Is using Google AppStartUp Library is a good aproach? Is it really effective and is it ok to add the initialization code of other 3rd party libraries at our content provider i.e workmanager , Firebace etc
According to me moving workmanager content provider code at our provider does not seem feasible. Can Some one help?
The App Startup library provides a straightforward, performant way to initialize components at application startup.
You can provide inject to your Initializer class.
Related
I'm looking into slowly migrating an existing view-based Android app to a Jetpack Compose app. I figure I will take the opportunity to totally refactor the app, so I'm starting the Compose app from a blank slate, and trying to adopt the latest best practices as I go.
I've created a new project in Android Studio, using the "Empty Compose Activity" that's recommended in some of the docs I've read.
The project it creates lacks a MainApplication.kt file, and the manifest jumps straight into MainActivity, which defines only class MainActivity : ComponentActivity()
I note that the Android docs say "There is normally no need to subclass Application. In most situations, static singletons can provide the same functionality in a more modular way." which has me thinking that, as part of this refactor, I might try follow this implicit recommendation and see where it leads.
So my question is, is there anything that must be done in the Application class that would make me regret the structure that Android Studio has given me?
Does Koin dependency injection work fine outside of the main Application class? My app has services which have Room dependency injections I now do in Application class. All of that can be done elsewhere, presumibly in MainActivity?? (All Koin's examples use the Application class for DI!)
Can setting user permissions like location and file access can be done outside Application class??
I know I'm asking for an opinion here, but do you regard it as best practice to not subclass Application if you can avoid it, as the Android docs seem to suggest?
And lastly, is not subclassing the Application class (ie not having MainApplication.kt) somehow related to the new Compose way of building apps?
thanks!
John
The skeleton code that you get from creating a Compose project from Android Studio does not subclass Application because it just gives you the bare essentials to have a functional compose app.
The Application class is still the right place to initialize your dependency injection graph, plus other libraries that need a one-off initialization, like for instance Timber.
Requesting runtime permissions should be done locally, at the time you need those. If you need some permission to start your application from the get go, ask for those in your activity, the Application is not the right place for that.
I'm trying to implement this multi-module design on my app, the thing is that I'm thinking about create an "api" or "network" module where I create the retrofit instance (I'm using Dagger2, but it doesn't matter, if you have an example or pseudo with any other DI framework feel free).
Problem?
I've been working on an app that I had this similar architecture but it ended up with a big module because I had organised the instance of a retrofit and then inside of it a sub-packages with each feature where I have the services and the responses.
This helped me with a problem that I had for instance, use the same service on a different features.
Example
Home feature I need to call the Feature1Service to show X
Feature1 need to call Feature1Service to show more stuff
I've thought with a solution that instead of creating the api or network module create every service inside of that feature, but doing this is a problem.
So I'd like to listen options or if you have worked with that app with modules how did you do that?
Short question
How do you use on multi-module project where you share services between features? (Retrofit)
I am building a library that every 30 seconds displays a question (obtained from a REST Api) and allows the user to select one of the possible answers.
Also, I need to make use of that library in an app, displaying a video underneath the question.
Desired result
All the business and UI logic should be handled in the library.
Does it make sense to use an MVVM approach, with repository pattern in the library?
With this package structure?
Possible package structure
You're creating the library, which is totally different context and way of creating the codebase comparing to the app.
First of all you need to make decisions about the dependencies. Of course it is super easy to put retrofit, mvvm and other dependencies into the app and manage them further.
With library it's not that easy. What I would expect from library in the first place is to have as little dependencies as possible. If you're going to provide aar file, then the developer would have to include those dependencies in the project. On the other hand, if you're publishing the library to maven repo, the gradle will take care of the library's dependencies. However the biggest challenge here is maintaining the library and resolving conflicts in actual app that uses the library. It can lead to frustration and eventually someone can throw your library away, which is the worst thing from library creator's perspective.
What I would suggest for this small library (calling api and providing data to custom view) is to:
Use only OkHttp without retrofit to provide the data from the REST api.
If it's the case for the library, create some abstraction over the OkHttp client with public functions/methods so the developers can get the data by themselves. Cool approach for creating this kind of interface is to use Fluent Interface (for example if you want the client of the library to put their access token/secret key for the REST api to detect who is calling the api, how much, limit their requests etc)
If you want to also provide the Custom View I would suggest to think twice about separating the REST client and Custom View itself and let the developer put the data by themselves. On the other hand if you want to handle it by yourself, you have to consider error handling, state management, lifecycle callbacks for cancelling the requests etc. You can provide some Listener interfaces for the developers so they know what is going on in the custom view.
The way you structure the library is up to you, if you have only one dependency (the rest client) just pass the objects via constructor so you won't need to add another dependency. Or just simply use ServiceLocator pattern, however it should also be connected to the Application/Activity itself when setting up the library so the objects are destroyed properly
As part of Jetpack, there is now a library to handle App Startup.
Specifically, you can implement a component initializer for any of your dependencies, apparently ones that use ContentProvider for their initialization, in order to speed up the app startup process.
My question is how should I know which of my dependencies deserves its own component initializer?
Do I need to guess that, for example, WorkManager uses ContentProvider and requires its own component initializer while a different dependency doesn't?
Thanks.
I believe this library is meant mostly for cases when the initialization code can't or shouldn't be accessed from a custom Application class.
For example, On Demand Modules or libraries that don't want to require the user to call an initialize(context) method.
This library is for content providers, because content providers slow down your applications startup time. whenever you use any lib like workmanger or firebase it will autmatically add its own content provider in your android manifest xml file.
you can know which providers added to your manifest from android studio "Merged Manfest" tab
Am working on a huge android project that has more than 50 APIs request
and using the MVVM pattern, My question is:
can I add all the requests in the same app repository or I must create a repository for each service?
As others suggested in the comments you should first define the modules of your app and then create the corresponding Repositories. This way you can easily maintain and test your application.
I strongly suggest you to have a look on this https://github.com/nickbutcher/plaid and mostly this video https://youtu.be/Sy6ZdgqrQp0
A good solution to this problem is, You must not implement all your API calling code to the same repository as it will become a massive single repository class. It will also be violating design principles i.e. rule of 30 as you are saying you have at least 50 APIs to work with.
Also, it is not a good practice to modify a class, again and again, see Open Close Principle.
You can make multiple API calling classes under the same package name.