Kuba Lipiński wrote: > Hello, > > I'm not sure if I correctly understand the application life cycle and > would like to consult the architecture of my application with the > group. > > My application is intended to perform some time consuming (about 30 > seconds) operation from time to time. The operation can be either > invoked by the end-user (from app UI) or by some system event (through > receiver). The operation should be performed in background but its > current status should be visible on the application window. One > operation can be performed at one time. They should not overlap. If > new events which invoke the operation occur when the operation is > already running, the new operation should start after the running one > ends. > > My current package consists of following elements: > The Service - the whole operation is performed in onStart() > 2 receivers which just launch the service by calling startService() > The Activity which is about to display a status and from which the end- > user can start the service (via startService()) > > My questions are following: > Should the service run in separate process (via remote attribute)?
No. > Will it be able to still share the preferences? Yes. > Or maybe the service can run in the same process? But will UI work > during the operation? So long as your background operation is working on its own thread, then yes. > The operation does not need any parameters. Do I need to define IDL's > etc? Or calling startService() is enough? If you are going to request the background task several times from the activity, I would not use startService() several times. Either use AIDL or some other in-process communications (e.g., shared LinkedBlockingQueue that the Activity posts requests on and the background thread pulls requests off of). > Will the request be queued? Or should I run the operation in the > separate thread and create my own queue? I usually create my own queues. > How to share the operation status (text only) between the service and > the UI? Is SharedPreferences suitable for this purpose? Since the operation status is not persistent between runs of your application, I would not use SharedPreferences. Use some other in-process indicator (e.g., a static AtomicConcurrentBoolean in the event object pushed onto the queue by the activity). -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
