This article would be a short one as I am not going to dive deep into what MVVM or LiveData or Kotlin Flow is. We are going to look at what are the basic things needed in order to achieve MVVM and compare how we used to do it and with the new implementation with Kotlin Flow and MediatorLiveData.

Why Kotlin Flow?

Right after the stable releases of Kotlin Coroutines that had “suspending” functions that can asynchronously return a single value, questions were raised on how to return multiple values or a stream of data. Kotlin Flow came into the picture that solved the problem of handling streams just like how RxJava does. Flow is fairly new and consists of a considerable amount of experimental APIs inside which performs really good, so it is not recommended to use those functionalities in your production code just yet but that doesn’t stop us from experimenting with it.

Let’s say, you hit a network request from an app and it returns data preferably a list and you need to observe them through your MVVM data-flow. It involves creating LiveData everywhere and observing them in your Activity. Suspending functions allowed you to achieve that with ViewModel scopes but that is just not enough. You have to write another function to perform operations on those returned data and state handling is challenging. You can also do the same without Coroutines but you may need to include LiveData in your repositories which are not recommended, your interactors/repositories must never have Android dependencies, this is architecture 101.

Kotlin Flow comes to the rescue here by allowing you to get those streams of data and convert them to LiveData by using Kotlin “ktx” extension function (asLiveData(viewModelContext)). Your Repository function should return a Flow<Data> and the calling function in your ViewModel should convert them to LiveData for your Activity to start observing them. Now let’s see the difference between them in code.

I would never recommend this approach as it is a bad design to use LiveData in your repositories.

So, our next thing to work on would be how to remove the LiveData dependency and replace it with Kotlin Flow. Flow like RxJava has asynchronous capabilities and allows you to run a block of code in the background thread.

flowOn() is an extension function that allows you to specify the dispatcher on which the block should run on Dispatchers.IO should work in our case. There are a lot of operations available for us to use in the returned flow from the repository, you can collect them, specify onStart code block (what should be done before the flow block is executed), and convert the returned Flow to LiveData using asLiveData() extension function.

Now let’s look at how the code would look like when we use Flow with LiveData.

Note that your Activity code is left unchanged but your Repository and ViewModel have adapted to use Kotlin Flow. Flow is fairly simple and easy to adapt, most of all, you can do asynchronous operations without having to define a Coroutine scope every time.

MediatorLiveData

MediatorLiveData are used to merge multiple LiveData and enable a set of Transformation operations to perform on their results. Moreover, it helps you to ensure the state of the LiveData Observer that it observes only LiveData that doesn’t return stale values. Let’s take the ExampleActivity from the above example and look at what went wrong. You can see that viewModel.getData() is being called before the Observer code, so what happens when you switch them? Your observer starts to observe meaningless LiveData that returns nothing, so you see nothing on your screen. How do we solve this issue of code order conformity?

Well, MediatorLiveData comes to the rescue. It is a LiveData that observes other LiveData and returns a single stream of LiveData (one-to-many dependency). Now, let’s look at the changes that had to be made from the example to achieve this.

You can see that getData() can now be called after the Observer code which is convenient and you don’t have to worry about the order now.

Thank You for reading

That concludes this article. I believe I’ve covered the basics of MediatorLiveData and I hope that I was of help. Thanks for your time and please upvote if you liked the read, I’d appreciate it. You can find the sample project where I’ve implemented the concepts below.

tizisdeepan/android-hilt-sample

Github Profile: https://github.com/tizisdeepan

LinkedIn Profile: www.linkedin.com/in/tizisdeepan

Happy Coding!

MVVM using MediatorLiveData and Kotlin Flow was originally published in Tech Log on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Dependency Injection?

Before heading on to the what let’s stick to the why. I would like to see Dependency Injection as vaccination for your project and when do you get it done? Right when the project is a baby. I know that it involves a huge learning curve and you must be wondering why should you do it with any project, well you are not forced to adapt to DI, you start a project thinking it is small and it solves a specific set of problems without the need for thinking ahead that there might be more new problems in the future that requires more modules to be built on your app. Complexity increases over time even if you follow a really good architecture with clean code, so DI is basically to avoid that.

Dependency Injection (DI) is a system that ensures the simplicity of your app’s architecture and lets you forget about the worries about the scalability of your app. S.O.L.I.D principles help you make the code simple, dependency injection makes the architecture simple. It prevents your code from getting more complex in the future and easily manageable. Dagger2 and Koin are one of the most used dependency injection frameworks, Hilt is fairly new to the game but my hopes are up because even at its early stages, it has promised a lot of good things.

Why Hilt?

Boilerplates

One thing that fears most of the developers to adapt to dependency injection, (even me back in the days), is that DI by itself is complex, hard to configure, and requires a lot of things to look at and put together for it to work. Google always ensures eliminating boilerplates in their frameworks right at the start or in the middle for some frameworks, just like how they managed to bring Kotlin as the go-to language for Android instead of Java. Dagger2 has a lot of boilerplates, right from modules, providers to injections, you have to write them all with respect to how you want them to work. Hilt eliminates all the boilerplates and does all the work for you with the help of a set of pre-defined components and scopes. No more creating components by yourself and creating a component factory.

Complexity

Dagger2 is a complex library that does DI by annotations. So, you have components, modules, scopes, and ways to inject them in different parts of your application which can be done in multiple ways. The problem with Dagger2 is, there is no one way in achieving something, so, when a new developer looks at your code, a base knowledge on the components and how you did it is required for them to understand the code better. Hilt, on the other hand, has wrapped all those different possibilities and gives you a clear cut way of implementing DI in your application. One look at it, and you can understand what’s happening under the hood.

ViewModel Injections

Injecting ViewModels in your Activities was the hardest part with DI using Dagger2. You had to create a ViewModel factory that took in the type and with map bindings and then injecting it via the component in your Activity — I even get tired when explaining it to people. Well, all that has vanished with Hilt. All that it takes is a @ViewModelInject for your constructor injections and a “by viewModels() ktx” extension in your activity. Yup, it’s that good.

Hilt Application

With Dagger2, it is mandatory that you create your own components and map it to the required modules before trying to inject the module functionalities, so you go ahead and create an application-level component mapped to the modules and you write a Factory provider that helps to inject classes across the specified scope.

You need to create components for each scope types and you may also need to do custom scopes based on your requirements. We will deep dive into what components and modules are, later on when we discuss them with respect to Hilt but here’s the difference in creating an application-level component between Dagger2 and Hilt. With Dagger2, you need an AppComponent that has DaggerApplication access and you need to extend your Application class with DaggerApplication.

With Hilt, all you need to do is annotate your Application class with @HiltAndroidApp annotation and that’s it, done, Hilt takes care of all the rest of the boilerplates by itself. Isn’t this fun? There’s more coming our way, stay tuned.

Hilt Components

Components are basically different parts of your application at the top-level which may have sub-components under them or modules that are installed under them. Components help the DI framework to generate the contract for you.

Dagger2 requires you to instantiate components directly which is complex to do and repetitive. Rest assured, Hilt packs in with a set of pre-defined components that comes to the rescue. We don’t anymore have to worry about all the components that we had to create and keep track of, you are asked to choose between the components that are already there. This is a good approach to programming as it standardizes your way of approach to DI overall and it is easy to adapt between different developers and easy to onboard basically anybody into your app.

Each component available in Hilt comes with a Scope by itself which derives from its name and easy to understand. For example, ActivityComponent is @ActivityScoped. Here are all the pre-defined components that are readily available for you to use from Hilt. The hierarchies and scopes are accessible just like what is found in the graph below, a provided service declared in the ApplicationComponent is accessible right down till ViewComponents. This is fairly simple rather than defining your own components which mostly becomes a mess at some point.

Hilt Modules

A Module is installed in a Hilt Component by using @Module and @InstallIn(ApplicationComponent::class) and that’s it, you don’t need to mention the module name in any component class.

You can do any number of providers in a Module that takes care of providing the service when required if the scope is satisfied. Which means, you can’t inject a provided service by a module installed in ActivityComponent in a code block that has an application-level scope.

@Provides helps you to write the provider for a particular service. @Singleton is to specify that the provider is always accessible across the mentioned scope (component) since all components are by default mapped to a scope.

Hilt Entry Points

Entry Points allow Hilt to know where exactly to inject what. You can use @AndroidEntryPoint on Activities, Fragments, Views, Services, and BroadcastReceivers. You can use this annotation to start using the injected values right away. You get access to modules depending on the scope of your entry points. For example, an entry point on an activity will allow you to use all the provided services specified on the activity as well as application modules.

@Inject helps you to get the values from the providers, yes, it's that easy, you will never have the need to instantiate/create your components at any point during the development when Hilt is being used. @Inject can also be used for construction injections.

@ViewModelInject is used to inject repository/use-case on your constructor in a ViewModel

Testing in Hilt

Testing is also easy with Hilt as it provides separate bindings for your tests by using specific Hilt test tests and rules. You get to use annotations like @HiltAndroidTest, @Rule — HiltAndroidRule, and HiltTestApplication for testing your application class.

Thank You for reading

That concludes this article. I believe I’ve covered the basics of Hilt and I hope that I was of help. Thanks for your time and please upvote if you liked the read, I’d appreciate it. You can find the sample project where I’ve implemented Hilt below.

tizisdeepan/android-hilt-sample

Github Profile: https://github.com/tizisdeepan

LinkedIn Profile: www.linkedin.com/in/tizisdeepan

Happy Coding!

Dagger-Hilt Dependency Injection on Android was originally published in Tech Log on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Kotlin most of the time, you won’t need to specify the type of the objects you are working with, as long as the compiler can infer it.

So, we just need to write var or val depending on the type of variable we want to generate, and the type can normally be inferred. We can always specify a type explicitly as well. Say, for instance, you define val REQUEST_CODE = 100. Behind the scenes, REQUEST_CODE initializes with the Int datatype since the value of REQUEST_CODE is of type Int, the compiler infers that REQUEST_CODE is also a Int. Note that Kotlin is a statically-typed language. This means that the type is resolved at compile time and never changes.

Although Kotlin uses Type Inference ( automatically identify something ), which means we also have the option to specify the data type when we initialize the variable like below:

val REQUEST_CODE: Int = 100

Both act the same while converting it to byte code.

What the heck, How do Kotlin determine the data type of numbers if we use implicit declaration?

Good question, Kotlin provides a set of built-in types that represent numbers. For integer numbers, there are four types with different sizes and, hence, value ranges.

All variables initialized with integer values not exceeding the maximum value of Int have the inferred type Int. If the initial value exceeds this value, then the type is Long. To specify the Long value explicitly, append the suffix L to the value. So, whenever you strictly want to save memory it is advisable to use explicit type declaration for data types like Byte & Short.

val one = 1 // Int
val threeBillion = 3000000000 // Long
val oneLong = 1L // Long
val oneByte: Byte = 1

Reference

• https://kotlinlang.org/docs/reference/basic-types.html

Kotlin Type inference — Quick Look was originally published in Tech Log on Medium, where people are continuing the conversation by highlighting and responding to this story.

Now you can automatically render all web contents using a dark theme in Android WebView. If you see androidx.webkit:webkit:1.3.0-beta01 changelogs you could see ForceDark API added to control if WebView should be rendered in dark mode. You can use ForceDarkStrategy API to control WebView darkening (CSS/web content darkening versus auto-darkening).

Prior try to access this feature, ensure that it is supported by the Webview is being used in. For this, the WebViewFeature class have an isFeatureSupported() function, which can be used to check if a given feature is supported. So before we go ahead and set the support for dark mode check if it is supported:

if (WebViewFeature.isFeatureSupported(WebViewFeature.FORCE_DARK)) { ... }

There are 3 different constants available in WebSettingsCompat to configure

• FORCE_DARK_OFF — Disable the force dark mode for the webview, meaning the content of the webview will be rendered as-is
• FORCE_DARK_ON — Enable the force dark mode for the webview, meaning the content of the webview will always be rendered with a dark theme
• FORCE_DARK_AUTO — Enable the force dark mode for the webview depending on the state of the parent view, meaning that the system dark mode setting will be followed when rendering the content of the webview.

Apply it accordingly using setForceDark function-

WebSettingsCompat.setForceDark(webView.settings, WebSettingsCompat.FORCE_DARK_ON)

Note: The setForceDark fun requires Android System WebView Version 76 or/+ to be installed on the device. There is no other straight forward way to enable dark mode in WebView if it doesn’t support. This is a major problem for the apps that uses a dark theme. OTOH, If you want to support WebView that doesn’t support dark theme google’s recommendation is to modify your WebView content with custom styling for Dark Theme. The prefers-color-scheme: dark @media query provides developers with a way to define custom styling for a Dark Theme similar to the way Android allows you to provide night-conditional resources.

WebView darkening — Force Dark Mode for Web Contents was originally published in Tech Log on Medium, where people are continuing the conversation by highlighting and responding to this story.

“If you struggle to read the code, how the hell are you meant to fix it !!” ????

Having a well named variable is definitely one of the most important thing for code readability. A good variable name should also provide meaning. That way it’s easy for others to read your code or even yourself in the future. You should be descriptive with your naming. Say, for instance, if you give a meaningful name to a method, you could probably save at least a line in the comment section in most scenarios.

Avoid these bad variable names:

• ❌ Single-letter names
• ❌ Acronyms
• ❌ Abbreviations
• ❌ Meaningless names

Good Read’s ( Variable Name & Code Style Guidelines ) -

“Tips on naming boolean variables — Cleaner Code” -https://dev.to/michi/tips-on-naming-boolean-variables-cleaner-code-35ig

“AOSP Java Code Style for Contributors” — https://source.android.com/setup/contribute/code-style

“Google Java Style Guide” — https://google.github.io/styleguide/javaguide.html

“Android Project and Code Guidelines” — https://github.com/ribot/android-guidelines/blob/master/project_and_code_guidelines.md

“XML naming convention” — https://jeroenmols.com/blog/2016/03/07/resourcenaming

“5 Tips to Increase your Code Quality” — https://simpleprogrammer.com/5-tips-code-quality

“Code readability metrics” — https://dev.to/stereobooster/code-readbility-metrics-5393

“Why Code Readability is important” — https://crmbusiness.wordpress.com/2014/12/08/why-code-readability-is-important/

#DEVcommunity #AndroidDev #JavaDev #KotlinDev #NamingConventions #CodingStyle #ReadabilityMatters #TheBuddySystem

Good Read’s — Variable Name & Code Style Guidelines was originally published in Tech Log on Medium, where people are continuing the conversation by highlighting and responding to this story.

GithubTrendingRepos — An #Android app consuming @github Trending Rest API’s to display the current trending #Github repositories. It has been built using Kotlin with clean architecture principles, Repository Pattern and MVVM pattern as well as Architecture Components.

Github Repo Link -https://github.com/anoopmaddasseri/GithubTrendingRepos

App Features -

✅ Trending Repository Listing
✅ Repository sorting by stars and name
✅ Take the user to the corresponding repository on long press
✅ Pull to force refresh repository
✅ Offline Storage ( Scheduled repo remote controller syncing, App will sync with backend server in every 2hrs )

Trending Libraries Demonstration -
#MaterialDesign #Dagger2 #Retrofit #Jetpack #Viewmodel #DataBinding #RoomPersistence #Moshi #kotlinx_coroutines #LeakCanary

Unit & Instrumentation tests with -
#AndroidXJUnit #JUnit4 #Mockito #MockWebServer #Espresso #Robolectric #Truth

Please feel free to hit the 🌟 button and support on Github if you find it helpful.

Android: MVVM with Clean Architecture Prototype Written In Kotlin — GithubTrendingRepos was originally published in Tech Log on Medium, where people are continuing the conversation by highlighting and responding to this story.

“The bitterness of poor quality remains long after the sweetness of low price is forgotten” — Benjamin Franklin

Providing a product at the lowest price point with outstanding quality of the product, sounds like a sure way to attract customers and gain an edge on the competition — but it’s not always that easy. It is normal for clients to expect quality and at the same time try to save money and time. After all, the clients are paying the company so they want to make sure their finances are spent efficiently.

It is well-known that development costs are quite high even to develop on one platform, either Android or iOS. Development for two platforms makes the costs grow twice as much (or even more).

Price has always been, and will always be, a significant indicator of quality, so making a high-quality product affordable and valuable is a fine line to walk and that’s what hybrid platforms do for you.

Thanks to a collection of new technologies that have emerged over the past two years. With these technologies, you can design, build, and deploy robust mobile apps faster than you could with native technologies, all while incurring little to no app performance penalties.

Using new technology is always a bit risky as you cannot be 100% sure of it. In this article, let’s compare two frameworks that is best in this business as of now, React Native and Ionic 2, and point out the main pros and cons of each.

Ionic 2

Ionic’s ultimate goal is to make it easier to develop native mobile apps also known as Hybrid apps and it proved that it’s a great solution in this business. Ionic apps are essentially websites embedded in a mobile app through what we call a webview. They are developed using HTML5, CSS, and Javascript and execute the same code regardless of the platform in which they run. They can, with tools like PhoneGap and Cordova, use the native features of a device, like GPS or camera.

A step up, Ionic is a breeze to learn & work with, and cross-compiles to iOS and Android (since it’s just Webview) using per-device differentiator classes to theme accordingly — “write once, run anywhere“.

Mixing Ionic code with native mobile app code in PhoneGap (now called Apache Cordova) allows for higher performance of the resulting product: utilizing AngularJS (rather than jQuery) allows Ionic to rely on native hardware acceleration (rather than extensive DOM manipulation). Ionic leverages CSS transitions and transforms for animation as a way to leverage the GPU and maximize available processor time.

React Native

React Native is a platform for building mobile apps using the highly popular and quickly growing React view library. The resulting apps run on both iOS and Android. However, unlike other cross-platform SDK’s like PhoneGap, Ionic, etc which basically run JavaScript powered apps in a web browser, React Native compiles to native code for the respective OS, Android or iOS. That means there is no performance compromise and the apps built with React Native run just as smoothly as apps built using the actual native tools like Xcode.

With React Native, you don’t build a “mobile web app”, an “HTML5 app”, or a “hybrid app”. You build a real mobile app that’s indistinguishable from an app built using Objective-C or Java. React Native uses the same fundamental UI building blocks as regular iOS and Android apps. You just put those building blocks together using JavaScript and React.

React Native doesn’t have the luxury “ write once, run anywhere. “ — their motto is “ learn once, write anywhere “ — meaning you’re using the same framework, and maybe even shared components, but maintaining separate code for your iOS & Android apps. This means more work, on top of the steeper learning curve. That’s the time/effort cost, now let’s consider the quality cost.

Now, Let’s Compare

Showcase — Who’s using?

OK. But Which is Better?

They both do different things, and both do it well. Choosing between the two depends more on your project requirements. React Native is a great option for creating performant iOS and Android apps that feel at home on their respective platforms, all while building on any previous web development experience. If your requirement is decent performance apps, with support for Progressive Web Apps and Native Browser Apps, then go for ionic 2 with no hesitation in mind.

Nevertheless, If you value native rendering more than the rest and if you need apps to be extremely fast and responsive, then you can opt for React Native.

References

• React Native — Learn once, write anywhere: Build Mobile app with React
• Ionic framework
• Building Hybrid Apps with AngularJS and Ionic

Go forth and build something awesome!

Gauging React Native and Ionic 2 — Which Is Really Better..? was originally published in Tech Log on Medium, where people are continuing the conversation by highlighting and responding to this story.

Perform asynchronous I/O operations using CoroutineScope ( https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-coroutine-scope ) that define a scope for new coroutines.

In Android, CoroutineScope ships with lifecycle aware architecture components. The KTX extension is ViewModelScope, we can use androidx.lifecycle:lifecycle-viewmodel-ktx:2.1.0-beta01 or higher.

A ViewModelScope is defined for each ViewModel in your app. Any coroutine launched in this scope is automatically canceled if the ViewModel is cleared. CoroutineScope tied with the ViewModel.

The viewModelScope code is publicly available in AOSP implemented as follows:

https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/lifecycle/lifecycle-viewmodel-ktx/src/main/java/androidx/lifecycle/ViewModel.kt

Usage of ViewModelScope — https://github.com/anoopmaddasseri/GithubTrendingRepos/blob/3940457412f6dc7f06e86c0a7db2c76ff5c2996f/app/src/main/kotlin/com/mvvmclean/trendingrepos/features/trendingrepo/TrendingRepositoryViewModel.kt#L33

We could also use Coroutines with LifecycleScope as a life cycle aware worker.

A LifecycleScope is defined for each Lifecycle object. Any coroutine launched in this scope is canceled when the Lifecycle is destroyed. You can access the CoroutineScope of the Lifecycle either via lifecycle.coroutineScope or lifecycleOwner.lifecycleScope properties.

Usage of LifecycleScope—

activity.lifecycleScope.launch {
 // scope tied to Activity Lifecycle
}

fragment.lifecycleScope.launch {
 // scope tied to Fragment Lifecycle 
}

fragment.viewLifecycleOwner.launch{
 // scope tied to Fragment View
}

Perform asynchronous I/O operations using CoroutineScope was originally published in Tech Log on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article will take you through the new Android 11 developer-focused features and APIs updates -

• App exit reasons updates: Google updated the exit reasons API including the ActivityManager.getHistoricalProcessExitReasons() method, allowing developers to request details surrounding their app’s recent exits. Apps can exit for many reasons, including crashes. This update helps developers get a better understanding of their app’s stability and how to improve its performance.
• Scoped storage enhancement: You can no longer use the ACTION_OPEN_DOCUMENT_TREE intent action to request access to the root directory of the internal storage volume, download directory, and to the root directory of each SD card. Apps that require broad access file can declare the MANAGE_EXTERNAL_STORAGE permission and use the ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION intent action to direct users to a system settings page where they can enable the Allow access to manage all files option for your app. With MANAGE_EXTERNAL_STORAGE permission, apps can read & write files in the shared storage and access the content of MediaStore.Files
• ADB incremental installations: Installing large (2GB or larger) APKs using ADB can be a slow process. In Android 11, developers can load these APKs onto devices up to 10x faster thanks to incremental APK installations. It works by installing enough of the APK to launch the app while streaming the remaining data in the background. This is particularly useful for developers working on mobile games. It only works on Pixel 4 devices as of DP3, but handsets that launch with Android 11 will also tout this feature.
• Wireless debugging improvements: Android 11 supports deploying and debugging your app wirelessly from your workstation via ADB. It allows the developers to connect multiple remote devices wirelessly using a pairing code, but Google plans to add QR code syncing in an upcoming Android Studio release.
• Improved data access auditing: AppOpsManager.OnOpNotedCallback provides the insights to better identify and rectify potentially unexpected data access. Your app can register an instance of the callback to better understand how the app access user information.
• Better support for curved/waterfall displays: DisplayCutout.getWaterfallInsets() to get exact dimensions of the waterfall inset to support waterfall displays, displays that wrap around the edge of the device. The existing DisplayCutout.getSafeInset…() methods now return the safe inset to avoid waterfall areas as well as cutouts.
• Conversation improvements & Chat Bubbles: Improvements to enhance the way conversations are handled. Bubbles are now available to developers to help surface conversations across the system.
• Large datasets secured sharing using data blobs: To help reduce data redundancy, both over the network and on disk, Android 11 caches shared datasets that support use cases such as machine learning and media playback. When your app needs access to a shared large dataset, it can first look for these cached datasets, called shared data blobs, before determining whether to download a new copy. The system maintains shared data blobs and controls which apps can access them using a BlobHandle object. Each instance of BlobHandle contains a cryptographically-secure hash and some identifying details for the dataset.
• Synchronized IME transitions: WindowInsetsAnimation API that let’s sync your app’s content with the onscreen keyboard and system bars as they animate on and offscreen. This will hopefully allow devs to create more natural, intuitive, and “jank-free” IME transitions. To synchronize your app’s views with the appearance and disappearance of the IME, set a listener on a view by providing a WindowInsetsAnimation.Callback to View.setWindowInsetsAnimationCallback()
• Variable refresh rate: In Android 11, apps and games can now set a preferred frame rate for each window. On devices with variable refresh rates, the system will now use the app’s preferred frame rate to choose the best refresh rate for the app. You can read more about this new Frame rate API here.
• 5G state API: Developers can now quickly check whether a user is currently connected on a 5G New Radio or Non-Standalone network.
• Call screening service improvements: New APIs to let call-screening apps do more to keep calls from bugging users. These apps will now be able to report a call rejection reason, as well as see if a call is being made to or from a number in the user’s contacts.

Read more in Features & APIs Overview section of Android Developer site: https://developer.android.com/preview/features

Android 11 — Developer focused updates [DP3] was originally published in Tech Log on Medium, where people are continuing the conversation by highlighting and responding to this story.

Traditionally, we use startActivityForResult() and onActivityResult() APIs to start another activity and receive a result back that is available on the Activity classes on all API levels.

With JetPack, it’s strongly recommended to get the business done with all-new Activity Result APIs introduced in AndroidX Activity 1.2.0-alpha02 and Fragment 1.3.0-alpha02 roll out.

You now have a nice abstraction which allows you to handle onActivityResult() method in a very clean and reusable structure, You can register a callback for an Activity Result, The Activity Result APIs provide components for registering for a result, launching the result, and handling the result once it is dispatched by the system.

Activity Result APIs —

• registerForActivityResult()— For registering the result callback
• ActivityResultContract— A contract specifying that an activity can be called with an input of type I and produce an output of type O Makes calling an activity for result type-safe.
• ActivityResultCallback — A type-safe callback to be called when an activity result is available. It’s is a single method interface with an onActivityResult() method that takes an object of the output type defined in the ActivityResultContract
• ActivityResultLauncher — A launcher for a previously-prepared call to start the process of executing an ActivityResultContract.

registerForActivityResult() takes an ActivityResultContract and an ActivityResultCallback and returns an ActivityResultLauncher which you’ll use to launch the other activity.

You can either use different contracts or want separate callbacks for multiple activity result call, you can call registerForActivityResult() multiple times to register multiple ActivityResultLauncher instances.

registerForActivityResult() is safe to call before your fragment or activity is created, allowing it to be used directly when declaring member variables for the returned ActivityResultLauncher instances. But you cannot launch the ActivityResultLauncher until the fragment or activity’s CREATED.

Launching an activity for the result —

Calling launch()starts the process of producing the result. When the user is done with the subsequent activity and returns, the onActivityResult() from the ActivityResultCallback is then executed

You can use the prebuilt ActivityResultContract from ActivityResultContracts. Alongside this, you can create custom contracts as well. You can read here to learn more about creating a custom contract.

Generic StartActivityForResult contract —

StartActivityForResult can be used for the generic purposes. This is an ActivityResultContract that doesn’t do any type conversion, taking raw Intent as an input and ActivityResult as an output. Can be registered with ActivityResultCaller.registerForActivityResult(ActivityResultContract, ActivityResultCallback) to avoid having to manage request codes when calling an activity API for which a type-safe contract is not available.

Ready to Use Contracts —

• RequestPermission
• RequestMultiplePermissions
• TakePicture
• OpenDocument
• OpenDocumentTree
• StartActivityForResult

You can find more here

Dependencies —

Package Summary —

• androidx.activity.result
• androidx.activity.result.contract

We need to be conservative when developing apps that run in the Android ecosystem which is targeted to a vast and wide variety of OEM manufacturers, When starting an activity for a result, it is possible (and, in cases of memory-intensive operations such as camera usage, almost certain) that your process and your activity will be destroyed due to low memory. For this reason, the Activity Result APIs decouple the result callback from the place in your code where you launch the other activity. As the result callback needs to be available when your process and activity are recreated, the callback must be unconditionally registered every time your activity is created.

AndroidX Activity Result APIs —  The new way! was originally published in Tech Log on Medium, where people are continuing the conversation by highlighting and responding to this story.