Geek Answers Handbook

When to use and not use the Android application class?

I consider the use of the android Application class as a place to store the temporary state and general code shared by other (fragments) actions in the application.

I would like more information on whether this is a good place for:

  • Common constants such as identifiers, privilege names, etc.
  • Global variables (i.e., setters / getters) reflecting the current state of the user interface, navigation, the selected fragment and, in general, temporary data that do not need to be saved.
  • Hooks to save data when certain conditions are triggered.
  • Updating the user interface after changing the settings.
  • Providing an easy way to access the context from anywhere in the application, including code where getApplication() not available, for example. through a static getter such as MyApp.getApp() .
  • General methods that require the visibility of global state variables and which become too cumbersome to go to the highlighted classes.

What else is needed / useful / useful to have in an activity class? What would be nice to keep in it and what would be the best alternatives? And finally, what did you find the application that is best used in your applications?

+6
source share
2 answers

Common constants such as identifiers, pref key names, etc.

Usually I create a constant file called C, as it is better read. C.SHARED_PREFS easier to understand that Application.SHARED_PREFS IMHO.

Global variables (i.e., setters / getters) that reflect the current state of the user interface, navigation, selected fragment, and, in general, temporary data that does not need to be saved.

This will be better in the Activity or component to which it relates (for example, the state of the Activity user interface should probably be stored in the icicle package or in this Activity instance).

Hooks to save data when certain conditions are triggered.

That should be good.

Updating the user interface after changing preferences.

Again, I feel that it will be better in the appropriate component.

Providing easy access to the context from anywhere in the application, including code where getApplication () is not available, for example. through a static getter such as MyApp.getApp ().

This will work, but be careful with memory leaks. Usually you should pass the context as a parameter when calling the method from Activity or Service or any other. Less likely to leak memory.

General methods requiring visibility of global state variables and which will become too cumbersome to move on to the initiate classes.

I believe that it would be better to make an effort to allocated classes, since when your application will expand in functions and sizes, it will be difficult to maintain.

+2
source

This is probably the place where certain hooks can be attached.

For example, if you use the ACRA error reporting library, you just need to use the Application class, because ACRA is attached here. It made me start using this class; I have never needed this before.

+2
source

More articles:


All Articles