views:

92

answers:

1

Hi all!

I'm developing an android app (if you want more info http://www.txty.mobi) and I am having some problems with dialogs management. I'm quite new to Android so the way I'm doing things completely wrong. If the case please just say so pointing me to the right documentation to follow.

Background:

The main blocks of the app so far are one activity and one Service (which derives from IntentService). The actvity needs to interact with the service in just two occasions: start/stop the service. The intent service will self regulate its lifetime using the AlarmManager.

A typical flow when clicking on start/stop:

1) the activity on its onResume registers a broadcast receiver to events sent by the service (unregisters it in the onPause)

2) the activity starts a indeterminate progress dialog

3) the activty sends a single shot alarm event (either start or stop) which will be send **straight away to the service

4) the service does what it needs to do to start

5) the service emits a broadcast event basically saying "done"

6) the activity receive this event and gets rid of the dialog.

The Problem:

The activity can lose its foreground status let's say if the user switches focus or a call is received, so the onPause method is called (at this point the activity could even be killed by the system to claim memory). obviously if this is the case the activity will never receive its broadcast event because the receiver has been unregistered. This will leave the app in the awkward situation, when the activity is brought again to the front, of having a dialog that you can't kill nor will never get rid of.

The (possible??) solution:

The way I am handling this now (apart for keeping the broadcast receiver in place) is by creating a utility class that uses preferences to keep track of which operations are being executed and their status:

Activity
- in the onResume using my utility class gets the list of operations the activity is waiting for
- check their status
- if they are completed perform some actions accordingly (in my case get rid of dialog!)
- delete the operation from the preferences. - just before asking for a operation to the service it saves it to the preference using my utility class.

Service
perform operation and save state of the operation to the preference using my utility class. emit broadcast.

Disasters happen!

Now this saves me in a normal situation, but if a disaster happens (i.e. with the task killer app you kill everything) the service might be killed before it can save the status of the operation I am stuck as before (the activity will think the operation is still going on so it won't touch the dialog). So as for now I add a Dismiss button to very dialog just in case :)

Now all of this looks too complicated for what I think should be a fairly common thing to do. That's why, as said at the beginning of the post, I might (very likely!) be completely wrong.
Any ideas? Apologies if this question has been asked already, I looked around but didn't find anything. Please point me to any resource online explaining this.

Thanks and sorry for the lenghty post :P

Luca

+1  A: 

Have you tried using a StickyBroadcast? This caches the latest broadcast, so it can be received onResume. Please see this post.

iPaulPro
thanks! form the documentation is exactly what I need to get rid of the utility class I have written. I will try it asap.
lucabox
My pleasure. Please remember to accept this answer if it solves your issue. (This will encourage other people to answer more of your questions in the future)
iPaulPro
I finally managed to try the StickyBroadcast approach, although it simplifies my code (no need of accessing preferences anymore, at the price of adding one permission more: **BROADCAST_STICKY**) I think I still need a "Dimiss" button on the indeterminate progress dialog because (as with my approach) if the gets service gets killed then it won't send the broadcast and the UI will be stuck with this dialog nobody will ever remove, making the app unusable. Probably I need to add a "timeout". I will check whether the task killer app can kill services, if it can't then I'm just over-engineering :)
lucabox