Hello Readers, CoolMonkTechie heartily welcomes you in this article (An Overview Of Strict Mode).
In this article, we will learn about Strict Mode in Android. Performing any kind of long blocking operations or disk IO operations on the Android Main thread can cause ANR (Application Not Responding) issues. We may not even realise that we have a potential ANR until it is too late and is already in our user’s hands. most of the cases, the library or framework which we are using in our application, will not allow us to perform disk operations on the main thread (Room for instance, makes it explicit when we want to turn it off).
So, how do we know and correct our mistakes done during android application development when the libraries or frameworks don’t explicitly prevent this kind of operation?
Android provides a Strict Mode developer tool for that.
To understand about the Strict Mode, we cover the below topics as below :
Overview
Strict Mode Policies
Different Ways to Notify Strict Mode
Enabling Strict Mode
Recommendations
A famous quote about learning is :
“If you live long enough, you’ll make mistakes. But if you learn from them, you’ll be a better person.“
So Let’s begin.
Overview
Strict Mode is a developer tool which detects things we might be doing by accident and brings them to our attention so we can fix them.
Best practice in Android says “keeping the disk and network operations off from the main thread makes applications much smoother and more responsive”. So StrictMode is use to catch the coding issues such as disk I/O or network access on the application’s main thread i.e. UI thread. By keeping our application’s main thread responsive, we also prevent ANR dialogs from being shown to users.
This is a debugging tool introduced in Android 2.3 (API level 9) but more features were added in Android 3.0.
StrictMode Policies
Strict Mode has two types of policies and each policy has various rules. Each policy also has various methods of showing when a rule is violated.
Thread Policy
Thread policies are focused on the things which is not recommended to do in main thread like disk or network operations. The Thread policy can monitor following violations:
Disk Reads
Disk Writes
Network access
Resource Mismatch
Custom Slow Code
VM Policy
VM policies are focused on memory leaks because of bad coding practices like forgot to close the SQLite cursor or leaks in Activities. The VM policy can monitor following violation:
Activity leaks
SQLite objects leaks
Closable objects leaks
Registration objects leaks
Class instance limit
File URL exposure
Different Ways to Notify Strict Mode
There are variety of different ways by which user/developer get to know when a rule you set has been violated. In terms of Strict Mode, it is known as Penalty.
Some of methods are listed below:
penaltyDeath(): Crash the whole process on violation.
penaltyDeathOnNetwork(): Crash the whole process on any network usage.
penaltyDialog(): Show an annoying dialog to the developer on detected violations.
penaltyFlashScreen(): Flash the screen during a violation.
penaltyLog(): Log detected violations to the system log.
Enabling Strict Mode
To enable and configure the Strict Mode in our application, we require to use setThreadPolicy() and setVmPolicy() methods of Strict Mode. It is a good practice to set policies either in Application , Activity or other application component’s Application.onCreate() method:
Now, we can decide what should happen when a violation is detected like in the above example we have used only penaltyLog() for Thread Policy but in the VM Policy we used penaltyLog() as well as penaltyDeath() to notify. We can watch the output of adb logcat while we use our application to see the violations as they happen.
Here is the example of penaltyLog() showing the logs which explains Strict Mode is warning us that we are using disk write operation on the main thread.
DEBUG/StrictMode(3134): StrictMode policy violation; ~duration=319 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
DEBUG/StrictMode(3134): at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1041)
DEBUG/StrictMode(3134): at android.database.sqlite.SQLiteStatement.acquireAndLock(SQLiteStatement.java:219)
DEBUG/StrictMode(3134): at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:83)
DEBUG/StrictMode(3134): at android.database.sqlite.SQLiteDatabase.updateWithOnConflict(SQLiteDatabase.java:1829)
DEBUG/StrictMode(3134): at android.database.sqlite.SQLiteDatabase.update(SQLiteDatabase.java:1780)
DEBUG/StrictMode(3134): at com.test.data.MainActivity.update(MainActivity.java:87)
Recommendations
If we find violations that we feel are problematic, there are a variety of tools to help solve them: threads, Handler, AsyncTask, IntentService, etc. But don’t feel compelled to fix everything that Strict Mode finds. In particular, many cases of disk access are often necessary during the normal activity lifecycle. Use Strict Mode to find things we did by accident. Network requests on the UI thread are almost always a problem, though.
It is not a security mechanism and is not guaranteed to find all disk or network accesses. While it does propagate its state across process boundaries when doing Binder calls, it’s still ultimately a best effort mechanism. Notably, disk or network access from JNI calls won’t necessarily trigger it.
Many of violations are not related to our application. We want to suppress these violations. For example- DiskRead checking (or suppress any other checkingof StrictMode that is it violating). Here, we want to do following things in function:
Turn off the Strict Mode checking
Running the function or the parameterized block of code
Turn on the original Strict Mode checking
The function looks like the below:
fun permitDiskReads(func: () -> Any?) : Any? {
if (BuildConfig.DEBUG) {
val oldThreadPolicy = StrictMode.getThreadPolicy()
StrictMode.setThreadPolicy(
StrictMode.ThreadPolicy.Builder(oldThreadPolicy)
.permitDiskReads().build())
val anyValue = func()
StrictMode.setThreadPolicy(oldThreadPolicy)
return anyValue
} else {
return func()
}
}
The above example, we are just suppressing the detectDiskReads(), we could perform other suppression if required. it‘s not only running the function, but returning Any value (i.e. nothing or something if we don’t know what Any means) the function might return.
This is useful when the code that we want to suppress the check might be a function that returns something. For example, we have a SampleManager.getInstance() that also have some disk reads violation we want to suppress. So we could do as below:
val sampleManager =
permitDiskReads { SampleManager.getInstance() } as SampleManager
That’s all about in this article.
Conclusion
In this article, we understood about about Strict Mode in Android. This article explained about Strict Mode which is a very useful tool to find and fix performance issues, object leaks, and other hard-to-find runtime issues for Android developers. We may think that we are doing everything off the main thread, but sometimes small things can creep in and cause these issues. It helps keep our applications in check and should definitely be enabled whilst developing our applications.
Thanks for reading! I hope you enjoyed and learned about Strict Modeconcepts in Android. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find other articles of CoolMonkTechie as below link :
Hello Readers, CoolMonkTechie heartily welcomes you in this article (An Overview Of Jetpack DataStore).
In this article, we will learn about Google’s new library Jetpack DataStore in Android. JetpackDataStore is Google’s new library to persist data as key-value pairs or typed objects using protocol buffers. Using Kotlin coroutines and Flow as its foundation, it aims to replace SharedPreferences. This is part of the Jetpack suite of libraries. This article explains about Jetpack DataStore types implementations and address the limitations of the SharedPreferences API in Android.
To understand the Jetpack DataStore, we cover the below topics as below :
Overview
Limitation of SharedPreferences
Types of Jetpack DataStore Implementations
Jetpack DataStore Setup
Store key-value pairs with Preferences DataStore
Store typed objects with Proto DataStore
Use Jetpack DataStore in synchronous code
A famous quote about learning is :
“One learns from books and example only that certain things can be done. Actual learning requires that you do those things.”
So Let’s begin.
Overview
Jetpack DataStore is a data storage solution that allows us to store key-value pairs or typed objects with protocol buffers. DataStore uses Kotlin coroutines and Flow to store data asynchronously, consistently, and transactionally. Google introduced DataStore to address the limitations in the SharedPreferences API.
Limitation of SharedPreferences
To understand the DataStore’s advantages, we need to know about the limitations of SharedPreferences API. Even though SharedPreferences has been around since API level 1, it has drawbacks that have persisted over time:
SharedPreferences is not always safe call on the UI thread. It can cause junk by blocking the UI thread.
There is no way for SharedPreferences to signal errors except for parsing errors as runtime exceptions.
SharedPreferences has no support for data migration. If we want to change the type of a value, we have to write the entire logic manually.
SharedPreferences doesn’t provide type safety. Application will compile fine If we try to store both Booleans and Integers using the same key.
Google introduced DataStore to address the above limitations.
Types of Jetpack DataStore Implementations
DataStore provides two different implementations: Preferences DataStore and Proto DataStore.
Preferences DataStore: Stores and accesses data using keys. This implementation does not require a predefined schema, and it does not provide type safety. This is similar to SharedPreferences. We use this to store and retrieve primitive data types.
Proto DataStore: Uses protocol buffers to store custom data types. When using Proto DataStore, we need to define a schema for the custom data type.
SharedPreferences uses XML to store data. As the amount of data increases, the file size increases dramatically and it’s more expensive for the CPU to read the file.
Protocol buffers are a new way to represent structured data that’s faster and than XML and has a smaller size. They’re helpful when the read-time of stored data affects the performance of our application.
Jetpack DataStore Setup
To use Jetpack DataStore in application, we add the following dependencies to Gradle file depending on which implementation we want to use:
Datastore Typed
// Typed DataStore (Typed API surface, such as Proto)
dependencies {
implementation("androidx.datastore:datastore:1.0.0")
// optional - RxJava2 support
implementation("androidx.datastore:datastore-rxjava2:1.0.0")
// optional - RxJava3 support
implementation("androidx.datastore:datastore-rxjava3:1.0.0")
}
// Alternatively - use the following artifact without an Android dependency.
dependencies {
implementation("androidx.datastore:datastore-core:1.0.0")
}
Datastore Preferences
// Preferences DataStore (SharedPreferences like APIs)
dependencies {
implementation("androidx.datastore:datastore-preferences:1.0.0")
// optional - RxJava2 support
implementation("androidx.datastore:datastore-preferences-rxjava2:1.0.0")
// optional - RxJava3 support
implementation("androidx.datastore:datastore-preferences-rxjava3:1.0.0")
}
// Alternatively - use the following artifact without an Android dependency.
dependencies {
implementation("androidx.datastore:datastore-preferences-core:1.0.0")
}
If we use the datastore-preferences-core artifact with Proguard, we must manually add Proguard rules to our proguard-rules.pro file to keep our fields from being deleted.
Store key-value pairs with Preferences DataStore
The Preferences DataStore implementation uses the DataStore and Preferences classes to persist simple key-value pairs to disk.
Create a Preferences DataStore
// At the top level of our kotlin file:
val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "settings")
Use the property delegate created by preferencesDataStore to create an instance of Datastore<Preferences>. Call it once at the top level of kotlin file, and access it through this property throughout the rest of application. This makes it easier to keep DataStore as singleton.
Read from a Preferences DataStore
val EXAMPLE_COUNTER = intPreferencesKey("example_counter")
val exampleCounterFlow: Flow<Int> = context.dataStore.data
.map { preferences ->
// No type safety.
preferences[EXAMPLE_COUNTER] ?: 0
}
Because Preferences DataStore does not use a predefined schema, we must use the corresponding key type function to define a key for each value that we need to store in the DataStore<Preferences> instance.
Preferences DataStore provides an edit() function that transactionally updates the data in a DataStore. The function’s transform parameter accepts a block of code where we can update the values as needed. All of the code in the transform block is treated as a single transaction.
Store typed objects with Proto DataStore
The Proto DataStore implementation uses DataStore and protocol buffers to persist typed objects to disk.
Define a schema
Proto DataStore requires a predefined schema in a proto file in the app/src/main/proto/ directory. This schema defines the type for the objects that we persist in our Proto DataStore.
The class for our stored objects is generated at compile time from the message defined in the proto file. Make sure we rebuild our project.
Create a Proto DataStore
There are two steps involved in creating a Proto DataStore to store typed objects:
Step 1 : Define a class that implements Serializer<T>, where T is the type defined in the proto file. This serializer class tells DataStore how to read and write data type. Make sure we include a default value for the serializer to be used if there is no file created yet.
Step 2 : Use the property delegate created by dataStore to create an instance of DataStore<T>, where T is the type defined in the proto file. Call this once at the top level of kotlin file and access it through this property delegate throughout the rest of application. The filename parameter tells DataStore which file to use to store the data, and the serializer parameter tells DataStore the name of the serializer class defined in step 1.
We use DataStore.datato expose a Flow of the appropriate property from our stored object.
val exampleCounterFlow: Flow<Int> = context.settingsDataStore.data
.map { settings ->
// The exampleCounter property is generated from the proto schema.
settings.exampleCounter
}
Write to a Proto DataStore
Proto DataStore provides an updateData() function that transactionally updates a stored object. updateData() gives us the current state of the data as an instance of our data type and updates the data transactionally in an atomic read-write-modify operation.
Asynchronous API is one of the primary benefits of DataStore. It may not always be feasible to change our surrounding code to be asynchronous. This might be the case if we’re working with an existing codebase that uses synchronous disk I/O or if we have a dependency that doesn’t provide an asynchronous API.
Kotlin coroutines provide the runBlocking() coroutine builder to help bridge the gap between synchronous and asynchronous code. We can use runBlocking() to read data from DataStore synchronously. RxJava offers blocking methods on Flowable. The following code blocks the calling thread until DataStore returns data:
val exampleData = runBlocking { context.dataStore.data.first() }
Performing synchronous I/O operations on the UI thread can cause ANRs or UI junk. We can mitigate these issues by asynchronously preloading the data from DataStore:
override fun onCreate(savedInstanceState: Bundle?) {
lifecycleScope.launch {
context.dataStore.data.first()
// You should also handle IOExceptions here.
}
}
This way, DataStore asynchronously reads the data and caches it in memory. Later synchronous reads using runBlocking() may be faster or may avoid a disk I/O operation altogether if the initial read has completed.
That’s all about in this article.
Conclusion
In this article, we understood about Google’s new library Jetpack DataStore in Android. This article explained about Jetpack DataStore types implementations and address the limitations of the SharedPreferences API in Android.
Thanks for reading! I hope you enjoyed and learned about Jetpack DataStoreconcepts in Android. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find other articles of CoolMonkTechie as below link :
Hello Readers, CoolMonkTechie heartily welcomes you in this article (An Overview Of Application Security Best Practices).
In this article, we will learn about the best practices of Application Security in Android. By making our application more secure in android, we help preserve user trust and device integrity. This article explains about few best practices that have a significant, positive impact on our application’s security.
To understand the Application Security Best Practices, we cover the below topics as below :
Enforce secure communication with other applications
Provide the right permissions
Store data safely
Keep the services and related dependencies up-to-date
A famous quote about learning is :
“Being a student is easy. Learning requires actual work.”
So Let’s begin.
1. Enforce secure communication with other applications
When we safeguard the data that we want to exchange between our application and other applications, or between our application and a website, we improve our application’s stability and protect the data that we want to send and receive.
1.1 Use implicit intents and non-exported content providers
1.1.1 Show an application chooser
Use implicit intents to show application chooser that provides option to user to launch at least two possible applications on the device for the requested action. This allows users to transfer sensitive information to the application that they trust.
val intent = Intent(Intent.ACTION_SEND)
val possibleActivitiesList: List<ResolveInfo> =
packageManager.queryIntentActivities(intent, PackageManager.MATCH_ALL)
// Verify that an activity in at least two applications on the user's device
// can handle the intent. Otherwise, start the intent only if an application
// on the user's device can handle the intent.
if (possibleActivitiesList.size > 1) {
// Create intent to show chooser.
// Title is something similar to "Share this photo with".
val chooser = resources.getString(R.string.chooser_title).let { title ->
Intent.createChooser(intent, title)
}
startActivity(chooser)
} else if (intent.resolveActivity(packageManager) != null) {
startActivity(intent)
}
1.1.2 Apply signature-based permissions
Apply signature-based permissions while sharing data between two applications that is controlled by us. These permissions do not need user confirmation, but instead it checks that the applications accessing the data are signed using the same signing key. Hence offer more streamlined and secure user experience.
1.1.3 Disallow access to our application’s content providers
Unless we intend to send data from our application to a different application that we don’t own, we should explicitly disallow other developers’ apps from accessing the ContentProvider objects that our application contains. This setting is particularly important if our application can be installed on devices running Android 4.1.1 (API level 16) or lower, as the android:exported attribute of the <provider> element is true by default on those versions of Android.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapp">
<application ... >
<provider
android:name="android.support.v4.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
...
android:exported="false">
<!-- Place child elements of <provider> here. -->
</provider>
...
</application>
</manifest>
1.2 Ask for credentials before showing sensitive information
When we are requesting the credentials so that we can access sensitive information or premium content in our application, ask for either a PIN/password/pattern or a biometric credential, such as using face recognition or fingerprint recognition.
1.3 Apply network security measures
Ensure network security with Security with HTTPS and SSL — For any kind of network communication we must use HTTPS (instead of plain http) with proper certificate implementation. This section describes how we can improve our application’s network security.
1.3.1 Use SSL traffic
If our application communicates with a web server that has a certificate issued by a well-known, trusted CA, the HTTPS request is very simple:
val url = URL("https://www.google.com")
val urlConnection = url.openConnection() as HttpsURLConnection
urlConnection.connect()
urlConnection.inputStream.use {
...
}
1.3.2 Add a network security configuration
If our application uses new or custom CAs, we can declare our network’s security settings in a configuration file. This process allows us to create the configuration without modifying any application code.
To add a network security configuration file to our application, we can follow these steps:
Declare the configuration in our application’s manifest:
<manifest ... >
<application
android:networkSecurityConfig="@xml/network_security_config"
... >
<!-- Place child elements of <application> element here. -->
</application>
</manifest>
2. We add an XML resource file, located at res/xml/network_security_config.xml.
Specify that all traffic to particular domains should use HTTPS by disabling clear-text:
During the development process, we can use the <debug-overrides> element to explicitly allow user-installed certificates. This element overrides our application’s security-critical options during debugging and testing without affecting the application’s release configuration.
The following snippet shows how to define this element in our application’s network security configuration XML file:
Our SSL checker shouldn’t accept every certificate. We may need to set up a trust manager and handle all SSL warnings that occur if one of the following conditions applies to our use case:
We’re communicating with a web server that has a certificate signed by a new or custom CA.
That CA isn’t trusted by the device we’re using.
You cannot use a network security configuration.
1.4 Use WebView objects carefully
Whenever possible, we load only allowlisted content in WebView objects. In other words, the WebView objects in our application shouldn’t allow users to navigate to sites that are outside of our control. In addition, we should never enable JavaScript interface support unless we completely control and trust the content in our application’s WebView objects.
1.4.1 Use HTML message channels
If our application must use JavaScript interface support on devices running Android 6.0 (API level 23) and higher, use HTML message channels instead of communicating between a website and your app, as shown in the following code snippet:
val myWebView: WebView = findViewById(R.id.webview)
// channel[0] and channel[1] represent the two ports.
// They are already entangled with each other and have been started.
val channel: Array<out WebMessagePort> = myWebView.createWebMessageChannel()
// Create handler for channel[0] to receive messages.
channel[0].setWebMessageCallback(object : WebMessagePort.WebMessageCallback() {
override fun onMessage(port: WebMessagePort, message: WebMessage) {
Log.d(TAG, "On port $port, received this message: $message")
}
})
// Send a message from channel[1] to channel[0].
channel[1].postMessage(WebMessage("My secure message"))
2. Provide the right permissions
Application should request only the minimum number of permissions necessary to function properly.
2.1 Use intents to defer permissions
It should not add a permission to complete an action that could be completed in another application. Instead, we use an intent to defer the request to a different application that already has the necessary permission.
For example, If an application requires to create a contact to a contact application, it delegates the responsibility of creating the contact to a contacts application, which has already been granted the appropriate WRITE_CONTACTS permission.
// Delegates the responsibility of creating the contact to a contacts application,
// which has already been granted the appropriate WRITE_CONTACTS permission.
Intent(Intent.ACTION_INSERT).apply {
type = ContactsContract.Contacts.CONTENT_TYPE
}.also { intent ->
// Make sure that the user has a contacts application installed on their device.
intent.resolveActivity(packageManager)?.run {
startActivity(intent)
}
}
In addition, if our application needs to perform file-based I/O – such as accessing storage or choosing a file – it doesn’t need special permissions because the system can complete the operations on our application’s behalf. Better still, after a user selects content at a particular URI, the calling application gets granted permission to the selected resource.
2.2 Share data securely across applications
We can follow these best practices in order to share our application’s content with other applications in a more secure manner:
Enforce read-only or write-only permissions as needed.
Provide clients one-time access to data by using the FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flags.
When sharing data, we use “content://” URIs, not “file://” URIs. Instances of FileProvider do this for us.
The following code snippet shows how to use URI permission grant flags and content provider permissions to display an application’s PDF file in a separate PDF Viewer application:
// Create an Intent to launch a PDF viewer for a file owned by this application.
Intent(Intent.ACTION_VIEW).apply {
data = Uri.parse("content://com.example/personal-info.pdf")
// This flag gives the started application read access to the file.
addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
}.also { intent ->
// Make sure that the user has a PDF viewer application installed on their device.
intent.resolveActivity(packageManager)?.run {
startActivity(intent)
}
}
3. Store data safely
Although our application might require access to sensitive user information, our users will grant our application access to their data only if they trust that we’ll safeguard it properly.
3.1 Store private data within internal storage
We need to store all private user data within the device’s internal storage, which is sandboxed per application. Our application doesn’t need to request permission to view these files, and other applications cannot access the files. As an added security measure, when the user uninstalls an app, the device deletes all files that the app saved within internal storage.
We consider working with EncryptedFile objects if storing data is particularly sensitive or private. These objects are available from Security library instead of File objects.
For Example, one way to write data to storage demonstrates in the below code snippet:
// Although you can define your own key generation parameter specification, it's
// recommended that you use the value specified here.
val keyGenParameterSpec = MasterKeys.AES256_GCM_SPEC
val mainKeyAlias = MasterKeys.getOrCreate(keyGenParameterSpec)
// Create a file with this name, or replace an entire existing file
// that has the same name. Note that you cannot append to an existing file,
// and the file name cannot contain path separators.
val fileToWrite = "my_sensitive_data.txt"
val encryptedFile = EncryptedFile.Builder(
File(DIRECTORY, fileToWrite),
applicationContext,
mainKeyAlias,
EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB
).build()
val fileContent = "MY SUPER-SECRET INFORMATION"
.toByteArray(StandardCharsets.UTF_8)
encryptedFile.openFileOutput().apply {
write(fileContent)
flush()
close()
}
Another example shows the inverse operation, reading data from storage:
// Although you can define your own key generation parameter specification, it's
// recommended that you use the value specified here.
val keyGenParameterSpec = MasterKeys.AES256_GCM_SPEC
val mainKeyAlias = MasterKeys.getOrCreate(keyGenParameterSpec)
val fileToRead = "my_sensitive_data.txt"
val encryptedFile = EncryptedFile.Builder(
File(DIRECTORY, fileToRead),
applicationContext,
mainKeyAlias,
EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB
).build()
val inputStream = encryptedFile.openFileInput()
val byteArrayOutputStream = ByteArrayOutputStream()
var nextByte: Int = inputStream.read()
while (nextByte != -1) {
byteArrayOutputStream.write(nextByte)
nextByte = inputStream.read()
}
val plaintext: ByteArray = byteArrayOutputStream.toByteArray()
3.2 Store data in external storage basedon use case
We consider external storage for large, non-sensitive files that are specific to our application, as well as files that our application shares with other applications. The specific APIs that we use depend on whether our application is designed to access app-specific files or access shared files.
3.2.1 Check availability of storage volume
When user interacts with a removable external storage device from the application, then he might remove the storage device while our app is trying to access it. We need to include logic to verify that the storage device is available.
3.2.2 Access application-specific files
If a file doesn’t contain private or sensitive information but provides value to the user only in our application, we store the file in an application-specific directory on external storage.
3.2.3 Access shared files
If our application needs to access or store a file that provides value to other applications, we can use one of the following APIs depending on our use case:
Media files: To store and access images, audio files, and videos that are shared between apps, use the Media Store API.
Other files: To store and access other types of shared files, including downloaded files, use the Storage Access Framework.
3.2.4 Check validity of data
If our application uses data from external storage, make sure that the contents of the data haven’t been corrupted or modified. Our application should also include logic to handle files that are no longer in a stable format.
We take an example of hash verifier in below code snippet:
val hash = calculateHash(stream)
// Store "expectedHash" in a secure location.
if (hash == expectedHash) {
// Work with the content.
}
// Calculating the hash code can take quite a bit of time, so it shouldn't
// be done on the main thread.
suspend fun calculateHash(stream: InputStream): String {
return withContext(Dispatchers.IO) {
val digest = MessageDigest.getInstance("SHA-512")
val digestStream = DigestInputStream(stream, digest)
while (digestStream.read() != -1) {
// The DigestInputStream does the work; nothing for us to do.
}
digest.digest().joinToString(":") { "%02x".format(it) }
}
}
3.3 Store only non-sensitive data in cache files
To provide quicker access to non-sensitive application data, we store it in the device’s cache. For caches larger than 1 MB in size, we use getExternalCacheDir() otherwise, use getCacheDir(). Each method provides the File object that contains our application’s cached data.
Let’s take one example code snippet that shows how to cache a file that application recently downloaded:
val cacheFile = File(myDownloadedFileUri).let { fileToCache ->
File(cacheDir.path, fileToCache.name)
}
If we use use getExternalCacheDir() to place our application’s cache within shared storage, the user might eject the media containing this storage while our application run. We should include logic to gracefully handle the cache miss that this user behavior causes.
3.4 Use SharedPreferences in private mode
When we are using getSharedPreferences() to create or access our application’s SharedPreferences objects, use MODE_PRIVATE. That way, only our application can access the information within the shared preferences file.
Moreover, EncryptedSharedPreferences should be used for more security which wraps the SharedPreferences class and automatically encrypts keys and values.
4. Keep services and dependencies up-to-date
Most applications use external libraries and device system information to complete specialized tasks. By keeping our app’s dependencies up to date, we make these points of communication more secure.
4.1 Check the Google Play services security provider
If our application uses Google Play services, make sure that it’s updated on the device where our application is installed. This check should be done asynchronously, off of the UI thread. If the device isn’t up-to-date, our application should trigger an authorization error.
4.2 Update all application dependencies
Before deploying our application, make sure that all libraries, SDKs, and other dependencies are up to date:
For first-party dependencies, such as the Android SDK, we use the updating tools found in Android Studio, such as the SDK Manager.
For third-party dependencies, we check the websites of the libraries that our app uses, and install any available updates and security patches.
In this article, we understood about the best practices of Application Security in Android. This article explained about few best practices that every mobile app developer must follow to secure the application from vulnerability. This helps us to develop the highly secure applications required to prevent valuable user information of our application and maintain the trust of our client.
Thanks for reading! I hope you enjoyed and learned about the best practices of Application Security concepts in Android. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find other articles of CoolMonkTechie as below link :
Hello Readers, CoolMonkTechie heartily welcomes you in A Short Note Series (An Overview Of Functions Currying In Kotlin).
In this note series, We will understand about Functions Currying in Kotlin. Currying is a common technique in functional programming. It allows transforming a given function that takes multiple arguments into a sequence of functions, each having a single argument.
In this short note series, we are going to implement an automatic currying mechanism that could be applied to any function taking three parameters.
So Let’s begin.
Overview
We can understand Currying as :
A common technique in functional programming.
Transforming a given function that takes multiple arguments into a sequence of functions, each having a single argument.
Each of the resulting functions handles one argument of the original (uncurried) function and returns another function.
To understand the concept of functions currying, let’s consider the following example of a function handling three parameters:
fun foo(a: A, b: B, c: C): D
Its curried form would like this :
fun carriedFoo(a: A): (B) -> (C) -> D
In other words, the curried form of the foo function would take a single argument of the A type and return another function of the following type: (B) -> (C) -> D. The returned function is responsible for handling the second argument of the original function and returns another function, which takes the third argument and returns a value of type D.
How To Implement it ?
In this section, we are going to implement the curried() extension function for the generic functional type declared as follows: ((P1, P2, P3). The curried() function is going to return a chain of single-argument functions and will be applicable to any function which takes three arguments.
Here, we can implement Functions Currying with the below steps :
Step 1 –Declare a header of the curried() function :
Let’s explore how to use the curried() function in action. In the following example, we are going to call curried() on the following function instance which is responsible for computing a sum of three integers:
fun sum(a: Int, b: Int, c: Int): Int = a + b + c
In order to obtain a curried form of the sum() function, we have to invoke the curried() function on its reference:
::sum.curried()
Then we can invoke the curried sum function in the following way:
val result: Int = ::sum.curried()(1)(2)(3)
Here, the result variable is going to be assigned an integer value equal to 6.
In order to invoke the curried() extension function, we access the sum() function reference using the :: modifier. Then we invoke the next functions from the function sequence returned by the curried function one by one.
The preceding code could be written in an equivalent more verbose form with explicit types declarations:
val sum3: (a: Int) -> (b: Int) -> (c: Int) -> Int = ::sum.curried()
val sum2: (b: Int) -> (c: Int) -> Int = sum3(1)
val sum1: (c: Int) -> Int = sum2(2)
val result: Int = sum1(3)
Under the hood, the currying mechanism implementation is just returning functions nested inside each other. Every time the specific function is invoked, it returns another function with the arity reduced by one.
Conclusion
In this note series, we understood about Functions Currying in Kotlin. Currying is useful whenever we can’t provide the full number of required arguments to the function in the current scope. We can apply only the available ones to the function and return the transformed function.
Thanks for reading! I hope you enjoyed and learned about Functions Currying in Kotlin. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe us on this blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find Other articles of CoolmonkTechie as below link :
Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Implement Automatic Functions Memoization Technique in Kotlin ?).
In this article, we will learn about how to implement Automatic Functions Memoization Technique in Kotlin. Memoization is a technique used to optimize the program-execution speed by caching the results of expensive function calls and reusing their ready values when they are required again. Although memoization causes an obvious trade-off between memory usage and computation time, often it’s crucial to provide the desired performance. This article explains about Automatic Functions Memoization Technique work flows in Kotlin.
To understand the Automatic Functions Memoization Technique in Kotlin, we cover the below topics as below :
Overview
How to Implement Technique?
How Technique Works?
A famous quote about learning is :
“That is what learning is. You suddenly understand something you’ve understood all your life, but in a new way.”
So Let’s begin.
Overview
We can understand about Memoization as:
A technique used to optimize the program-execution speed by caching the results of expensive function calls and reusing their ready values when they are required again.
An obvious trade-off between memory usage and computation time, often it’s crucial to provide the desired performance. Usually, we apply this pattern to computationally-expensive functions.
It can help to optimize recursive functions that call themselves multiple times with the same parameters values.
Memoization can easily be added internally to function implementation. However, in this article, we are going to create a general-purpose, reusable memoization mechanism that could be applied to any function.
How to Implement Technique?
In this section, We will understand how to implement it and What steps are required for implementation.
Step 1 – Declare a Memoizer class responsible for caching the results:
class Memoizer<P, R> private constructor() {
private val map = ConcurrentHashMap<P, R>()
private fun doMemoize(function: (P) -> R):
(P) -> R = { param: P ->
map.computeIfAbsent(param) { param: P ->
function(param)
}
}
companion object {
fun <T, U> memoize(function: (T) -> U):
(T) -> U =
Memoizer<T, U>().doMemoize(function)
}
}
Step 2 – Provide a memoized() extension function for the (P) -> R function type:
fun <P, R> ((P) -> R).memoized(): (P) -> R = Memoizer.memoize<P, R>(this)
How Technique Works?
The memoize() function takes an instance of a one-argument function as its argument. The Memoizer class contains the ConcurrentHashmap<P, R> instance, which is used to cache the function’s return values. The map stores functions passed to memoize() as arguments as the keys, and it puts their return values as its values.
First, the memoize() function looks up the value for a specific parameter of the function passed as an argument. If the value is present in the map, it is returned. Otherwise, the function is executed and its result is returned by memoize() and put into the map. This is achieved using the handy inline fun <K, V> ConcurrentMap<K, V>.computeIfAbsent(key: K, defaultValue: () -> V): V extension function provided by the standard library.
Additionally, we can provide an extension function, memoized(), for the Function1 type, which will allow us to apply the memoize() function directly to the function references.
Note that the under the hood functions in Kotlin are compiled to the FunctionN interface instances in the Java bytecode, where N corresponds to the number of function arguments. We can declare an extension function for a function. For example, in order to add an extension function for a function taking two arguments, (P, Q) -> R, we need to define an extension as fun <P, Q, R> Function2<P, Q, R>.myExtension(): MyReturnType.
Now, take a look at how we can benefit from the memoized() function in action. Consider a function that computes the factorial of an integer recursively:
fun factorial(n: Int): Long = if (n == 1) n.toLong() else n * factorial(n - 1)
We can apply the memoized() extension function to enable caching of the results:
As we can see, even though the second computation requires a higher number of recursive calls of the factorial() function, it takes much less time than the first computation.
We can implement similar automatic memoization implementations for other functions that take more than one argument. In order to declare an extension function for a function taking N arguments, we’d have to implement an extension function for the FunctionN type.
In this article, we understood about how to implement Automatic Functions Memoization Technique in Kotlin. This article explained about Automatic Functions Memoization Techniquework flows in Kotlin.
Thanks for reading! I hope you enjoyed and learned about Automatic Functions Memoization Technique concepts in Kotlin. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find other articles of CoolMonkTechie as below link :
Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Implement Either Monad Design Pattern in Kotlin ?).
In this article, we will learn about how to implement Either Monad Design Pattern in Kotlin. The concept of Monad is one of the fundamental functional programming design patterns. We can understand a Monad as an encapsulation for a data type that adds a specific functionality to it or provides custom handlers for different states of the encapsulated object.
One of the most commonly used is a Maybe monad. The Maybe monad is supposed to provide information about the enclosed property presence. It can return an instance of the wrapped type whenever it’s available or nothing when it’s not. Java 8 introduced the Optional class, which is implementing the Maybe concept. It’s a great way to avoid operating on null values. This article explains about Either Monad Design Pattern work flows in Kotlin.
To understand the Either Monad Design Pattern in Kotlin, we cover the below topics as below :
Overview
Pattern Implementation Steps
How Pattern Works ?
A famous quote about learning is :
” The beautiful thing about learning is that nobody can take it away from you.”
So Let’s begin.
Overview
We can understand about Either Monad Design Pattern as:
A fundamental functional programming design patterns and,
Consider a Monad as an encapsulation for a data type that adds a specific functionality or provides custom handlers for different states of the encapsulated object.
However, apart from having the information about the unavailable state, we would often like to be able to provide some additional information. For example, if the server returns an empty response, it would be useful to get an error code or a message instead of the null or an empty response string. This is a scenario for another type of Monad, usually called Either, which we are going to implement in this article.
Pattern Implementation Steps
In this section, We will understand how to implement it and What steps are required for implementation.
Step 1 – Declare Either as a sealed class
sealed class Either<out E, out V>
Step 2 – Add two subclasses of Either, representing Error and Value:
sealed class Either<out L, out R> {
data class Left<out L>(val left: L) : Either<L, Nothing>()
data class Right<out R>(val right: R) : Either<Nothing, R>()
}
Step 3 – Add factory functions to conveniently instantiate Either:
sealed class Either<out L, out R> {
data class Left<out L>(val left: L) : Either<L, Nothing>()
data class Right<out R>(val right: R) : Either<Nothing, R>()
companion object {
fun <R> right(value: R): Either<Nothing, R> = Either.Right(value)
fun <L> left(value: L): Either<L, Nothing> = Either.Left(value)
}
}
How Pattern Works ?
In order to make use of the class Either and benefit from the Either.right() and Either.left() methods, we can implement a getEither() function that will try to perform some operation passed to it as a parameter. If the operation succeeds, it is going to return the Either.Right instance holding the result of the operation, otherwise, it is going to return Either.Left, holding a thrown exception instance:
By convention, we can use the Either.Right type to provide a default value and Either.Left to handle any possible edge cases.
One essential functional programming feature the Either Monad can provide is the ability to apply functions to its values. We can simply extend the Either class with the fold() function, which can take two functions as the parameters. The first function should be applied to the Either.Left type and the second should be applied to Either.Right:
sealed class Either<out L, out R> {
data class Left<out L>(val left: L) : Either<L, Nothing>()
data class Right<out R>(val right: R) : Either<Nothing, R>()
fun <T> fold(leftOp: (L) -> T, rightOp: (R) -> T): T = when (this) {
is Left -> leftOp(this.left)
is Right -> rightOp(this.right)
}
//…
}
The fold() function will return a value from either the leftOp or rightOp function, whichever is used. The usage of the fold() function can be illustrated with a server-request parsing example.
Suppose we have the following types declared:
data class Response(val json: JsonObject)
data class ErrorResponse(val code: Int, val message: String)
And we have also a function responsible for delivering a backend response:
fun someGetRequest(): Either<ErrorResponse, Response> = //..
We can use the fold() function to handle the returned value in the right way:
We can also extend the Either class with other useful functions, like the ones available in the standard library for data-processing operations—map, filter, and exists.
In this article, we understood about how to implement Either Monad Design Pattern in Kotlin. This article explained about Either Monad Design Pattern work flows in Kotlin.
Thanks for reading! I hope you enjoyed and learned about Either Monad Design Pattern concepts in Kotlin. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find other articles of CoolMonkTechie as below link :
Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Schedule Tasks With WorkManager ?).
In this article, we will learn about how to schedule tasks with WorkManager. WorkManager is an API that makes it easy to schedule deferrable, asynchronous tasks that are expected to run even if the app exits or the device restarts. The WorkManager API is a suitable and recommended replacement for all previous Android background scheduling APIs, including FirebaseJobDispatcher, GcmNetworkManager, and Job Scheduler. WorkManager incorporates the features of its predecessors in a modern, consistent API that works back to API level 14 while also being conscious of battery life. This article explains about WorkManager workflow and advantages in Android application.
To understand the WorkManager in Android, we cover the below topics as below :
What is WorkManager?
Why use WorkManager ?
Features of WorkManager
When to use WorkManager?
How WorkManager works?
WorkManager implementation demo application to Schedule Tasks
Demo application output
A famous quote about learning is :
” There is no end to education. It is not that you read a book, pass an examination, and finish with education. The whole of life, from the moment you are born to the moment you die, is a process of learning. “
So Let’s begin.
What is WorkManager ?
“WorkManager is a background processing library which is used to execute background tasks which should run in a guaranteed way but not necessarily immediately.”
“WorkManager is a task scheduler that makes it easy to specify the asynchronous task easily and when they should run. The WorkManager API helps create the task and hand it to the Work Manager to run immediately or at an appropriate time as mentioned. “
With WorkManager, we can enqueue our background processing even when the app is not running and the device is rebooted for some reason. WorkManager also lets us define constraints necessary to run the task e.g. network availability before starting the background task.
For example, we might point our app to download new resources from the network from time to time and now the downloading is a task and we can set up this task to run at an appropriate time depending on the availability of the WIFI network or when the device is charging. So this way we can schedule a task using WorkManager.
WorkManager is a part of Android Jetpack (a suite of libraries to guide developers to write quality apps) and is one of theAndroid Architecture Components (collection of components that help developers design robust, testable, and easily maintainable apps).
If our app targets Android 10 (API level 29) or above, our FirebaseJobDispatcher and GcmNetworkManager API calls will no longer work on devices running Android Marshmallow (6.0) and above.
Why use WorkManager ?
Since Marshmallow, The Android development team is continuously working on battery optimizations. After that team introduced Doze mode. Then in Oreo imposed various kind of limitation on performing background jobs. Before WorkManager, we use various job scheduler for performing background task, such as Firebase JobDispatcher, Job Scheduler and Alarm Manager + Broadcast receivers. So for the developer perspective, it is difficult to choose which scheduler should use and which one is good. So the Work Manager handles these kinds of stuff. We have to pass the task to the WorkManager and It uses all this Firebase Job Dispatcher, Alarm Manager + Broadcast Receivers, Job Scheduler to perform the background task depending on the requirement.
Features of WorkManager
In addition to providing a simpler and consistent API, WorkManager has a number of other key benefits, including:
Work Constraints
Declaratively define the optimal conditions for our work to run using Work Constraints. (For example, run only when the device is Wi-Fi, when the device idle, or when it has sufficient storage space, etc.)
Robust Scheduling
WorkManager allows us to schedule work to run one- time or repeatedly using flexible scheduling windows. Work can be tagged and named as well, allowing us to schedule unique, replaceable work and monitor or cancel groups of work together. Scheduled work is stored in an internally managed SQLite database and WorkManager takes care of ensuring that this work persists and is rescheduled across device reboots. In addition, WorkManager adheres to power-saving features and best practices like Doze mode, so we don’t have to worry about it.
Flexible Retry Policy
WorkManager offers flexible retry policies, including a configurable exponential backoff policy, if work fails.
Work Chaining
For complex related work, chain individual work tasks together using a fluent, natural, interface that allows us to control which pieces run sequentially and which run in parallel. For each work task, we can define input and output data for that work. When chaining work together, WorkManager automatically passes output data from one work task to the next.
Built-In Threading Interoperability
WorkManager integrates seamlessly with RxJava and Coroutines and provides the flexibility to plug in our own asynchronous APIs.
When to use WorkManager?
WorkManager handles background work that needs to run when various constraints are met, regardless of whether the application process is alive or not. Background work can be started when the app is in the background, when the app is in the foreground, or when the app starts in the foreground but goes to the background. Regardless of what the application is doing, background work should continue to execute, or be restarted if Android kills its process.
A common confusion about WorkManager is that it’s for tasks that needs to be run in a “background” thread but don’t need to survive process death. This is not the case. There are other solutions for this use case like Kotlin’s coroutines, ThreadPools, or libraries like RxJava. There are many different situations in which we need to run background work, and therefore different solutions for running background work.
WorkManager can be a perfect background processing library to use in android when our task:
Does not need to run at a specific time
Can be deferred to be executed
Is guaranteed to run even after the app is killed or device is restarted
Has to meet constraints like battery supply or network availability before execution
The simplest example can be when our app needs to upload a large chunk of user data to the server. This particular use case meets the criteria we mentioned above to choose WorkManager because:
Results need not be reflected immediately in our Android app
Data needs to be uploaded even when the upload begins and the user kills the app to work on some other app, and
The network needs to be available in order to upload data on the server.
How WorkManager Works ?
In this section, we will understand the class and concept of WorkManager. Let’s understand what are various base classes that are used for Job Scheduling.
Worker
Work is defined using the Worker class. It specifies what task to perform. The WorkManager API include an abstract Worker class and we need to extends this class and perform the work.
WorkRequest
WorkRequest represents an individual task that is to be performed. Now this WorkRequest, we can add values details for the work. Such as constraint or we can also add data while creating the request.
WorkRequest can be of to type :
OneTimeWorkRequest– That means we requesting for non-repetitive work.
PeriodicWorkRequest– This class is used for creating a request for repetitive work.
WorkManager
The WorkManager class in enqueues and manages all the work request. We pass work request object to this WorkManager to enqueue the task.
WorkInfo
WorkInfo contains the information about a particular task, The WorkManager provides LiveData for each of the work request objects, We can observe this and get the current status of the task.
WorkManager Implementation Demo Application to Schedule Tasks
In this section, we will discuss the below steps for implement WorkManager to schedule task with authentic android demo application :
Add WorkManager dependency in app/buid.gradle file
Create Layout
Add a base class of Worker
Create WorkRequest
Enqueue the request with WorkManager
Fetch the particular task status
1. Add WorkManager dependency in app/buid.gradle file
For using WorkManager we have to add dependency in app/build.gradle file. So let’s open the app build.gradle file and add below lines.
In this step, we will create a layout. This layout will contain TextView and Button. After that, we will set onClickListener() and this event will enqueue the WorkRequest to WorkManager and shows the status on TextView.
In this step, we create a base class of Worker class and override un-implemented methods and super constructor.
NotificationWorker.kt
package com.coolmonktechie.android.workmanagerdemo
import android.app.NotificationChannel
import android.app.NotificationManager
import android.content.Context
import android.os.Build
import androidx.core.app.NotificationCompat
import androidx.work.Data
import androidx.work.Worker
import androidx.work.WorkerParameters
class NotificationWorker(context: Context, workerParams: WorkerParameters) :
Worker(context, workerParams) {
override fun doWork(): Result {
val taskData = inputData
val taskDataString = taskData.getString(MainActivity.MESSAGE_STATUS)
showNotification("WorkManager", "Message has been Sent")
val outputData = Data.Builder().putString(WORK_RESULT, "Jobs Finished").build()
return Result.success(outputData)
}
private fun showNotification(task: String, desc: String) {
val manager =
applicationContext.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
val channelId = "task_channel"
val channelName = "task_name"
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
val channel =
NotificationChannel(channelId, channelName, NotificationManager.IMPORTANCE_DEFAULT)
manager.createNotificationChannel(channel)
}
val builder = NotificationCompat.Builder(applicationContext, channelId)
.setContentTitle(task)
.setContentText(desc)
.setSmallIcon(R.mipmap.ic_launcher)
manager.notify(1, builder.build())
}
companion object {
private const val WORK_RESULT = "work_result"
}
}
4. Create WorkRequest
Let’s move to MainActivity and create a WorkRequest to execute the work that we just created. Now first we will create WorkManager. This work manager will enqueue and manage our work request.
var mWorkManager:WorkManager = WorkManager.getInstance()
Now we will create OneTimeWorkRequest, because we want to create a task that will be executed just once.
var mRequest: OneTimeWorkRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java).build()
Using this code, we built work request that will be executed one time only.
5. Enqueue the request with WorkManager
In this step, we discuss onClick() of the button. we will enqueue this request using the WorkManager. So that’s all we need to do.
mWorkManager!!.enqueue(mRequest!!)
6. Fetch the particular task status
In this steps, we will fetch some information about this particular task and display it on tvStatus TextView. We will do that using WorkInfo class. The work manager provides LiveData for each of the work request objects, We can observe this and get the current status of the task.
mWorkManager!!.getWorkInfoByIdLiveData(mRequest!!.id).observe(this, { workInfo ->
if (workInfo != null) {
val state = workInfo.state
tvStatus!!.append(
"""
$state
""".trimIndent()
)
}
})
Finally, the full source code of MainActivity.kt looks like this:
package com.coolmonktechie.android.workmanagerdemo
import android.os.Build
import android.os.Bundle
import android.view.View
import android.widget.Button
import android.widget.TextView
import androidx.appcompat.app.AppCompatActivity
import androidx.work.Constraints
import androidx.work.NetworkType
import androidx.work.OneTimeWorkRequest
import androidx.work.WorkManager
import com.sunilmishra.android.workmanagerdemo.NotificationWorker
class MainActivity : AppCompatActivity(), View.OnClickListener {
var tvStatus: TextView? = null
var btnSend: Button? = null
var btnStorageNotLow: Button? = null
var btnBatteryNotLow: Button? = null
var btnRequiresCharging: Button? = null
var btnDeviceIdle: Button? = null
var btnNetworkType: Button? = null
var mRequest: OneTimeWorkRequest? = null
var mWorkManager: WorkManager? = null
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
initViews()
tvStatus = findViewById(R.id.tvStatus)
btnSend = findViewById(R.id.btnSend)
mWorkManager = WorkManager.getInstance()
}
private fun initViews() {
tvStatus = findViewById(R.id.tvStatus)
btnSend = findViewById(R.id.btnSend)
btnStorageNotLow = findViewById(R.id.buttonStorageNotLow)
btnBatteryNotLow = findViewById(R.id.buttonBatteryNotLow)
btnRequiresCharging = findViewById(R.id.buttonRequiresCharging)
btnDeviceIdle = findViewById(R.id.buttonDeviceIdle)
btnNetworkType = findViewById(R.id.buttonNetworkType)
btnSend!!.setOnClickListener(this)
btnStorageNotLow!!.setOnClickListener(this)
btnBatteryNotLow!!.setOnClickListener(this)
btnRequiresCharging!!.setOnClickListener(this)
btnDeviceIdle!!.setOnClickListener(this)
btnNetworkType!!.setOnClickListener(this)
}
override fun onClick(v: View) {
tvStatus!!.text = ""
val mConstraints: Constraints
when (v.id) {
R.id.btnSend -> mRequest =
OneTimeWorkRequest.Builder(NotificationWorker::class.java).build()
R.id.buttonStorageNotLow -> {
/**
* Constraints
* If TRUE task execute only when storage's is not low
*/
mConstraints = Constraints.Builder().setRequiresStorageNotLow(true).build()
/**
* OneTimeWorkRequest with requiresStorageNotLow Constraints
*/
mRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java)
.setConstraints(mConstraints).build()
}
R.id.buttonBatteryNotLow -> {
/**
* Constraints
* If TRUE task execute only when battery isn't low
*/
mConstraints = Constraints.Builder().setRequiresBatteryNotLow(true).build()
/**
* OneTimeWorkRequest with requiresBatteryNotLow Constraints
*/
mRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java)
.setConstraints(mConstraints).build()
}
R.id.buttonRequiresCharging -> {
/**
* Constraints
* If TRUE while the device is charging
*/
mConstraints = Constraints.Builder().setRequiresCharging(true).build()
/**
* OneTimeWorkRequest with requiresCharging Constraints
*/
mRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java)
.setConstraints(mConstraints).build()
}
R.id.buttonDeviceIdle -> if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
/**
* Constraints
* If TRUE while the device is idle
*/
mConstraints = Constraints.Builder().setRequiresDeviceIdle(true).build()
/**
* OneTimeWorkRequest with requiresDeviceIdle Constraints
*/
mRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java)
.setConstraints(mConstraints).build()
}
R.id.buttonNetworkType -> {
/**
* Constraints
* Network type is conneted
*/
mConstraints =
Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build()
/**
* OneTimeWorkRequest with requiredNetworkType Connected Constraints
*/
mRequest = OneTimeWorkRequest.Builder(NotificationWorker::class.java)
.setConstraints(mConstraints).build()
}
else -> {
}
}
/**
* Fetch the particular task status using request ID
*/
mWorkManager!!.getWorkInfoByIdLiveData(mRequest!!.id).observe(this, { workInfo ->
if (workInfo != null) {
val state = workInfo.state
tvStatus!!.append(
"""
$state
""".trimIndent()
)
}
})
/**
* Enqueue the WorkRequest
*/
mWorkManager!!.enqueue(mRequest!!)
}
companion object {
const val MESSAGE_STATUS = "message_status"
}
}
Demo Application Output
In this section, we will see the demo application output screen as below. We click on Send Notification button. The Job status will show on TextView.
In this article, we understood about how to schedule tasks with WorkManager. This article explained about WorkManager workflow and advantages in Android application.
Thanks for reading! I hope you enjoyed and learned about WorkManager concepts in Android. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find other articles of CoolMonkTechie as below link :
Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Run Android Tasks In Background Threads ?).
In this article, we will learn about how to run android tasks in background threads. All Android apps use a main thread to handle UI operations. Calling long-running operations from this main thread can lead to freezes and unresponsiveness. For example, if our app makes a network request from the main thread, our app’s UI is frozen until it receives the network response. We can create additional background threads to handle long-running operations while the main thread continues to handle UI updates.
This article shows both Kotlin and Java Programming Language developers to use of a thread pool to set up and use multiple threads in an Android app. It also explains code definitions to run on a thread and communications between one of these threads and the main thread.
A famous quote about learning is :
” That is what learning is. You suddenly understand something you’ve understood all your life, but in a new way. “
So Let’s begin.
Overview
In this example section, we will make a network request and return the result to the main thread, where the app then might display that result on the screen. Specifically, the ViewModel calls the repository layer on the main thread to trigger the network request. The repository layer is in charge of moving the execution of the network request off the main thread and posting the result back to the main thread using a callback.
To move the execution of the network request off the main thread, we need to create other threads in our app.
Creating Multiple Threads
A thread pool is a managed collection of threads that runs tasks in parallel from a queue. New tasks are executed on existing threads as those threads become idle. To send a task to a thread pool, use the ExecutorService interface. Note that ExecutorService has nothing to do with Services, the Android application component.
Creating threads is expensive, so we should create a thread pool only once as our app initializes. Be sure to save the instance of the ExecutorService either in our Applicationclass or in a dependency injection container. The following example creates a thread pool of four threads that we can use to run background tasks.
class MyApplication : Application() {
val executorService: ExecutorService = Executors.newFixedThreadPool(4)
}
Executing In A Background Thread
Making a network request on the main thread causes the thread to wait, or block, until it receives a response. Since the thread is blocked, the OS can’t call onDraw(), and our app freezes, potentially leading to an Application Not Responding (ANR) dialog. Instead, let’s run this operation on a background thread.
First, let’s take a look at our Repository class and see how it’s making the network request:
sealed class Result<out R> {
data class Success<out T>(val data: T) : Result<T>()
data class Error(val exception: Exception) : Result<Nothing>()
}
class LoginRepository(private val responseParser: LoginResponseParser) {
private const val loginUrl = "https://example.com/login"
// Function that makes the network request, blocking the current thread
fun makeLoginRequest(
jsonBody: String
): Result<LoginResponse> {
val url = URL(loginUrl)
(url.openConnection() as? HttpURLConnection)?.run {
requestMethod = "POST"
setRequestProperty("Content-Type", "application/json; charset=utf-8")
setRequestProperty("Accept", "application/json")
doOutput = true
outputStream.write(jsonBody.toByteArray())
return Result.Success(responseParser.parse(inputStream))
}
return Result.Error(Exception("Cannot open HttpURLConnection"))
}
}
makeLoginRequest() is synchronous and blocks the calling thread. To model the response of the network request, we have our own Result class.
The ViewModel triggers the network request when the user taps, for example, on a button:
class LoginViewModel(
private val loginRepository: LoginRepository
) {
fun makeLoginRequest(username: String, token: String) {
val jsonBody = "{ username: \"$username\", token: \"$token\"}"
loginRepository.makeLoginRequest(jsonBody)
}
}
With the previous code, LoginViewModel is blocking the main thread when making the network request. We can use the thread pool that we’ve instantiated to move the execution to a background thread. First, following the principles of dependency injection, LoginRepository takes an instance of Executor as opposed to ExecutorService because it’s executing code and not managing threads:
class LoginRepository(
private val responseParser: LoginResponseParser
private val executor: Executor
) { ... }
The Executor’s execute() method takes a Runnable. A Runnable is a Single Abstract Method (SAM) interface with a run() method that is executed in a thread when invoked.
Let’s create another function called makeLoginRequest() that moves the execution to the background thread and ignores the response for now:
class LoginRepository(
private val responseParser: LoginResponseParser
private val executor: Executor
) {
fun makeLoginRequest(jsonBody: String) {
executor.execute {
val ignoredResponse = makeSynchronousLoginRequest(url, jsonBody)
}
}
private fun makeSynchronousLoginRequest(
jsonBody: String
): Result<LoginResponse> {
... // HttpURLConnection logic
}
}
Inside the execute() method, we create a new Runnable with the block of code, we want to execute in the background thread—in our case, the synchronous network request method. Internally, the ExecutorService manages the Runnable and executes it in an available thread.
In Kotlin, we can use a lambda expression to create an anonymous class that implements the SAM interface.
Considerations
Any thread in our app can run in parallel to other threads, including the main thread, so we should ensure that our code is thread-safe. Notice that in our example that we avoid writing to variables shared between threads, passing immutable data instead. This is a good practice, because each thread works with its own instance of data, and we avoid the complexity of synchronization.
If we need to share state between threads, we must be careful to manage access from threads using synchronization mechanisms such as locks. In general we should avoid sharing mutable state between threads whenever possible.
Communicating With The Main Thread
In the previous step, we ignored the network request response. To display the result on the screen, LoginViewModel needs to know about it. We can do that by using callbacks.
The function makeLoginRequest() should take a callback as a parameter so that it can return a value asynchronously. The callback with the result is called whenever the network request completes or a failure occurs. In Kotlin, we can use a higher-order function.
class LoginRepository(
private val responseParser: LoginResponseParser
private val executor: Executor
) {
fun makeLoginRequest(
jsonBody: String,
callback: (Result<LoginResponse>) -> Unit
) {
executor.execute {
try {
val response = makeSynchronousLoginRequest(jsonBody)
callback(response)
} catch (e: Exception) {
val errorResult = Result.Error(e)
callback(errorResult)
}
}
}
...
}
The ViewModel needs to implement the callback now. It can perform different logic depending on the result:
class LoginViewModel(
private val loginRepository: LoginRepository
) {
fun makeLoginRequest(username: String, token: String) {
val jsonBody = "{ username: \"$username\", token: \"$token\"}"
loginRepository.makeLoginRequest(jsonBody) { result ->
when(result) {
is Result.Success<LoginResponse> -> // Happy path
else -> // Show error in UI
}
}
}
}
In this example, the callback is executed in the calling thread, which is a background thread. This means that we cannot modify or communicate directly with the UI layer until we switch back to the main thread.
To communicate with the View from the ViewModel layer, use LiveData as recommended in the updated app architecture. If the code is being executed on a background thread, we can call MutableLiveData.postValue() to communicate with the UI layer.
Using Handlers
We can use a Handler to enqueue an action to be performed on a different thread. To specify the thread on which to run the action, construct the Handler using a Looper for the thread. A Looper is an object that runs the message loop for an associated thread. Once we’ve created a Handler, we can then use the post(Runnable) method to run a block of code in the corresponding thread.
Looper includes a helper function, getMainLooper(), which retrieves the Looper of the main thread. We can run code in the main thread by using this Looper to create a Handler. As this is something we might do quite often, we can also save an instance of the Handler in the same place we saved the ExecutorService:
class MyApplication : Application() {
val executorService: ExecutorService = Executors.newFixedThreadPool(4)
val mainThreadHandler: Handler = HandlerCompat.createAsync(Looper.getMainLooper())
}
It’s a good practice to inject the handler to the Repository, as it gives us more flexibility. For example, in the future we might want to pass in a different Handler to schedule tasks on a separate thread. If we’re always communicating back to the same thread, we can pass the Handler into the Repository constructor, as shown in the following example.
class LoginRepository(
...
private val resultHandler: Handler
) {
fun makeLoginRequest(
jsonBody: String,
callback: (Result<LoginResponse>) -> Unit
) {
executor.execute {
try {
val response = makeSynchronousLoginRequest(jsonBody)
resultHandler.post { callback(response) }
} catch (e: Exception) {
val errorResult = Result.Error(e)
resultHandler.post { callback(errorResult) }
}
}
}
...
}
Alternatively, if we want more flexibility, we can pass in a Handler to each function:
class LoginRepository(...) {
...
fun makeLoginRequest(
jsonBody: String,
resultHandler: Handler,
callback: (Result<LoginResponse>) -> Unit
) {
executor.execute {
try {
val response = makeSynchronousLoginRequest(jsonBody)
resultHandler.post { callback(response) }
} catch (e: Exception) {
val errorResult = Result.Error(e)
resultHandler.post { callback(errorResult) }
}
}
}
}
In this example, the callback passed into the Repository’s makeLoginRequest call is executed on the main thread. That means we can directly modify the UI from the callback or use LiveData.setValue() to communicate with the UI.
Configuring A Thread Pool
We can create a thread pool using one of the Executor helper functions with predefined settings, as shown in the previous example code. Alternatively, if we want to customize the details of the thread pool, we can create an instance using ThreadPoolExecutor directly. We can configure the following details:
Initial and maximum pool size
Keep alive time and time unit. Keep alive time is the maximum duration that a thread can remain idle before it shuts down.
An input queue that holds Runnable tasks. This queue must implement the BlockingQueue interface. To match the requirements of our app, we can choose from the available queue implementations.
Here’s an example that specifies thread pool size based on the total number of processor cores, a keep alive time of one second, and an input queue.
class MyApplication : Application() {
/*
* Gets the number of available cores
* (not always the same as the maximum number of cores)
*/
private val NUMBER_OF_CORES = Runtime.getRuntime().availableProcessors()
// Instantiates the queue of Runnables as a LinkedBlockingQueue
private val workQueue: BlockingQueue<Runnable> =
LinkedBlockingQueue<Runnable>()
// Sets the amount of time an idle thread waits before terminating
private const val KEEP_ALIVE_TIME = 1L
// Sets the Time Unit to seconds
private val KEEP_ALIVE_TIME_UNIT = TimeUnit.SECONDS
// Creates a thread pool manager
private val threadPoolExecutor: ThreadPoolExecutor = ThreadPoolExecutor(
NUMBER_OF_CORES, // Initial pool size
NUMBER_OF_CORES, // Max pool size
KEEP_ALIVE_TIME,
KEEP_ALIVE_TIME_UNIT,
workQueue
)
}
Concurrency Libraries
It’s important to understand the basics of threading and its underlying mechanisms. There are, however, many popular libraries that offer higher-level abstractions over these concepts and ready-to-use utilities for passing data between threads. These libraries include Guava and RxJava for the Java Programming Language users and coroutines, which we recommend for Kotlin users.
In practice, we should pick the one that works best for our app and our development team, though the rules of threading remain the same.
In this article, we understood about how to run android tasks in background threads. This article showed both Kotlin and Java Programming Language developers to use of a thread pool to set up and use multiple threads in an Android app. It also explained code definitions to run on a thread and communications between one of these threads and the main thread.
Thanks for reading! I hope you enjoyed and learned about RunningAndroid Tasks In Background Threads concepts. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find other articles of CoolMonkTechie as below link :
Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Select Scope Functions In Kotlin?).
In this article, we will learn about how to select Scope Functions in Kotlin. The Kotlin standard library contains several functions whose sole purpose is to execute a block of code within the context of an object. When we call such a function on an object with a lambda expression provided, it forms a temporary scope. In this scope, we can access the object without its name. Such functions are called Scope Functions. This article provides the detailed descriptions of the differences between scope functions and the conventions on their usage in Kotlin with some authentic examples.
A famous quote about learning is :
” Tell me and I forget, teach me and I may remember, involve me and I learn.”
So Let’s begin.
Scope Functions in Kotlin
The definition of Scope function is
” Scoped functions are functions that execute a block of code within the context of an object.“
These functions provide a way to give temporary scope to the object under consideration where specific operations can be applied to the object within the block of code, thereby, resulting in a clean and concise code. There are five scoped functions in Kotlin: let, run, with, also and apply.
Basically, these functions do the same: execute a block of code on an object. What’s different is how this object becomes available inside the block and what is the result of the whole expression.
If we write the same without let, we’ll have to introduce a new variable and repeat its name whenever we use it.
val alice = Person("Alice", 20, "Amsterdam")
println(alice)
alice.moveTo("London")
alice.incrementAge()
println(alice)
The scope functions do not introduce any new technical capabilities, but they can make our code more concise and readable.
Due to the similar nature of scope functions, choosing the right one for our case can be a bit tricky. The choice mainly depends on our intent and the consistency of use in our project.
Common Difference between Scope Functions
Because the scope functions are all quite similar in nature, it’s important to understand the differences between them. There are two main differences between each scope function:
The way to refer to the context object
The return value.
Context object – this or it
Inside the lambda of a scope function, the context object is available by a short reference instead of its actual name. Each scope function uses one of two ways to access the context object: as a lambda receiver (this) or as a lambda argument (it). Both provide the same capabilities, so we’ll describe the pros and cons of each for different cases and provide recommendations on their use.
fun main() {
val str = "Hello"
// this
str.run {
println("The receiver string length: $length")
//println("The receiver string length: ${this.length}") // does the same
}
// it str.let { println("The receiver string's length is ${it.length}") }
}
this
run, with, and apply refer to the context object as a lambda receiver – by keyword this. Hence, in their lambdas, the object is available as it would be in ordinary class functions. In most cases, we can omit this when accessing the members of the receiver object, making the code shorter. On the other hand, if this is omitted, it can be hard to distinguish between the receiver members and external objects or functions. So, having the context object as a receiver (this) is recommended for lambdas that mainly operate on the object members: call its functions or assign properties.
val adam = Person("Adam").apply {
age = 20 // same as this.age = 20 or adam.age = 20
city = "London"
}
println(adam)
it
In turn, let and also have the context object as a lambda argument. If the argument name is not specified, the object is accessed by the implicit default name it. it is shorter than this and expressions with it are usually easier for reading. However, when calling the object functions or properties we don’t have the object available implicitly like this. Hence, having the context object as it is better when the object is mostly used as an argument in function calls. it is also better if we use multiple variables in the code block.
fun getRandomInt(): Int {
return Random.nextInt(100).also {
writeToLog("getRandomInt() generated value $it")
}
}
val i = getRandomInt()
Additionally, when we pass the context object as an argument, we can provide a custom name for the context object inside the scope.
fun getRandomInt(): Int {
return Random.nextInt(100).also { value ->
writeToLog("getRandomInt() generated value $value")
}
}
val i = getRandomInt()
Return value
The scope functions differ by the result they return:
apply and also return the context object.
let, run, and with return the lambda result.
These two options let we choose the proper function depending on what we do next in our code.
Context object
The return value of apply and also is the context object itself. Hence, they can be included into call chains as side steps: we can continue chaining function calls on the same object after them.
val numberList = mutableListOf()
numberList.also { println("Populating the list") }
.apply {
add(2.71)
add(3.14)
add(1.0)
}
.also { println("Sorting the list") }
.sort()
They also can be used in return statements of functions returning the context object.
fun getRandomInt(): Int {
return Random.nextInt(100).also {
writeToLog("getRandomInt() generated value $it")
}
}
val i = getRandomInt()
Lambda result
let, run, and with return the lambda result. So, we can use them when assigning the result to a variable, chaining operations on the result, and so on.
val numbers = mutableListOf("one", "two", "three")
val countEndsWithE = numbers.run {
add("four")
add("five")
count { it.endsWith("e") }
}
println("There are $countEndsWithE elements that end with e.")
Additionally, we can ignore the return value and use a scope function to create a temporary scope for variables.
val numbers = mutableListOf("one", "two", "three")
with(numbers) {
val firstItem = first()
val lastItem = last()
println("First item: $firstItem, last item: $lastItem")
}
We can analyze the common scope functions difference summary as below diagram:
Five Scope Functions In Kotlin
To help we choose the right scope function for our case, we’ll describe them in detail and provide usage recommendations. Technically, functions are interchangeable in many cases, so the examples show the conventions that define the common usage style.
There are five scoped functions in Kotlin: let, run, with, also and apply.
Let’s go through them one by one.
Scope Function – let
The context object is available as an argument (it). The return value is the lambda result.
let can be used to invoke one or more functions on results of call chains. For example, the following code prints the results of two operations on a collection:
val numbers = mutableListOf("one", "two", "three", "four", "five")
val resultList = numbers.map { it.length }.filter { it > 3 }
println(resultList)
With let, we can rewrite it:
val numbers = mutableListOf("one", "two", "three", "four", "five")
numbers.map { it.length }.filter { it > 3 }.let {
println(it)
// and more function calls if needed
}
If the code block contains a single function with it as an argument, we can use the method reference (::) instead of the lambda:
val numbers = mutableListOf("one", "two", "three", "four", "five")
numbers.map { it.length }.filter { it > 3 }.let(::println)
letis often used for executing a code block only with non-null values. To perform actions on a non-null object, use the safe call operator ?. on it and call let with the actions in its lambda.
val str: String? = "Hello"
//processNonNullString(str) // compilation error: str can be null
val length = str?.let {
println("let() called on $it")
processNonNullString(it) // OK: 'it' is not null inside '?.let { }'
it.length
}
Another case for using let is introducing local variables with a limited scope for improving code readability. To define a new variable for the context object, provide its name as the lambda argument so that it can be used instead of the default it.
val numbers = listOf("one", "two", "three", "four")
val modifiedFirstItem = numbers.first().let { firstItem ->
println("The first item of the list is '$firstItem'")
if (firstItem.length >= 5) firstItem else "!" + firstItem + "!"
}.toUpperCase()
println("First item after modifications: '$modifiedFirstItem'")
Scope Function – with
A non-extension function: the context object is passed as an argument, but inside the lambda, it’s available as a receiver (this). The return value is the lambda result.
We recommend with for calling functions on the context object without providing the lambda result. In the code, with can be read as “with this object, do the following.”
val numbers = mutableListOf("one", "two", "three")
with(numbers) {
println("'with' is called with argument $this")
println("It contains $size elements")
}
Another use case for with is introducing a helper object whose properties or functions will be used for calculating a value.
val numbers = mutableListOf("one", "two", "three")
val firstAndLast = with(numbers) {
"The first element is ${first()}," +
" the last element is ${last()}"
}
println(firstAndLast)
It is convenient when we have to call multiple different methods on the same object. Instead of repeating the variable containing this object on each line, we can use with. Thisfunction is used to change instance properties without the need to call dot operator over the reference every time.
Scope Function – run
The context object is available as a receiver (this). The return value is the lambda result.
run does the same as with but invokes as let – as an extension function of the context object.
run is useful when our lambda contains both the object initialization and the computation of the return value.
val service = MultiportService("https://example.kotlinlang.org", 80)
val result = service.run {
port = 8080
query(prepareRequest() + " to port $port")
}
// the same code written with let() function:
val letResult = service.let {
it.port = 8080
it.query(it.prepareRequest() + " to port ${it.port}")
}
Besides calling run on a receiver object, we can use it as a non-extension function. Non-extension run lets us execute a block of several statements where an expression is required.
val hexNumberRegex = run {
val digits = "0-9"
val hexDigits = "A-Fa-f"
val sign = "+-"
Regex("[$sign]?[$digits$hexDigits]+")
}
for (match in hexNumberRegex.findAll("+1234 -FFFF not-a-number")) {
println(match.value)
}
run is actually a combination of with() and let().
Scope Function – apply
The context object is available as a receiver (this). The return value is the object itself.
Use apply for code blocks that don’t return a value and mainly operate on the members of the receiver object. The common case for apply is the object configuration. Such calls can be read as “apply the following assignments to the object.”
val adam = Person("Adam").apply {
age = 32
city = "London"
}
println(adam)
Having the receiver as the return value, we can easily include apply into call chains for more complex processing.
Scope Function – also
The context object is available as an argument (it). The return value is the object itself.
also is good for performing some actions that take the context object as an argument. Use also for actions that need a reference rather to the object than to its properties and functions, or when we don’t want to shadow this reference from an outer scope.
When we see also in the code, we can read it as “and also do the following with the object.”
val numbers = mutableListOf("one", "two", "three")
numbers
.also { println("The list elements before adding new one: $it") }
.add("four")
Scope Functions – run vs let
run is similar to letin terms of accepting any return value , but this is different in the context of the object terms. run function refers to the context of the object as “this” and not “it”. That is the reason we did not use “${this.name}” as it would be redundant here since the block of code understands that “name” is used here concerning the Person object.
Another point here is that since the context is referred to as “this”, it cannot be renamed to a readable lambda parameter. So depending on the use case and requirement , we have to choose between the let and the run operator. The “run” operator also helps in easy null checks similar to the “let” operator.
var name: String? = "Abcd"
private fun performRunOperation() {
val name = Person().name?.run {
"The name of the Person is: $this"
}
print(name)
}
Scope Functions – with vs run
Let’s consider a case where a Person object can be nullable.
we can see that the context of the object referred to as “this” is a nullable type of Person. And hence, to correct this, we need to change the code as:
So performing a null check using a “with” operator is difficult and this is where we can replace it with “run” as follows:
private fun performRunOperation() {
val person: Person? = null
person?.run {
name = "asdf"
contactNumber = "1234"
address = "wasd"
displayInfo()
}
}
This looks a lot cleaner.
Scope Functions – run vs apply
So let’s see the difference between run and apply functions.
We can see that run accepts a return statement whereas apply does not accept a return statement(we can see the error thrown by the IDE in the image) and always returns the same object which it is referring to.
Scope Functions – let vs also
So let’s see the difference between let and also functions.
We can see that let accepts a return statement whereas “also” does not accept a return statement(we can see the error thrown by the IDE in the image) and always returns the same object which it is referring to.
Standard Library Scope Functions – takeIf and takeUnless
In addition to scope functions, the standard library contains the functions takeIf and takeUnless. These functions let us embed checks of the object state in call chains.
When we called on an object with a predicate provided, takeIf returns this object if it matches the predicate. Otherwise, it returns null. So, takeIf is a filtering function for a single object. In turn, takeUnless returns the object if it doesn’t match the predicate and null if it does. The object is available as a lambda argument (it).
val number = Random.nextInt(100)
val evenOrNull = number.takeIf { it % 2 == 0 }
val oddOrNull = number.takeUnless { it % 2 == 0 }
println("even: $evenOrNull, odd: $oddOrNull")
When we do chaining other functions after takeIf and takeUnless, we don’t forget to perform the null check or the safe call (?.) because their return value is nullable.
takeIf and takeUnless are especially useful together with scope functions. A good case is chaining them with let for running a code block on objects that match the given predicate. To do this, call takeIf on the object and then call let with a safe call (?). For objects that don’t match the predicate, takeIf returns null and let isn’t invoked.
fun displaySubstringPosition(input: String, sub: String) {
input.indexOf(sub).takeIf { it >= 0 }?.let {
println("The substring $sub is found in $input.")
println("Its start position is $it.")
}
}
displaySubstringPosition("010000011", "11")
displaySubstringPosition("010000011", "12")
This is how the same function looks without the standard library functions:
fun displaySubstringPosition(input: String, sub: String) {
val index = input.indexOf(sub)
if (index >= 0) {
println("The substring $sub is found in $input.")
println("Its start position is $index.")
}
}
displaySubstringPosition("010000011", "11")
displaySubstringPosition("010000011", "12")
The Selection Of Scope Functions
To help we choose the right scope function for our purpose, we provide the table of key differences between them.
Function
Object reference
Return value
Is extension function
let
it
Lambda result
Yes
run
this
Lambda result
Yes
run
–
Lambda result
No: called without the context object
with
this
Lambda result
No: takes the context object as an argument.
apply
this
Context object
Yes
also
it
Context object
Yes
Key differences between Scope Function
Here is a short guidelines for choosing scope functions depending on the intended purpose:
Executing a lambda on non-null objects: let
Introducing an expression as a variable in local scope: let
Object configuration: apply
Object configuration and computing the result: run
Running statements where an expression is required: non-extension run
Additional effects: also
Grouping function calls on an object: with
The use cases of different scope functions overlap, so that we can choose the functions based on the specific conventions used in our project or team.
In this article, we understood about how to select Scope Functions in Kotlin. Although the scope functions are a way of making the code more concise, avoid overusing them: it can decrease our code readability and lead to errors. Avoid nesting scope functions and be careful when chaining them: it’s easy to get confused about the current context object and the value of this or it. This article showed the detailed descriptions of the differences between scope functions and the conventions on their usage in Kotlin with some authentic examples.
Thanks for reading! I hope you enjoyed and learned about Scope Functions concepts in Kotlin. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find other articles of CoolMonkTechie as below link :
Hello Readers, CoolMonkTechie heartily welcomes you in this article (How To Apply Manual Dependency Injection In A Real Android Application ?).
In this article, we will learn about how to apply manual dependency injection in a real android application. Dependency Injection is a good technique for creating scalable and testable Android applications. When our application gets larger, we will start seeing that we write a lot of boilerplate code (such as factories), which can be error-prone. We also have to manage the scope and lifecycle of the containers ourself, optimizing and discarding containers that are no longer needed in order to free up memory. Doing this incorrectly can lead to subtle bugs and memory leaks in our app. This article reviews an iterated approach of how we might start using manual dependency injection in our application.
A famous quote about learning is :
” Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young. The greatest thing in life is to keep your mind young. “
So Let’s begin.
Manual Dependency Injection
Android’s recommended app architecture encourages dividing our code into classes to benefit from separation of concerns, a principle where each class of the hierarchy has a single defined responsibility. This leads to more, smaller classes that need to be connected together to fulfill each other’s dependencies.
The dependencies between classes can be represented as a graph, in which each class is connected to the classes it depends on. The representation of all our classes and their dependencies makes up the application graph. In figure 1, we can see an abstraction of the application graph. When class A (ViewModel) depends on class B (Repository), there’s a line that points from A to B representing that dependency.
Dependency injection helps make these connections and enables us to swap out implementations for testing. For example, when testing a ViewModel that depends on a repository, we can pass different implementations of Repository with either fakes or mocks to test the different cases.
The approach improves until it reaches a point that is very similar to what Dagger would automatically generate for us.
Example – Login Flow For A Typical Android Application
Consider a flow to be a group of screens in our app that correspond to a feature. Login, registration, and checkout are all examples of flows.
When covering a login flow for a typical Android application, the LoginActivity depends on LoginViewModel, which in turn depends on UserRepository. Then UserRepository depends on a UserLocalDataSource and a UserRemoteDataSource, which in turn depends on a Retrofit service.
LoginActivity is the entry point to the login flow and the user interacts with the activity. Thus, LoginActivity needs to create the LoginViewModel with all its dependencies.
The Repository and DataSource classes of the flow look like this:
class UserRepository(
private val localDataSource: UserLocalDataSource,
private val remoteDataSource: UserRemoteDataSource
) { ... }
class UserLocalDataSource { ... }
class UserRemoteDataSource(
private val loginService: LoginRetrofitService
) { ... }
Here’s what LoginActivity looks like:
class LoginActivity: Activity() {
private lateinit var loginViewModel: LoginViewModel
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// In order to satisfy the dependencies of LoginViewModel, you have to also
// satisfy the dependencies of all of its dependencies recursively.
// First, create retrofit which is the dependency of UserRemoteDataSource
val retrofit = Retrofit.Builder()
.baseUrl("https://example.com")
.build()
.create(LoginService::class.java)
// Then, satisfy the dependencies of UserRepository
val remoteDataSource = UserRemoteDataSource(retrofit)
val localDataSource = UserLocalDataSource()
// Now you can create an instance of UserRepository //that LoginViewModel needs
val userRepository = UserRepository(localDataSource, remoteDataSource)
// Lastly, create an instance of LoginViewModel with //userRepository
loginViewModel = LoginViewModel(userRepository)
}
}
There are issues with this approach:
There’s a lot of boilerplate code. If we wanted to create another instance of LoginViewModel in another part of the code, we’d have code duplication.
Dependencies have to be declared in order. We have to instantiate UserRepository before LoginViewModel in order to create it.
It’s difficult to reuse objects. If we wanted to reuse UserRepository across multiple features, we’d have to make it follow the singleton pattern. The singleton pattern makes testing more difficult because all tests share the same singleton instance.
Example Solutions
Managing Dependencies With A Container
To solve the issue of reusing objects, we can create our own dependencies container class that we use to get dependencies. All instances provided by this container can be public. In the example, because we only need an instance of UserRepository, we can make its dependencies private with the option of making them public in the future if they need to be provided:
// Container of objects shared across the whole app
class AppContainer {
// Since you want to expose userRepository out of the container, you need to satisfy
// its dependencies as you did before
private val retrofit = Retrofit.Builder()
.baseUrl("https://example.com")
.build()
.create(LoginService::class.java)
private val remoteDataSource = UserRemoteDataSource(retrofit)
private val localDataSource = UserLocalDataSource()
// userRepository is not private; it'll be exposed
val userRepository = UserRepository(localDataSource, remoteDataSource)
}
Because these dependencies are used across the whole application, they need to be placed in a common place all activities can use: the application class. Create a custom application class that contains an AppContainer instance.
// Custom Application class that needs to be specified
// in the AndroidManifest.xml file
class MyApplication : Application() {
// Instance of AppContainer that will be used by all the Activities of the app
val appContainer = AppContainer()
}
We aware that AppContainer is just a regular class with a unique instance shared across the app placed in our application class. However, AppContainer is not following the singleton pattern; in Kotlin, it’s not an object, and in Java, it’s not accessed with the typical Singleton.getInstance() method.
Now we can get the instance of the AppContainer from the application and obtain the shared of UserRepository instance:
class LoginActivity: Activity() {
private lateinit var loginViewModel: LoginViewModel
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// Gets userRepository from the instance of AppContainer in Application
val appContainer = (application as MyApplication).appContainer
loginViewModel = LoginViewModel(appContainer.userRepository)
}
}
In this way, we don’t have a singleton UserRepository. Instead, we have an AppContainer shared across all activities that contains objects from the graph and creates instances of those objects that other classes can consume.
If LoginViewModel is needed in more places in the application, having a centralized place where we create instances of LoginViewModel makes sense. We can move the creation of LoginViewModel to the container and provide new objects of that type with a factory. The code for a LoginViewModelFactory looks like this:
// Definition of a Factory interface with a function to create objects of a type
interface Factory<T> {
fun create(): T
}
// Factory for LoginViewModel.
// Since LoginViewModel depends on UserRepository, in order to create instances of
// LoginViewModel, you need an instance of UserRepository that you pass as a parameter.
class LoginViewModelFactory(private val userRepository: UserRepository) : Factory {
override fun create(): LoginViewModel {
return LoginViewModel(userRepository)
}
}
We can include the LoginViewModelFactory in the AppContainer and make the LoginActivity consume it:
// AppContainer can now provide instances of LoginViewModel with LoginViewModelFactory
class AppContainer {
...
val userRepository = UserRepository(localDataSource, remoteDataSource)
val loginViewModelFactory = LoginViewModelFactory(userRepository)
}
class LoginActivity: Activity() {
private lateinit var loginViewModel: LoginViewModel
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// Gets LoginViewModelFactory from the application instance of AppContainer
// to create a new LoginViewModel instance
val appContainer = (application as MyApplication).appContainer
loginViewModel = appContainer.loginViewModelFactory.create()
}
}
This approach is better than the previous one, but there are still some challenges to consider:
We have to manage AppContainer ourself, creating instances for all dependencies by hand.
There is still a lot of boilerplate code. We need to create factories or parameters by hand depending on whether we want to reuse an object or not.
Managing Dependencies In Application Flows
AppContainer gets complicated when we want to include more functionality in the project. When our app becomes larger and we start introducing different feature flows, there are even more problems that arise:
When we have different flows, we might want objects to just live in the scope of that flow. For example, when creating LoginUserData (that might consist of the username and password used only in the login flow) we don’t want to persist data from an old login flow from a different user. We want a new instance for every new flow. We can achieve that by creating FlowContainer objects inside the AppContainer as demonstrated in the next code example.
Optimizing the application graph and flow containers can also be difficult. We need to remember to delete instances that we don’t need, depending on the flow we’re in.
Imagine we have a login flow that consists of one activity (LoginActivity) and multiple fragments (LoginUsernameFragment and LoginPasswordFragment). These views want to:
Access the same LoginUserData instance that needs to be shared until the login flow finishes.
Create a new instance of LoginUserData when the flow starts again.
We can achieve that with a login flow container. This container needs to be created when the login flow starts and removed from memory when the flow ends.
Let’s add a LoginContainer to the example code. We want to be able to create multiple instances of LoginContainer in the app, so instead of making it a singleton, make it a class with the dependencies the login flow needs from the AppContainer.
class LoginContainer(val userRepository: UserRepository) {
val loginData = LoginUserData()
val loginViewModelFactory = LoginViewModelFactory(userRepository)
}
// AppContainer contains LoginContainer now
class AppContainer {
...
val userRepository = UserRepository(localDataSource, remoteDataSource)
// LoginContainer will be null when the user is NOT in the login flow
var loginContainer: LoginContainer? = null
}
Once we have a container specific to a flow, we have to decide when to create and delete the container instance. Because our login flow is self-contained in an activity (LoginActivity), the activity is the one managing the lifecycle of that container. LoginActivity can create the instance in onCreate() and delete it in onDestroy().
class LoginActivity: Activity() {
private lateinit var loginViewModel: LoginViewModel
private lateinit var loginData: LoginUserData
private lateinit var appContainer: AppContainer
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
appContainer = (application as MyApplication).appContainer
// Login flow has started. Populate loginContainer in AppContainer
appContainer.loginContainer = LoginContainer(appContainer.userRepository)
loginViewModel = appContainer.loginContainer.loginViewModelFactory.create()
loginData = appContainer.loginContainer.loginData
}
override fun onDestroy() {
// Login flow is finishing
// Removing the instance of loginContainer in the AppContainer
appContainer.loginContainer = null
super.onDestroy()
}
}
Like LoginActivity, login fragments can access the LoginContainer from AppContainer and use the shared LoginUserData instance.
Because in this case we’re dealing with view lifecycle logic, using lifecycle observation makes sense.
In this article, we understood about how to apply manual dependency injection in a real android application. Dependency injection is a good technique for creating scalable and testable Android applications. Use containers as a way to share instances of classes in different parts of our application and as a centralized place to create instances of classes using factories. This article reviewed an iterated approach of how we might start using manual dependency injection in our android application.
Thanks for reading! I hope you enjoyed and learned about ManualDependency Injection (DI) concepts in Android. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find other articles of CoolMonkTechie as below link :