3

My understanding of the Android lifecycle model is that when onPause() is called I should save any state that needs to be saved, because my app could be terminated at any point after I return. I'm targeting Gingerbread, so onStop might never be called.

However in my app some state is being saved on a remote server. I periodically flush this state but if onPause is called I am not sure the correct thing to do, because my understanding is that as soon as onPause returns my app could be killed. Since I have to run the android http request in another thread this seems problematic: if I start the request in onPause then return, then my app might be killed before the remote request to save the state completes (or even starts!).

I am thinking I should put some sort of synchronization where I go to sleep and wait for the request to work, but first I'm not sure I can even do this in onPause, and second, onPause isn't supposed to take very long to complete so if there is network delay this could cause issues as well.

Is there some recommended way of saving state in onPause when the state needs to be flushed to a remote server or in general by some method that requires a separate thread?

P.T.
  • 24,557
  • 7
  • 64
  • 95
Michael
  • 9,060
  • 14
  • 61
  • 123

2 Answers2

2

Not entirely sure what you are doing, but

You can put your HttpRequest into a Service, when you spawn a Thread from here this will not be killed when your activity hit's onPause.

You can then call back to your app using a BroadcastReciever and this will start your Activity up if it isn't started already.

Blundell
  • 75,855
  • 30
  • 208
  • 233
2

recommended way of saving state in onPause when the state needs to be flushed to a remote server:

in OnPause start a service(Android Service) and flush your state to server from that service and close the service after the completion of your desired task.

Shridutt Kothari
  • 7,326
  • 3
  • 41
  • 61
  • Can it really be that simple? I've already got a service that I'm doing my normal flushes through. My concern was that since my service is part of the same process as the activity, that the service could be killed with the activity. – Michael Feb 10 '13 at 17:01
  • @Michael Always remember Service don't close with your activity (as normal thing that it doesnt mean that if UI i.e. activity is killed doesnt mean your applicatio is also killed). "AND Just because of it you should always close it after you desired task -*(if and only if it is not used by any other component either from your app or any other app using it through AIDLfrom different process)" – Shridutt Kothari Feb 10 '13 at 17:15
  • 1
    The Service is in the same process as the Activity though, at least in my case it is, because I can call static functions directly. How can the OS kill only the activity to free resources and not kill the service at the same time? – Michael Feb 10 '13 at 18:06
  • Its Because of certains things: Read why it is like that here:(READ 2ND POINT CAREFULLY) http://developer.android.com/reference/android/app/Service.html#ProcessLifecycle – Shridutt Kothari Feb 10 '13 at 18:09
  • 1
    This doesn't explain how the Service is not killed if the Activity in the same process is killed. Perhaps Android uses a different meaning for killing a process than the underlying OS, such as "free the Activity object"? – Michael Feb 10 '13 at 18:15
  • 1
    Ok See it practically. In a restra waiter is the activity(UI) and the cook is service(doing work in background, not visible)...So if you have given some order and than waiter forwarded the order to cook. and now the waiter is gone away from your table(i.e like activity gone from screen) so would cook stop the performing??? NO. because if nothing is on UI doesnt mean that your whole process should be stoped.. – Shridutt Kothari Feb 10 '13 at 18:31