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
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
On Tue, Mar 9, 2010 at 4:59 AM, miguelo miguel...@gmail.com wrote:
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.
How are you loading data into your
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.
Streets is right, and gives good practical advice, as usual. I do the
same, if it's important, it has a getter and a setter. The getter
checks for null, if it's null it gets from local storage, be it a
preference, a file, an sqlite db, or it makes a new network call.
Then it gets set to local
5 matches
Mail list logo
