Forem: Sergey-Sharyk

Problems with UITabBarController tab switching in iOS 18

Sergey-Sharyk — Mon, 21 Apr 2025 20:51:34 +0000

I recently inherited a project - an iOS app that hadn't been worked on in a while. After I made all the necessary updates and finally launched it on a device with the most up-to-date version of the operating system (at that time, it was iOS 18.4), I noticed an interesting but not too pleasant situation: when switching tabs in the bottom menu (implemented using UITabBarController and Storyboard), the screen flickered noticeably: for a fraction of a second, an empty space was shown, and only then the content appeared. A simple check showed that on iOS 17 and below, all switching was smooth, and the user immediately saw the real content of the selected tab. So, we have a scenario and context for the bug - it's time to get to the bottom of it.

Obviously, since the problem is only showing up on devices with iOS 18 and above, we need to figure out what changed in the major release. Some googling, reading documentation and forums confirmed the assumption that the incorrect behavior may be related to changes in the UITabBarController rendering system or in the UIViewController lifecycle order that Apple introduced in the new iOS version. That's when the first ideas to establish the exact cause, and therefore fix the problem, also appeared.

There may have been some optimizations under the hood of TabBar. For example, it was suggested that View in tabs were loaded “lazily”, which caused a delay before the content was displayed;
asynchrony and optimizations could have been applied at the level of the whole controller rather than at the level of individual View;
the ViewController lifecycle and the sequence of calls to the main methods of the lifecycle (such as viewWillAppear / viewDidAppear) may have changed. In this case, newer versions of iOS would first delete old content and then add new content.

In order to level out the problem of asynchronous loading of controllers, we had to check the force loading of tab controllers and their root View:

override func viewDidLoad() {
    super.viewDidLoad()

    // force load all view controllers
    self.viewControllers?.forEach { viewController in
        _ = viewController.view // force load VC's view
    }
}

It was expected that this approach, although it would increase resource consumption when starting the root TabBarController, would still provide a more familiar and pleasant user experience.
Reality: it didn't help, the tabs kept flickering.

Let's now check out the lifecycle behavior of ViewControllers. Changes in the behavior of viewWillAppear and viewDidAppear in iOS 18 have not been officially documented by Apple yet, but according to developer observations and testing on beta and RC-versions of iOS 18 we can note the following

New lifecycle call sequence when changing tabs. On iOS 17, when switching between tabs, the UITabBarController immediately called viewWillAppear / viewDidAppear on the new selectedViewController, even before the view was added to the window hierarchy. On iOS 18 - the view hierarchy is changed first, then the lifecycle methods are called. This makes visible a short delay if the view has not been loaded or layout is not yet calculated.
Lazy (deferred) loading of View. Right now, UITabBarController defers the creation of view child controllers until the first display. In iOS 17, the behavior was less aggressive - views were created immediately after being added to viewControllers (we already checked this with the first point).
In iOS 18, you may notice that layout happens a bit later (especially when the tab first appears). This can cause an empty view to be briefly displayed.

To test these scenarios, all the controllers in the tabs and the UITabViewController itself were set to a background color that matches the general style of the application - and it turned out that now the screen flickers with this color. Certainly, getting closer to the general theme of the application was a nice improvement, but it didn't solve the flickering problem. Here's how it was achieved:

override func viewDidLoad() {
    super.viewDidLoad()
    view.backgroundColor = .appMainBackgroundColor  // custom color, created with extension
}

By the way, installing backgroundView solved another problem: when switching from one of the controllers to another, the bottom menu itself flashed white before disappearing. Now during the transition the menu merged with the main content and the transition looked smoother.

Well, apparently it's not about data or layout - it's about the moment when the system adds the new controller's view to the hierarchy when switching tabs. Since the view is already loaded (we force it at startup), but still flickers - it means that the problem is in the moment of displaying, not initialization.

What is going on? Further debugging showed that in iOS 18, between clicking on the tab and the final insertion of the view into the UIWindow hierarchy, there is a brief interval in which the UITabBarController removes the old controller, but has not yet inserted the new one (or layout has not happened yet). At this point, the background of the main controller is visible, which looks like “flickering”.

In order to avoid this, we can try to postpone the removal of the old viewController - for this purpose we will override the switching behavior in the custom UITabBarController (we already had it, created long ago and assigned to Storyboard):

class CustomTabBarController: UITabBarController, UITabBarControllerDelegate {

    override func viewDidLoad() {
        super.viewDidLoad()
        self.delegate = self
    }

    // called before switching the tab
    func tabBarController(_ tabBarController: UITabBarController, shouldSelect viewController: UIViewController) -> Bool {

        if #available(iOS 18, *) {
            guard let fromView = selectedViewController?.view,
                  let toView = viewController.view,
                  fromView != toView else {
                return viewController != selectedViewController
            }

            // Custom transition, to "hide" blinking
            UIView.transition(
                from: fromView, to: toView,
                duration: 0.01, // almost immediately
                options: [.transitionCrossDissolve]
            ) { _ in }
        }

        return viewController != selectedViewController
    }
}

Run it - it works! This is an easy way to “glue” views to each other so that there is no phase when the screen is empty. You don't even need to force View creation!

Thanks for reading! Hope it helps, and happy coding to you!
If you found this post usefult, feel free to clap and subscribe!

Device independent time synchronization

Sergey-Sharyk — Thu, 13 Feb 2025 19:27:12 +0000

In many mobile applications, it is necessary to perform certain actions at a specific moment in time or after a certain time interval. All of this requires having reliable information about the current time. This article will discuss a method for obtaining the current time, independent of device and system settings.

Use Case

Let's consider the time synchronization process using the following example. Suppose your application implements a special offer (e.g., free access to premium features) for users who meet certain conditions. One of these conditions is regular use of the application (e.g., at least once every 12 hours) over several days. At the same time, no day can be skipped, otherwise the offer is canceled. Each time the user opens the application, their progress should be displayed. However, the application does not have its own backend to handle validation, meaning the application can only rely on itself and third-party services (of course, any interaction with them should preferably be minimized or eliminated). Leaving aside possible technical implementation options for the checks, let's focus on the following:

How to check that enough time has passed since the last mark of fulfilling the next part of the condition (in our case, 12 hours)?
How to check that no day has been skipped? To solve these issues, it is necessary to ensure a reliable mechanism for obtaining accurate and maximally independent timestamps of when certain events occur.

Why is this important?

Independence from user settings:

Devices may have incorrectly set time zones or intentionally altered time settings, which can cause application malfunctions.
Some users disable automatic time synchronization, which can create problems for applications requiring precision.

Global users: Applications used worldwide face different time zones, time formats, and daylight saving time rules.
Critical accuracy: Timestamps for transactions, events, and data synchronization must be accurate, especially in banking, logistics, and financial applications.
Fraud prevention: Changing the device's time can be used to bypass restrictions, such as during free trial periods or promotions.

Technical Implementation

For Android devices, the only way to obtain time independently of device/system settings and other factors that can be directly influenced during application use is to rely on external systems. Applications can obtain time from servers via protocols such as NTP (Network Time Protocol) or APIs. Data sources can be specialized time servers (e.g., services offered by Google, Microsoft, etc.) or national services. Applications can connect to the internet to obtain time, ignoring local device settings. Another option is GPS integration: GPS receivers provide precise time as part of the satellite system (typically used in navigation applications). Since it is preferable to minimize the use of external systems, we will use the NTP protocol.

NTP (Network Time Protocol) is a protocol for synchronizing time between devices on a network. It allows obtaining accurate time from special servers that use atomic clocks or GPS.

Time Synchronization Using NTP

The general workflow with NTP is quite simple:

The device sends a request to an NTP server.
The server returns the current precise time.
The device compares it with its own time and adjusts if necessary. Thus, using NTP ensures the same time across all devices on the network, provides accuracy, and prevents errors due to desynchronization.

Considering the specifics outlined in the example, the following should be taken into account:

There is no need to contact the NTP server every time precise time is required—it can be done once, and then the obtained value and the time elapsed since its retrieval can be used. For this, Android provides the API long SystemClock.elapsedRealtime(), which returns the time elapsed since the device was booted (this cannot be influenced except by restarting the device—see point 2 for a solution to this issue).
The elapsedRealtime value represents the time elapsed since the device was booted and, therefore, resets with each reboot. This must be considered when determining passed time interval.

Thus, for the correct operation of the time synchronizer, it is necessary to respond to three events:

Start of the scenario (in our example, this point X is the user accepting the special offer). At this moment, a request to the NTP server should be made. Let's denote the server's response as trueTimeStart. Save this value in persistent memory (e.g., in SharedPreferences). This value will also be used as trueTimeOnReboot in case the device is restarted. At the same time, determine and save two device-related values: 1) the elapsed real time value at the start of the scenario (denoted as elapsedRealtimeStart and 2) the local time at the start of the scenario (denoted as localTimeStart). These actions are performed within the application code upon the occurrence of the specific event (start of the scenario—in our example, when the user clicks the "Accept Offer" button).
Device reboot (point Y). Similarly, the device's time and the actual NTP time need to be synchronized. For this, a request to the NTP server is made, saving its response as trueTimeOnReboot. At the same time, update the Telapsed value. From the Android system's perspective, to receive a notification about the device booting, a BroadcastReceiver with the filter Intent.ACTION_BOOT_COMPLETED and/or Intent.ACTION_LOCKED_BOOT_COMPLETED should be implemented (receiving one or both of these notifications depends on the specifics of the firmware implementation).

Therefore, the next time the current time is needed (and there can be many such situations), no new requests to the server will be required—it will be sufficient to use the saved time marks:

val delta0 = trueTimeOnReboot - trueTimeStart
val delta1 = SystemClock.elapsedRealtime() - elapsedRealtimeStart
val localTimeNow = localTimeStart + delta0 + delta1

Here:

delta0 is the time elapsed since the start of the scenario until the last device boot. This ensures accounting for the time when the device was off.
delta1 is the time elapsed since the last device boot.
localTimeNow is the desired timestamp. Taking the device's time at the start of the scenario (localTimeStart) as the reference point (point X), we add to it all the time elapsed until the last device boot (point Y), as well as the device's uptime (until the current moment). Thus, we obtain an accurate time value that accounts only for the actual elapsed time and is independent of other factors, such as manual changes to the date/time in system settings.

The full code can be viewed on GitHub.

Conclusion

This article discussed a mechanism for obtaining precise time independently of device settings. This algorithm helps make applications more reliable and secure. It uses data from NTP servers and simple calculations to always display accurate time, even if the user changes settings or the device operates incorrectly. This is especially important for banking applications, online games, booking systems, and other services where time accuracy affects functionality. This approach not only eliminates errors but also protects against attempts to cheat, such as changing the time to extend a trial period.

How to Avoid Blinking in Android Recycler View

Sergey-Sharyk — Wed, 27 Nov 2024 20:37:17 +0000

A bit about RecyclerView

RecyclerView is a more flexible and efficient alternative to the classic ListView widget. It provides options for displaying and transforming a large amount of data in a list or grid view. RecyclerView has a modular architecture and allows you to reuse components for different data types, supports animations and smooth list scrolling. Due to its flexibility and efficiency, RecyclerView has become a standard tool for working with lists of data in Android development and is used in most modern applications that contain lists of data.

The main advantages of RecyclerView over the legacy ListView are reusability and lazy item loading: list items are loaded only as needed. For example, when scrolling through a list, new items can be loaded only when they become visible on the screen. When an item goes off-screen, its View and data are linked to a new item that comes within the scope. This reduces the number of View’s created and destroyed, which reduces memory overhead and improves the responsiveness of the application.

However, it’s not without a spoonful of tar in this honey barrel. When data changes, the list item must be rendered again and receive animation changes. However, such a complete refresh can be undesirable when it is sufficient to make changes to only a small part of the interface (an individual list item). As a consequence, the situation shown in the example below can occur: when you click on the header, the entire element flickers, which negatively affects the user experience.

So how can this be avoided? In this article, let’s look at two possibilities.

Stable IDs

The first option, Stable IDs, is relevant when list items are moved, deleted, or added. StableIds allow RecyclerView to determine exactly which items have been changed, moved, or deleted between the old and new datasets. This allows RecyclerView animators to correctly perform animations of visual changes to items and allows the user to understand what is happening.
In case RecyclerView detects that two items in the new and old dataset have the same ID (this is done by implementing the getItemId method), the same ViewHolder will be used for them, i.e. in this case RecyclerView will refrain from recreating the View and try to make the most of the existing one.
This is how the process of working with stableIds in RecyclerView works:

Setting the setHasStableIds flag:
To enable the use of stableIds in RecyclerView, the developer must call the setHasStableIds(true) method for the RecyclerView adapter. This tells the RecyclerView that the list items will have stable identifiers.
Implementation of the getItemId() method:
The RecyclerView adapter must override this method to return a unique identifier for a list item based on its position. Such a unique identifier could be, for example, a numeric representation of the item or its hash code
Comparing the current identifiers with previous identifiers:
When RecyclerView updates the list of items, it compares the stable identifiers of the current and previous datasets to determine changes and moves. If an item retains its stable identifier, RecyclerView can realize that the item has not changed and does not need to update its UI.
Optimized update methods:
RecyclerView provides a set of updated methods for handling list items, such as notifyItemChanged(), notifyItemMoved(), and notifyItemRemoved(). When using stableIds, RecyclerView can effectively apply these methods by only updating items that have actually changed.

DiffUtil

The popularity of RecyclerView was so great that the Google team returned to develop and refine it after a long time using the first stable version. At the same time, it was obvious that many developers did not fully understand the principle of view reuse, and instead of selectively updating only the items that really need it, they simply called notifyDataSetChanged(), which leads to recalculation and redrawing of all the items visible on the screen. Therefore, one of the big improvements has been the active implementation of the DiffUtil mechanism.

What is DiffUtil? This utility provides a mechanism to automatically detect differences between two data lists and calculate the necessary update operations (insert, delete, move list items). To do this, DiffUtil compares data objects based on a unique identifier or hash code. Then, based on the calculated differences, RecyclerView can update only those list items that have changed, minimizing the load on the application and improving performance. To compare old and new data and calculate the difference between them, several methods of the DiffUtil.Callback abstract class must be mandatorily overridden:

areItemsTheSame(oldItemPosition: Int, newItemPosition: Int): Boolean:
Checks whether the specified items in the old and new list are the same object. If the method returns true, the items are considered to be the same and further checks are required to determine if changes have been made;
areContentsTheSame(oldItemPosition: Int, newItemPosition: Int): Boolean:
checks whether the specified items in the old and new list have completely identical contents. If the method returns true, then nothing has changed for the item and it should not be redrawn or changed in any way.

DiffUtil with payloads

Using the DiffUtil mechanism by itself only allows you to optimize element updates in their entirety. In order to work at an even more granular level, payloads should be addressed.
Payloads in DiffUtil RecyclerView are used to update specific list items or parts of them without completely redrawing the entire list. This allows visible items to be updated more efficiently, reducing CPU load and interface refresh.
Payloads are arbitrary objects that are passed to DiffUtil methods to calculate the difference between the old and new datasets and apply the updates to the RecyclerView. The order in which they are used is as follows
As you can see from the diagram, the logic common to DiffUtil of comparing old and new data and calculating the difference between them (using the areItemsTheSame and areContentsTheSame methods) is executed first. However, two more steps are performed next:

payload calculation: DiffUtil.Callback#getChangePayload(oldItemPosition: Int, newItemPosition: Int): Any?
this method returns the payload for the specified items if they have different contents.
usage of the calculated payload: RecyclerView.Adapter#onBindViewHolder(holder: ViewHolder, payload: MutableList<Any>):
here you can check for payloads and perform appropriate updates only for the changed parts of the list item, minimizing redraws and improving performance.
Using payloads allows you to efficiently update only the parts of list items that have changed, instead of completely redrawing the entire list. This is particularly useful when list items contain complex structures or it may be less costly to update only parts of items rather than the entire contents. It also allows you to implement animations and custom effects, focusing on the specific changes that need to be visualized.

Conclusion

As a conclusion, I would like to present a comparison of two versions of the adapter: the first one corresponds to an inefficient primitive solution without change checking, while the second one contains code that takes into account the payload when changing elements

What exactly has changed?

First of all, Stable IDs are connected. For this purpose, a flag is set and a method is implemented that returns a unique ID for each item in the list:

Secondly, a mechanism of partial updating of items has been implemented. To do this, the new and old elements are first compared and what exactly has changed is calculated:

For example, here the list of items consists of two types of items — folders (which can be opened and closed) and files inside them (which can be absent on the device, downloaded with progress displayed, and present on the device). Accordingly, for each type, a different set of possible changes between the old and new state is computed. For files, the set of changes (presence on device flag and download progress) is placed in a list, for folders, for simplicity, the only possible changed item (collapsed/uncollapsed folder flag) is returned. If no changes are detected, getChangePayload returns simply null

Next, the calculated changes are processed each time the ViewHolder is accessed:

To do this, for each of the provided change element, its type and associated values are determined (with type conversion, since initially the method works with the Any type — well, and then the necessary adjustments are made in the user interface (in this case, custom bind methods are called, each of which makes small changes (for example, changing the progress value or icon)

Using the updated adapter avoids unnecessary animations of elements, as you can see in the video below:

Custom Kotlin Delegates: Shared Preferences

Sergey-Sharyk — Tue, 19 Nov 2024 21:55:30 +0000

This post focuses on a specific application of Kotlin delegates mechanism for data read and write operations using SharedPreferences.

What’s the problem?

SharedPreferences is an ideal solution for long-term storage of small pieces of data (such as user settings in an application or a cache of individual service messages). However, the read/write operations in SharedPreferences are quite verbose.

Consider, for example, a simple example — setting the display mode (light/dark theme):

private val sharedPrefs = context.getSharedPreferences("prefs_file_name", Context.MODE_PRIVATE)
companion object {
    private const val KEY_DARK_MODE = "dark_mode"
}
fun getIsDarkMode(): Boolean {
    return sharedPrefs.getBoolean(KEY_DARK_MODE, false)
}
fun saveIsDarkMode(darkMode: Boolean) {
    sharedPrefs.edit().putBoolean(KEY_DARK_MODE, darkMode).apply()
}

Thanks to Kotlin, it is also possible to use properties instead of methods, but the problem with boilerplate code still remains:

var isDarkMode: Boolean
    get() = sharedPrefs.getBoolean(KEY_DARK_MODE, false)
    set(darkMode) {
        sharedPrefs.edit().putBoolean(KEY_DARK_MODE, darkMode).apply()
    }

I would like to be able to read and set settings values with a single command — and here is a solution to such a problem.

1. Primitives

private class SharedPrefsPrimitiveDelegate<T>(private val sp: SharedPreferences, private val key: String, private val fallback: T): ReadWriteProperty<Any, T> {
    override operator fun getValue(thisRef: Any, property: KProperty<*>): T {
        return (sp.all[key] as? T) ?: fallback
    }

    override fun setValue(thisRef: Any, property: KProperty<*>, value: T) {
        val editor = sp.edit()
        when(value) {
            is Boolean -> editor.putBoolean(key, value)
            is Int -> editor.putInt(key, value)
            is Long -> editor.putLong(key, value)
            is Float -> editor.putFloat(key, value)
            is String -> editor.putString(key, value)
        }
        editor.apply()
    }
}

fun SharedPreferences.preference(key: String, fallback: Int = 0) = SharedPrefsPrimitiveDelegate(this, key, fallback)
fun SharedPreferences.preference(key: String, fallback: Long = 0L) = SharedPrefsPrimitiveDelegate(this, key, fallback)
fun SharedPreferences.preference(key: String, fallback: Float = 0.0f) = SharedPrefsPrimitiveDelegate(this, key, fallback)
fun SharedPreferences.preference(key: String, fallback: Boolean = false) = SharedPrefsPrimitiveDelegate(this, key, fallback)
fun SharedPreferences.preference(key: String, fallback: String = "") = SharedPrefsPrimitiveDelegate(this, key, fallback)

Then the example with the customization for the dark theme gets the form:

var isDarkMode by sharedPrefs.preference(KEY_DARK_MODE)

2. Complex objects

Storing records of primitive data types has built-in support in SharedPreferences. However, sometimes it makes sense to write and then read a more complex object. In this case, some serialization/deserialization mechanism similar to Parcelable is required, but converting the object not to/from a binary format, but to/from one of the types supported by SharedPreferences. Obviously, the most appropriate option is to convert to a string.
For this purpose, let’s define some simple interfaces for the conversion:

interface StringParser<T> {
    fun parse(input: String): T?
}
interface StringConverter<T> : StringParser<T> {
    fun stringify(input: T): String
}

interface StringConvertible {
    fun stringify(): String
}

And let’s immediately prepare a default implementation for their communication:

abstract class SimpleStringConverter<T : StringConvertible> : StringConverter<T> {
    override fun stringify(input: T): String = input.stringify()
}

Then the delegate will be of the form:

class SharedPrefsComplexDelegate<T : StringConvertible>(
    private val sp: SharedPreferences,
    private val key: String,
    private val converter: StringConverter<T>,
) : ReadWriteProperty<Any, T?> {

    constructor(sp: SharedPreferences, key: String, parser: (String) -> T?) :
            this(sp, key, object : StringConverter<T> {
                override fun parse(input: String): T? = parser(input)
                override fun stringify(input: T): String = input.toString()
            })

    override operator fun getValue(thisRef: Any, property: KProperty<*>): T? {
        return try {
            sp.getString(key, null)?.let { converter.parse(it) }
        } catch (t: Throwable) {
            null
        }
    }

    override fun setValue(thisRef: Any, property: KProperty<*>, value: T?) {
        val editor = sp.edit()
        editor.putString(key, value?.stringify())
        editor.apply()
    }
}


fun <T : StringConvertible> SharedPreferences.preference(key: String, parser: StringParser<T>) =
    SharedPrefsComplexDelegate<T>(this, key, parser::parse)

And here is an example of its use (for example, when we want to save user avatar data):

data class Attach(val id: Long, val width: Int, val height: Int, val text: String) : StringConvertible {
    override fun stringify(): String {
        return "Attach|${id}|${width}|${height}|${text}"
    }
}

class AttachConverter : SimpleStringConverter<Attach>() {
    override fun parse(input: String): Attach? {
        val items = input.split("|")
        return try {
            Attach(items[1].toLong(), items[2].toInt(), items[3].toInt(), items[4])
        } catch (t: Throwable) {
            null
        }
    }
}


var mainAttach by sp.preference("main_avatar", AttachConverter())

3. Collections (sets, lists, etc.)

In the sections above, we used a custom delegate to handle individual settings of primitive types (numbers, strings, logical flags) or complex objects. However, Android SharedPreferences allow you to store sets of strings as well. Obviously, the values of a set can be not only abstract strings (for example, the draft text of a message entered by the user in the input field of a messenger), but also string representations of other primitive types or even entire complex objects. Then with the application of a particular parser, we can use a wrapper over the Set handling methods to get sets of the desired type:

class SharedPrefsSetDelegates<T>(
    private val sp: SharedPreferences,
    private val key: String,
    private val converter: StringConverter<T>
) : ReadWriteProperty<Any, Set<T>> {

    constructor(sp: SharedPreferences, key: String, parser: (String) -> T?) :
            this(sp, key, object : StringConverter<T> {
                override fun parse(input: String): T? = parser(input)
                override fun stringify(input: T): String = input.toString()
            })

    override operator fun getValue(thisRef: Any, property: KProperty<*>): Set<T> {
        return try {
            val list = sp.getStringSet(key, emptySet())?.mapNotNull { converter.parse(it) }
            list?.toSet<T>() ?: emptySet()
        } catch (t: Throwable) {
            emptySet()
        }
    }

    override fun setValue(thisRef: Any, property: KProperty<*>, value: Set<T>) {
        val editor = sp.edit()
        val set = value.map { converter.stringify(it) }.toSet()
        editor.putStringSet(key, set)
        editor.apply()
    }
}

And, as usual, a set of auxiliary functions:

fun SharedPreferences.intSetPreference(key: String) =
    SharedPrefsSetDelegates(this, key, String::toIntOrNull)

fun SharedPreferences.longSetPreference(key: String) =
    SharedPrefsSetDelegates(this, key, String::toLongOrNull)

fun SharedPreferences.floatSetPreference(key: String) =
    SharedPrefsSetDelegates(this, key, String::toFloatOrNull)

fun SharedPreferences.boolSetPreference(key: String) =
    SharedPrefsSetDelegates(this, key, String::toBooleanStrictOrNull)

fun SharedPreferences.stringSetPreference(key: String) =
    SharedPrefsSetDelegates(this, key) { it }

fun <T> SharedPreferences.listPreference(key: String, converter: StringConverter<T>) =
    SharedPrefsSetDelegates(this, key, converter)

fun <T: StringConvertible> SharedPreferences.listPreference(key: String, converter: SimpleStringConverter<T>) =
    SharedPrefsSetDelegates(this, key, converter)

4. DataStore

In 2021, Google introduced a new data storage mechanism designed to replace SharedPreferences — DataStore.
DataStore also requires quite a bit of template code, and it makes sense to wrap it in a delegate. In general, creating such a delegate will not differ too much from the ones shown above in the article, and so its text will not be given here.

Automating JavaScript execution in the browser

Sergey-Sharyk — Sat, 09 Nov 2024 22:04:42 +0000

If you (like me) often perform the same actions in your browser, you would probably like (like me) to automate them.
In this short post, I will show you some of the most common options to reduce the routine and automate JavaScript scripts execution in the browser (using Google Chrome as an example).

Automating JavaScript execution in the browser is useful for a range of tasks, including web application testing, data scraping, and simplifying routine actions. Several methods can accomplish this task, from using browser console tools to specialized software and frameworks.

1. Running a JS Script Using DevTools

Open the browser console (usually F12).
Go to the Console tab.
Paste and execute the required JS code by pressing Enter.

Pros: Quick and simple, ideal for testing small scripts.
Cons: Cannot automate code execution by schedule or on different pages.

2. Automation Using Browser Extensions

Extensions enable JavaScript code execution when a page loads or based on specific events. You can create your own extension or use one of existing solutions. These user script managers allow JS code to run on specific sites.

Install the extension.
Write a script and specify the execution conditions (e.g., URL).
The script will run automatically when you visit the specified page.

Pros: Suitable for tasks requiring constant script execution on certain pages.
Cons: Limited by the browser and security requirements.

3. Using Automation Frameworks

There are plenty of tools to execute actions in the browser simulating real user, such as Selenium or Puppeteer. But, most of them require additional knowledge of programming languages and scripting skills. The general scenario is:

Install the tool and required components (e.g., the appropriate web driver for your browser).
Write a script to open a page, perform actions, and run JS code.
Launch the script.

Pros: Suitable for complex automation, running tests, and data scraping.
Cons: Requires programming knowledge, environment setup, and sometimes high resources.

4. Launching as bookmarklet.

In Google Chrome, you can create a bookmark that runs JavaScript code when clicked. These bookmarks are called bookmarklets. They are useful for quickly running small scripts on a page.

Open the Bookmark Manager (Go to Chrome > Bookmarks > Bookmark Manager, or, alternatively, press Ctrl+Shift+O)
Create a New Bookmark:
- Click Add bookmark or press Ctrl+D to create a new one.
- In the Name field, give it a descriptive name, like "Run JS."
- In the URL field, paste your JavaScript code, making sure to add the javascript: prefix at the beginning.
Write Your JavaScript Code
To launch the script, click on the created bookmark.

Pros: Fast launch; full control on the code.
Cons: the entire code should be on one line, as line breaks may cause errors; some sites may block certain scripts from running for security reasons.

This outline covers the main methods and tools for automating JavaScript execution in the browser. Such automation serves a wide range of purposes, from testing to automatic data collection. Choosing the right method depends on task complexity, knowledge level, and automation requirements.
Personally, I prefer running small snippets directly in the Console; middle scripts for repeating tasks run as bookmarklets, and create separate browser extension for more complex cases.

Simple Context Menu in iOS by Tap

Sergey-Sharyk — Mon, 28 Oct 2024 20:53:14 +0000

Problem

Not too long ago, I started developing an iOS version of one of our company’s mobile apps. The new feature included a requirement to open a multi-option menu when a commonly used three-dot element was clicked. Such a menu has probably been seen by every smartphone user:

For simplicity, such menus will be further referred to as “context menus”.

However, for iPhone owners it’s more usual to get such dialogs after holding the button for a long time, while I needed to show the menu at a simple click. After studying the documentation and surfing the web in search of suitable solutions, I found the following:

yes, in iOS it is possible to show a context menu using UIKit SDK BUT only when a visual element is long pressed, and this is expected behavior;
yes, it is possible to trigger a simple tap to show a context menu using the Private API, BUT this is forbidden by AppStore rules;
yes, it is possible to assign a menu to a button as the main action, BUT this is only applicable from iOS 14 and only for UIButtons. Thus, off-the-shelf solutions didn’t fit, so I decided to write my own mechanism for showing context menus.

Filling menu items

First, let’s implement methods for filling the menu. For this purpose, it is convenient to use a combination of “Builder” and “Prototype” design patterns to give an opportunity to set only parameters interesting for the client, and after the process is completed, to get a fully ready to work menu. To do this we will need:

a description of each menu option (each option contains an optional icon, text and a click handler);
a set of menu options;
a method for adding items to the menu; it takes the menu item contents as parameters, and for encapsulation purposes converts them to the internal data structure defined in (1);

class ContextMenu: UIView {

    /// (1) for convenience and clarification of the intention 
    typealias MenuOptionAction = () -> ()

    /// (1): each item of the menu contains text (with optional icon) and can react onn user's tap on it
    private struct MenuOptionItem {
        let text: String
        let icon: UIImage?
        let action: MenuOptionAction
    }

    class Builder {

        /// (2) the builder operates the list of options
        private var items: [MenuOptionItem] = []

        /// (3) seed the items
        func addOption(withText s: String, icon image: UIImage?, _ callback: @escaping MenuOptionAction) -> Builder {
            self.items.append(MenuOptionItem(text: s, icon: image, action: callback))
            return self
        }

        /// ... see more later
    }
}

It should be noted — method (3) returns an instance of the builder itself, which makes it possible to use call chains of this method, as will be shown in the example. This builder contains minimal functionality, but can be improved if necessary (e.g. you can add nested menus, customization ability for each option, etc.).

Preparing for display

Now let’s implement a method to complete the construction and get a finished instance of the context menu. A context menu is a custom UIView that contains all of its options as children. For convenience, the elements are placed in a stack and separated by thin lines. At the same time, the menu itself is placed in a full-screen container, which allows you to customize the blur effect for all elements on the screen, except for the menu itself; as well as to implement closing the menu by clicking outside of its elements.

import UIKit

class ContextMenu: UIView {

    class Builder {
        func build() -> ContextMenu {
            /// create custom view for the menu
            /// this view itself takes all space, but only part of it used for menu items
            /// we still need to occupy all screen to handle taps outside the menu items and dismiss the menu in the case
            let menu = ContextMenu(frame: CGRect(x: 0, y: 0, width: AppConstants.screenWidth, height: AppConstants.screenHeight))

            /// first, configure container for menu items
            let w = AppConstants.screenWidth * 0.8
            let stack = createOptionsStack()

            /// inflate the with with the known items (create new views and set their parameters)
            populateOptions(into: stack)

            /// make stylization
            applyStyles(for: stack)
            let blurredEffectView = wrapWithBlur(butKeep: stack)

            /// prepare interaction
            menu.tap {
                /// just hide the menu when click outside the menu items
                self.dismiss()
            }

            /// put it all together
            menu.addSubview(stack)
            menu.putTo(parent: blurredEffectView.contentView)

            /// when created, the menu is invisible before attached explicitly (see later)
            menu.alpha = 0.0

            // register some direct links
            menu.stack = stack
            menu.blurContainer = blurredEffectView

            return menu
        }

        // MARK: - internal methods for building

        /// - Returns: container for menu items
        private func createOptionsStack() -> UIStackView {
            let stack = UIStackView(frame: CGRect(x: 0, y: 0, width: w, height: ContextMenuItem.HEIGHT * CGFloat(items.count)))
            stack.backgroundColor = .black.withAlphaComponent(0.3)
            stack.axis = .vertical
            stack.distribution = .fillProportionally
            stack.spacing = 0
        }

        /// Inserts and configures each option item as custom view
        private func populateOptions(into stack: UIStackView, of menu: ContextMenu) {
            let initOffset = ContextMenuItem.HEIGHT / 2
            var h: CGFloat = -initOffset
            items.enumerated().forEach { (index, option) in
                /// Make view inflation
                let item = nib(ContextMenuItem.self)
                item.translatesAutoresizingMaskIntoConstraints = false
                item.frame = CGRect(x: 0, y: h, width: ContextMenu.Builder.menuWidth, height: ContextMenuItem.HEIGHT)
                h += ContextMenuItem.HEIGHT
                item.set(icon: option.icon)
                item.set(text: option.text)
                item.tap {
                    /// when user taps on the menu item, execute the provided action and dismiss the menu
                    menu.dismiss()
                    option.action()
                }
                stack.addArrangedSubview(item)

                if index != items.count - 1 {
                    let separatorView = UIView(frame: CGRect(x: 0, y: h + initOffset, width: ContextMenu.Builder.menuWidth, height: 1))
                    separatorView.backgroundColor = .divider()
                    stack.addArrangedSubview(separatorView)
                    h += 1
                }
            }
        }

        /// Configures UI 
        private func applyStyles(for stack: UIStackView) {            
            /// some styling for items
            stack.layer.cornerRadius = 12
            stack.layer.borderWidth = 1
            stack.layer.borderColor = UIColor.purple.cgColor
        }

        /// Add blur for the entire screen (except items container)
        private func wrapWithBlur(butKeep stack: UIView) -> BlurVisualEffectView {
            let blurEffect = UIBlurEffect(style: .systemUltraThinMaterialDark)
            let blurredEffectView = BlurVisualEffectView(effect: blurEffect, intensity: 0.3)
            blurredEffectView.alpha = 0.0
            blurredEffectView.frame = stack.bounds
            return blurredEffectView
        }
    }

    /// keep references to some of important subviews to simplify access
    private var stack: UIStackView? = nil
    private var blurContainer: UIVisualEffectView? = nil
}

Overall, nothing extraordinary here, and I hope the added comments fully explain the principle of the builder. I would like to point out only a few points:

in populateOptions, for each element, an option View is created using the extension method nib(_:):

func nib<T: UIView>(_ viewType: T.Type) -> T {
   let nibName = String(describing: type(of: viewType)).remove(suffix: ".Type")
   return Bundle.main.loadNibNamed(nibName, owner: nil, options: nil)![0] as! T
}

other extension methods are also used, the implementation of which is omitted to simplify the article and focus on its main content;
the layout of the element itself is quite trivial, depends on the design of the project and is omitted here.

The standard UIVisualEffectView that handles blur was blurring the screen too much, so we had to make a custom implementation with reduced blur intensity (thanks to darrarski who published his version — available on Github Gists).

Showing and hiding the context menu

The menu is ready to be displayed, now we need to show it when clicking on some (let’s call it “target”) UI element. To do this, we perform a few simple steps in sequence:

define the parent ViewController on top of which the menu should be added;
decide where to place the menu options. To do this, we qualitatively evaluate the area of the screen where the target element is located and place the menu options on a free space (above or below the target element);
smoothly show the menu — for simplicity, in the example we just bring it from transparency to opacity with simultaneous resizing;
also, we need a way to remove the menu (by clicking either on the menu item or completely outside of it) — here we perform the animation described in step 3, and after its completion — remove the container with the menu from the hierarchy of visual components.

Launching

As an example, let’s consider an application in which a user can communicate with specialists in a certain area, and after the conversation leave a review. Such feedback affects the rating of the expert, is visible to other users of the service, and therefore falls under the definition of user-generated content. Accordingly, the application should provide an opportunity to complain about a review that violates the requirements. It was decided to realize this by showing a context menu with options when clicking on the button of additional actions for the review:

And this is what came out: