CODEWITHSUNDEEP
androidandroid-context
ccpizza
ccpizza

Reputation: 31801

When to use and not to use the android Application class?

I am considering using the android Application class as a place to store temporary state and common code shared by other (fragment) activities in the app.

I would like to get more feedback as to whether it is a good place for:

  1. Shared constants like ID's, pref key names, etc.
  2. Global variables (i.e. setters/getters) reflecting current UI state, navigation, selected fragment, and, in general, temporary data that does not need to be persisted.
  3. Hooks for persisting data when certain conditions are triggered.
  4. Updating the UI after preference changes.
  5. Providing an easy way to access the context from anywhere in the app, including code where getApplication() is not available, e.g. via a static getter such as MyApp.getApp().
  6. Common methods that need the visibility of the global state variables and which would become too cumbersome to move away to dedicated classes.

What else would be appropriate/useful/handy to have in the activity class? What would not be a good idea to keep in it and what would be the best alternatives? And finally, what you have found Application to be best used for in your apps?

Upvotes: 6

Views: 1108

Answers (2)

Audrius Meškauskas
Audrius Meškauskas

Reputation: 21778

It is probably some place where certain hooks can be attached.

For instance, if you use ACRA crash reporting library, you just need to use the Application class, because this is where ACRA is attached. This is that forced me to start using this class; I never needed the one before.

Upvotes: 2

Raghav Sood
Raghav Sood

Reputation: 82563

Shared constants like ID's, pref key names, etc.

I generally create a constants file called C for this, as its better for readability. C.SHARED_PREFS is easier to understand that Application.SHARED_PREFS IMHO.

Global variables (i.e. setters/getters) reflecting current UI state, navigation, selected fragment, and, in general, temporary data that does not need to be persisted.

This would be better off in the Activity or component which it concerns (for example, the UI state of an Activity should probably stored in the icicle bundle, or within that instance of the Activity).

Hooks for persisting data when certain conditions are triggered.

This should be fine.

Updating the UI after preference changes.

Again, I feel this would be better off in the respective component.

Providing an easy way to access the context from anywhere in the app, including code where getApplication() is not available, e.g. via a static getter such as MyApp.getApp().

This would work, but be careful of memory leaks. You should generally pass the context in as a parameter when calling the method from an Activity or Service or whatever. Less chances of a memory leak.

Common methods that need the visibility of the global state variables and which would become too cumbersome to move away to dedicated classes.

I feel it would be better to make the effort of dedicated classes, as when your app grows in features and size, this will become difficult to maintain.

Upvotes: 2

Related Questions