IBR-DTN Android service from another Android app
Hello everyone,
I’m developing an Android app that uses IBR-DTN for Android. How can I start the DTN service from IBR-DTN from my application? I haven’t found it in the documentation. I have tried to call the service like this:
Intent new_service = new Intent("de.tubs.ibr.dtn.service.DaemonService"); new_service.setAction("de.tubs.ibr.dtn.action.STARTUP"); this.startService(new_service);
but it does not work.
Thanks!
Abraham.
Ops, I found why it isn’t working. It checks if the SharedPreference “enabledSwitch” is true before starting the process. I can’t change it from my app as the SharedPreferences are in private mode. Is there any way to change the value of “enabledSwitch" through the API?
Thanks a lot,
Abraham. On 28 January 2014 at 17:21:25, Abraham Martín (abraham.martin@cl.cam.ac.uk) wrote:
Hello everyone,
I’m developing an Android app that uses IBR-DTN for Android. How can I start the DTN service from IBR-DTN from my application? I haven’t found it in the documentation. I have tried to call the service like this:
Intent new_service = new Intent("de.tubs.ibr.dtn.service.DaemonService"); new_service.setAction("de.tubs.ibr.dtn.action.STARTUP"); this.startService(new_service);
but it does not work.
Thanks!
Abraham.
Hello Abraham,
the choice to enable / disable the background service for DTN is left to the user alone. I do not know any argument to give Apps the permission to do that. If you require that the user enables the daemon, you can ask him to do that and then open the daemon preferences.
Kind regards, Johannes Morgenroth
Am 28.01.2014 18:47, schrieb Abraham Martín:
Ops, I found why it isn't working. It checks if the SharedPreference "enabledSwitch" is true before starting the process. I can't change it from my app as the SharedPreferences are in private mode. Is there any way to change the value of "enabledSwitch" through the API?
Thanks a lot,
Abraham.
Hi Abraham,
you could add anotherBroadcastReceiver [1] in the Preferences class that changes the state of the daemon (as you said, the pref is called "enabledSwitch"). You could then fire an intent from your application to start/stop the daemon when needed. It's probably just a few lines of code. By the way, I think it's reasonble in some situations to start the daemon automatically if an app that requires the daemon is started.
Best regards, Christian
[1] http://developer.android.com/reference/android/content/BroadcastReceiver.htm...
Am 29.01.2014 07:54, schrieb Johannes Morgenroth:
Hello Abraham,
the choice to enable / disable the background service for DTN is left to the user alone. I do not know any argument to give Apps the permission to do that. If you require that the user enables the daemon, you can ask him to do that and then open the daemon preferences.
Kind regards, Johannes Morgenroth
Am 28.01.2014 18:47, schrieb Abraham Martín:
Ops, I found why it isn't working. It checks if the SharedPreference "enabledSwitch" is true before starting the process. I can't change it from my app as the SharedPreferences are in private mode. Is there any way to change the value of "enabledSwitch" through the API?
Thanks a lot,
Abraham.
-- !! This message is brought to you via the `ibr-dtn' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to ibr-dtn-request@ibr.cs.tu-bs.de !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/ibr-dtn.
Am 29.01.2014 09:40, schrieb Christian Raffelsberger:
By the way, I think it's reasonble in some situations to start the daemon automatically if an app that requires the daemon is started.
Let's start a discussion on that. :-)
But first, I like to explain something. The on/off state of the daemon only affects the networking behavior and if the process will stay running in background. An application can always send and receive bundles, even if the daemon is switched off. Since the network behavior effects the users battery and the background process reduces the memory consumption, I prefer to leave the authority to switch the daemon on/off to the user alone.
Now I am curious to know which situation you consider as reasonable to switch the state of the daemon in the applications.
Kind regards, Johannes Morgenroth
Am 29.01.2014 10:23, schrieb Johannes Morgenroth:
Am 29.01.2014 09:40, schrieb Christian Raffelsberger:
By the way, I think it's reasonble in some situations to start the daemon automatically if an app that requires the daemon is started.
Let's start a discussion on that. :-)
Oh, I was afraid this was going to happen ;-)
But first, I like to explain something. The on/off state of the daemon only affects the networking behavior and if the process will stay running in background. An application can always send and receive bundles, even if the daemon is switched off. Since the network behavior effects the users battery and the background process reduces the memory consumption, I prefer to leave the authority to switch the daemon on/off to the user alone.
Now I am curious to know which situation you consider as reasonable to switch the state of the daemon in the applications.
I thought about the battery problem aswell. Thus, I said "in some situations". For instance, we have written a prototype application that can be used by fire fighters or other first responders to locate victims. One feature that we experiment with is using the bundle protocol to send collected data to the command post. One of the most important requirements is to minimize user intevention (i.e., the fire fighter just activates the device and puts it in his/her pocket). In that case it is not feasible that the fire fighter manually starts the daemon. I know that this is a rather special use case and probably in general you are right that preserving battery is more important than usability.
Best regards, Christian
Am 29.01.2014 12:29, schrieb Christian Raffelsberger:
For instance, we have written a prototype application that can be used by fire fighters or other first responders to locate victims. One feature that we experiment with is using the bundle protocol to send collected data to the command post. One of the most important requirements is to minimize user intevention (i.e., the fire fighter just activates the device and puts it in his/her pocket). In that case it is not feasible that the fire fighter manually starts the daemon.
Why is the daemon not enabled by default in that case? Are the energy constrains are too hard? If "activate the device" means switching the whole device on, the daemon would automatically start-up if the device is booted.
Recently, I have been working on an approach to minimize the energy consumption by disabling the discovery beacons. In this "smart" mode, beaconing is activated only for 2 minutes if the Wi-Fi network is switched. Maybe switching off the daemon for your scenario is no longer necessary with that mechanism.
Kind regards, Johannes Morgenroth
participants (3)
-
Abraham Martín -
Christian Raffelsberger -
Johannes Morgenroth