How to detect when android kill my process?

by miguelo » Thu, 04 Mar 2010 19:20:39 GMT


Sponsored Links
 Hi, I have a problem when android decides to kill my process, because
when it is restored, it crashs because my Application object is
restored and has lost important info that was stored in it.

I have readed in Activity Lifecycke chapter on API documentation that
"If an activity is paused or stopped, the system can drop the activity
from memory by either asking it to finish, or simply killing its
process. When it is displayed again to the user, it must be completely
restarted and restored to its previous state."

Is there any way for my application to know if the system has killed
my process before and is trying to restore it right now?

Thanks in advance and regards!


--



How to detect when android kill my process?

by Frank Weiss » Mon, 08 Mar 2010 14:29:16 GMT


 You might want to rethink the question. What's the last chance your
application has to save its state before being killed?




>


Sponsored Links


How to detect when android kill my process?

by miguelo » Tue, 09 Mar 2010 00:09:42 GMT


 Hi, I have a problem when android decides to kill my process, because
when it is restored, it crashs because my Application object is
restored and has lost important info that was stored in it.

I have readed in Activity Lifecycke chapter on API documentation that
"If an activity is paused or stopped, the system can drop the activity
from memory by either asking it to finish, or simply killing its
process. When it is displayed again to the user, it must be completely
restarted and restored to its previous state."

Is there any way for my application to know if the system has killed
my process before and is trying to restore it right now?

Thanks in advance and regards!

--



How to detect when android kill my process?

by TreKing » Tue, 09 Mar 2010 00:23:00 GMT


 



Did you readed about onSavedInstanceState and onRestoreInstanceState ?

-------------------------------------------------------------------------------------------------
TreKing - Chicago transit tracking app for Android-powered devices
 http://sites.google.com/site/rezmobileapps/treking 

--



How to detect when android kill my process?

by miguelo » Tue, 09 Mar 2010 23:27:41 GMT


 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



...
...

--



How to detect when android kill my process?

by Streets Of Boston » Wed, 10 Mar 2010 05:37:13 GMT


 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).






--



How to detect when android kill my process?

by Matt Kanninen » Wed, 10 Mar 2010 07:57:51 GMT


 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 storage.

I do this with the response from most network calls, but definitely
the first important one.  Also with any user preference set in
settings, etc.






--



How to detect when android kill my process?

by Bob Kerns » Thu, 11 Mar 2010 16:55:05 GMT


 he *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:37pm, Streets Of Boston <flyingdutc...@gmail.com> wrote:

--



Other Threads

1. Please help with Android source

Hi,

I read Android source "Get source" doc. There is a section "Building the code", 
it says that to cd to the source directory and run "make". Here comes my way 
stupid question, what is it going to make? what code it's going to build? It 
seems no doc is concerning it.

Thanks
--~--~---------~--~----~------------~-------~--~----~

2. intent-filter for addContact and editContact ?

hello

I'm looking for a intent-filter which can start my BroadcastReciver
when somebody adds a new contact or edit a contact. Unfortunately I
couldn't finde something like that. Does it exist?
If not how can I get a Notification when somebody added a new contact
or something like that?
thanks in advance

jaspher

--~--~---------~--~----~------------~-------~--~----~

3. 2d Canvas over Opengl (Flickering !!)

4. JavaBinder: !!! FAILED BINDER TRANSACTION !!!

5. Out Of Memory issue

6. Problem with Sound

7. Can somebody explain how does the open core handle the selection between OPENMAX method and PV's own method?