2

I work on a project that has several developers. We work on one rather large app. Every developer has several activities that can be seen as sub-apps of the whole main-app.

I do realize, that this may not be the best design, but it exists and we have to handle it somehow.

Now the main issue is, that we need a master, that is always active and checks I/Os etc and that can give out status changes to every sub-app/activity. Something like "we just lost internet connection" etc.

Right now, that master is a singleton, that is first instantiated by the launcher activity and that every activity/sub-app can register to by passing the appropriate interfaces depending on what updates the activity would like to receive.

This is working, however it doesn’t feel right, because the singleton needs context to access system resources to determine system stati like internet or gps. Should the singleton be killed by OS, than a simple "getInstance" wouldn’t do much good, because the singleton would somehow need to acquire a context. I've read about extending the Application class and creating a static member context there, but this variable had to be volatile AND its possible that it returns null if the entire app is in some restart-after-crash/kill state. It doesn’t feel safe.

In addition, there should also be a possibility that the master somehow opens a user-dialog to display warnings etc to the user. Those warnings should look the same across the entire app and no dev should have to worry about when or why it suddenly pops up. Right now, those messages appear as custom toasts that overlay everything. Of course they require context and if the app is about to close there could be a problem.

All in all, that’s the mess we are in and I’m looking for a solution.

So how do I create a safe master object or activity (or even service ?!) that can pass info to different activities and post warnings etc (and Maybe even has the ability to close activities or at least order them to close themselves without the need to register a can_close interface).

It should be that safe, that if after a crash android only restarts the activity that was active it somehow manages to also be restarted or at least have/give the same info as before.

Every idea is welcome but total overhauls of the app are just not possible (lack of time and manpower)

bstpierre
  • 30,042
  • 15
  • 70
  • 103
NikkyD
  • 2,209
  • 1
  • 16
  • 31

2 Answers2

3

Here are a few ideas:

  1. Create a Service component for all the monitoring you need to do. If I understand correctly, this service will be required only if some of the activities are running. So you can make it a bound service. Let all activities bind to this service when they start and unbind when they close. The service will be started when the first activity binds.
  2. Create a base class for all your activities. You can write all the common code here. e.g. the code to bind to and exchange messages with the master service. This class can also contain utility methods for notifying user etc. So all activities will use the same method for notification.
  3. For user notifications, you could either use Status Bar Notification or create a Fragment which can capture, aggregate and display the notifications. You can have a common menu item implemented in the base Activity class to show/hide this Fragment. If you use Status Bar Notification, make sure you use one aggregated notification for your app. Otherwise, the different activities might create a clutter in the status bar.
Sameer
  • 4,379
  • 1
  • 23
  • 23
  • i like nr2, unfortunately we have a mapactivity, i hate those maps, they only cause trouble. The fragments are a problem because we run android 2.3. – NikkyD Oct 03 '12 at 13:30
  • i feel the need to comment on my last statement, silly me, just checked and MapActivity DOES extend Activity, its just not that easy to find that out. So option nr2 should work like a charm *fingers crossed* – NikkyD Dec 04 '12 at 16:03
  • even more silly me, i cant make mapactivity extend MY custom activity... back to square one – NikkyD Dec 04 '12 at 16:35
0

I guess that one solution would be to create a service that serve as the master. You will have to make it run independently of the different activities (but don't forget to manage own to shut it down neatly if the app is no longer used, you don't want to kill your clients battery). A service can't act on the interface though, so you will probably need to broadcast messages to the activities to order them to open a dialog.

A final thought : Toasts are ok but popup that block the interface are very bad, especially on a mobile device.

Teovald
  • 4,369
  • 4
  • 26
  • 45