Overview Using suspend methods with coroutines is a new norm while using Kotlin in Android, Kotlin Native or Kotlin Multiplatform. Recently, I have been searching good libraries for the multiplatform for a pet project I am working on, and I have seen many libraries and implementations that uses GlobalScope as coroutine scope. This is a huge antipattern because using GlobalScope can lead to memory leaks. Problem with GlobalScope Though in Android, using suspend methods is fairly easy because you can just use viewModelScope because most of the heavy lifting is being done inside viewmodels. So, No need to switch to CoroutineScope. But occasionally, there is a need for asynchronous work outside ViewModel. A common example of it would be an external SDK in your codebase may require an instance of a class performing module specific or app related tasks. ...

Overview Logs are very useful while debugging an issue and finding a root cause for it. I would write tons of garbage logs lines such as “inside save image method”, “user clicked on button send” or something like “image-Id=83488131". I would delete all these stuff as soon as I know what is the issue, and ready to commit changes. But, having too much verbosity in logs is equally bad and pollutes the log cat. Yeah, Logs are useful daily but if done properly. Here are a few tips and suggestion that I learned the hard way that would help you up the logging game. ...

Overview Webview in Android is a system component that runs on chromium engine that allows Android apps to display web view content. There are plenty of apps out there that simply wraps web pages or web content which is stored in app. Most of the cross-platform apps uses Webview to provide easy to use interface for their users. Now coming to more technical side of the things, being a developer you can debug your Webview with ADB. Android web view has debugging feature flag, that allows you to use the ADB remote debugging extension for chrome to debug the contents of the Webview. ...

Naming your methods and fields while programming can be hard at times, But not impossible and since, there is no concrete guideline about the naming, I made up my own. You can use these guidelines in your codebase to make the code more readable and avoid mental breakdowns for a maintenance programmer. Avoid misleading words Avoid naming your variables data, process, run, do. These words do not mean anything. Literally, any variable in your codebase can be called data, since you are ultimately doing something with data. These words do not correctly inform what they are supposed to do. In such cases, think about it for a few moments and figure out what can be a suitable name for your method or a variable. The generic idea would be avoiding common prefixes that could mislead someone or even you after some months. ...

While developing Nyx, I stumbled upon a custom delegate that would get me the extras using an inner class. Similar to safeArgs. I found it a very intriguing thing for a lazy ass like me. I implemented the same for my other app Ip-Scanner but immediately realized it contains a boilerplate code. For each fragment and activity. Being a lazy person, I hate writing boilerplate, I made few extensions that would get the extras for me with Kotlin lazy. ...