My activities start long running jobs that involve network communication. So handling these jobs with an IntentService seems perfectly reasonable. I also need to handle the results of these jobs, if the Activity that started this is "active" in the time of completion. The case that gave me a headache is what if the device is in the middle of a rotation, and the Service finishes a job?
Currently, the service broadcasts an intent with the results as extras. The activities register and unregister a receiver for this completion-intent in onResume and onPaused. This way I don't have to tell the service explicitly, which listener it has to notify upon completion, it only has to make a broadcast. But with this design I can't handle cases where the job finishes, but the Acitivity is not resumed - it might be in the middle of a rotation, or the user could've switched to another app temporarily, etc. So I had the idea to implement a "postbox" pattern: I'd extend the Application object (or use a static object) that has a postbox object. The IntentService puts the results of the completed jobs inside this box, with a unique jobId, and makes a broadcast indicating that the postbox has new things. If an Acitivty is active, it receives this broadcast, checks the postbox, and handles the results as needed. Besides, every Acitivity checks the postbox in onResume(), for possible missed messages containing job-results. I'm avare that static objects could be destroyed without notice. But this pattern might solve the rotation problem stated above - I'm quite sure that the Application object survives the device rotation, or am I missing something? So what do you think of this pattern? Is there something fatal I missed? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
