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.