In my application, I have a Service
which is responsible for looking after a Bluetooth connection to an external device. This Service
class periodically polls the external Bluetooth device for data and adds that latest data into a log held in cache (or possibly SD card) memory.
Amongst the various Activity
classes that I have, there is one particular Activity
that represents the main UI. It is responsible for displaying, in graphical form, the logged data based upon the cache file data. Let's call this Activity
the Dashboard
. The user can scroll back and forth on that graph to review the data collected and logged within the cache since the application was started.
For the purpose of this question, there are two modes of operation to consider. It is possible for the user to select a "log to SD card" option, whereby the application must continue the polling and logging to SD card even when all Activity
classes are killed' (e.g. the user has gone back to the launcher). In this case my Service
is started using .startService()
and continues to run, and will only be stopped when the user invokes the application again and disabled SD card logging. The other mode is where the user hasn't selected "log to SD card", in which case the Service
is still managing the Bluetooth connection, polling and logging to cache memory for the purpose of visually displaying the data on the graph, but only needs to do so while the Dashboard
Activity
is being used.
What I have at the moment is that the Dashboard
Activity
initially binds to the Service
using bindService()
, and does a corresponding call to unbindService()
within the onPause()
method (as otherwise I would of course leak the Service
).
The problem is that the Service
needs to maintain the Bluetooth connection and continue logging during orientation changes or when the user invokes another Activity
over the top (e.g. checks an email). Now if the user has selected "log to SD card" resulting in a call to startService()
then of course there is no problem. The problem of course is how to distinguish between an Activity
being destroyed and then created again due to orientation (or some other configuration) change, and being destroyed because the user went back to the launcher. In the former case, I don't want the Service
datalogging to have been interrupted. In the latter case, I want the Service
to stop, if the user hasn't selected "log to SD card".
The best solution I can think of for this at the moment is for the service to be always started using startService()
, so that it continues to run when the Dashboard
has been destroyed. What I would then do is implement a time-out within the Service
, whereby the Service
will stop itself unless continuous SD card logging is enabled, or the Dashboard
is onCreate
d again within five seconds (say) and re-binds to the Service
. This seems a little crude, and I can't help thinking this must be a common design problem that has a better solution that I've overlooked.
Option 1: if you want the service to be destroyed, immediately when the main activity is finishing, but not during rotation:
To avoid automatic service stop you must start it manually before binding:
protected void onStart() {
Intent intent = new Intent(getApplicationContext(), MServcie.class);
startService(intent);
bindService(intent, connection, Context.BIND_AUTO_CREATE);
}
Stop the service only if your Activity is finishing!
protected void onStop() {
if (service != null) {
unbindService(connection);
service = null;
if (isFinishing()) {
stopService(new Intent(getApplicationContext(), MyServcie.class));
}
}
}
Option 2: if you want the os to decide when the service is being stopped.
protected void onStart() {
Intent intent = new Intent(this, MServcie.class);
getApplicationContext().bindService(intent, this, Context.BIND_AUTO_CREATE);
}
One approach you could use, is check to see if the Activity isFinishing()
before unbinding in your onPause()
. If it is finishing, you would defer the unbinding to your onDestroy()
method. Before onDestroy()
is called, however, you could persist your ServiceConnection in the onRetainNonConfigurationInstance()
method. If you do perform that persistence, than you wouldn't actually call unBind()
inside of on your onDestroy()
at all and simply let the new instance of your Activity do the unbinding.
That being said, depending on your application, you might find it is just easier to start/stop your service.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With