Using Android Content Providers for Automatically Initialization
Android Content Providers
Content providers are Android’s way of sharing access to application data between applications. You can also access the data generated by your application for other applications.
The most important basic structure about content providers is that they are automatically created and run when an application starts up that uses anything that declares content providers.
The important and perhaps not obvious thing about content providers is that they are created and run automatically when an application is launched that uses anything that declares content providers.
Firebase uses content providers for automatically init performance monitoring.
All you have to do is add one line in the gradle file. All performance metrics are on your console.
I aimed for the library will create to work at the app-start level without any developer needing to init the application to be used. And I did a little research on how it works.
The way to view these details may not be explicitly in the libraries used. But one way to find out how is the Merged Manifest file.
Merged Manifest
Things like additional activities, services, and permissions are not the final file given to the system, even though basic Manifest definitions are available in Android’s apps.
The merged file is created from your Manifest.xml file, along with other information that the tools pick up, including manifests from libraries that your app uses. We see what’s happening with library content providers in this final statement.
Let’s take a look at a specific example. We’ll look at Firebase Performance.
To use Firebase Perf in my project, I added this dependency to my app’s build.gradle file:
implementation ‘com.google.firebase:firebase-perf’After I sync’d and built the app. I could see by clicking on the Merged Manifest tab at the lower-left of the Android Studio editor window while viewing Manifest.xml:
In this merged version of the manifest, I saw that including Firebase Performance had put a lot more information into the manifest, including this provider block:
And since there was now a content provider in the merged manifest, the system will automatically create and run it when my app starts.
Now I know how the content provider works on app-start without any init operation.
Auto-Init with the Startup Library
The simplest way to use App Startup is to implicitly use its content provider to initialize.
To load my library via App Startup, I first added App Startup to my app’s build.gradle file:
implementation “androidx.startup:startup-runtime:1.0.0”Note: Content provider is responsible for initialization.
I created an Initializer, which is an interface provided by App Startup api.
Every Initializer has two override functions create() and dependencies(). dependencies() related to ordering multiple libraries. I didn’t need that functionality in my case.
Here is the my custom initializer class I added:
Here is the provider tag I added:
This metadata tag inside of the provider tells the App Startup library where to find your Initializer code, which will be run at startup to init the library.
As a result I made the library that init at the app-start level as well as without having to inject context from outside.
That’s all
Until next time, take advantage of the content provider.
Do you think is it a good way to use a content provider with this method? If you used a different method like this situation, I would be glad to see it in the comment section.
