The *potential* problem with this approach is that it *potentially* distributes a whole lot of initialization code throughout your application in various Activities, Services, etc.
One advantage of subclassing Application is it allows you to centralize a lot of common logic. If you have this bit of state in ActivityA, and another in ActivityB, and another in ActivityC -- not only does it get terribly confusing, but you also can also end up repeatedly loading preferences settings, database data, etc. You also end up loading classes you might otherwise never need to have touched. On the other hand, initializing everything on loading the application ignores that you may not need all of it. Of course, you can avoid that by doing lazy initialization within the Application subclass, too. I am NOT arguing that you should always subclass Application instead of using statics, etc. Rather, you should do the simplest thing that works. I'd suggest starting out with statics, and only subclassing Application if it solves a problem for you. You can also create a Model class (as in Model-View-Controller, or MVC) that you centralize around. This is a single singleton, that replaces many singletons. There's more to the Model component of MVC than I'll cover here, but you can manage it either within a Application subclass or with a static -- just be sure to only have one. I'd prefer this to cluttering up an Application subclass. Still, the only reason I know where it's actually NECESSARY to subclass Application, is to override its lifecycle methods. I initialize Flurry there, so I can set up error handling before any activities or services are started. I also publish from the Application subclass certain data I extract from my application manifest's metadata, which can't be done from a static. I handle updating data from the free app to the paid app, and upgrading data from one release to the next, before the Activity's and Services have a chance to notice the obsolete data. On Mar 9, 1:37 pm, Streets Of Boston <flyingdutc...@gmail.com> wrote: > Try to avoid subclassing the Application class. > Just use static variables. Initialize them to null/0/whatever and > check them in the onCreate of your activity. If these are null/0/ > whatever, initialize these static variable properly and continue. But > re-initializing them *won't maintain* state. After you process has > been killed, your state is reset. You can use static variables to > share state between multiple activities in your app (as long as > they're started in the same process). > > If you want to maintain state over configuration changes (e.g. slide > out keyboard, orientation changes), use the activity's > onRetainNonConfigurationInstance method. > > If you want to maintain state even if your process has been killed, > use the activity's onSaveInstanceState method (and related methods). > > On Mar 9, 5:59 am, miguelo <miguel...@gmail.com> wrote: > > > > > Hi, thanks for your help. I have read about how to save and restore > > the status of an activity (onSavedInstanceState(), > > onRestoreInstanceState(), ...) > > > My problem is I'm extending the android.app.Application class, which > > is a "base class for those who need to maintain global application > > state" and I'm using it to maintain some global data (user logged in, > > DB helper, ...). These are the data I'm losing if I leave my > > application opened and after a few hours I return to it. I'm able to > > restore the specific data of the running activity but not these global > > data. > > > I don't know if I'm using a bad practice (and in that case which is > > the recommended approach to store global application state), and if > > that's the correct place to do it, how can I save/restore those data > > when my process is killed/restarted. > > > Thanks, > > > Miguel > > > On 8 mar, 17:22, TreKing <treking...@gmail.com> wrote: > > ... > > > > Did you readed about onSavedInstanceState and onRestoreInstanceState ? > > > ... -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
