Android general high level question

CrazYmonkeY159

Expert Member
Joined
Sep 13, 2007
Messages
2,142
Reaction score
0
Location
CPT/PE
So I'm making an Android app which functions (on an architectural level) similarly to Twitter or WhatsApp.

The App basically consists of 2 parts. A login screen (or Intent) and a background process (or Service)

The user will enter his user name and password into the login screen when the program is first started, the intent then logs the user into the service and then if the credentials are valid, a background process is spawned which checks various things and pushes notifications to the user.

In a similar way to WhatsApp this service must be restarted whenever the phone is rebooted or powered up.

So far my thoughts is to have a MainActivity which listens to the powerup broadcast and spawns the service (process) whenever the powerup/reboot event is fired. The service polls various things on a network and pushes notifications if things are being too wierd or broken. I can't use Google Cloud Messenger because I do not have access to the servers.

This is my first real try at this and I'm wondering if my planning at least doesnt sound bad?
 
What type of service are you going to run? Maybe a foreground service etc? It may be worthwhile looking into the ExecutorService, specifically the newSingleThreadExecutor and newSingleThreadScheduledExecutor (for scheduling). Not sure if it will particularly fit in for your application because I don't know what sort of stuff you are doing in your service, but have a look anyway.

Also, what if the OS kills the service due to low system resources? Are you going to handle that? And if you do, do you want the service to start automatically again when resources are available (START_STICKY in onStartCommand) or are you going to leave it as is(START_NOT_STICKY in onStartCommand)? If you do restart the service, are you going to start it from scratch or continue from where you last left off?
If your service is killed before stopSelfResult is called for the last request, you can automatically restart the service by using START_REDELIVER_INTENT, which will restart the service when resources are available again. This auto-restart passes the last intent passed to the service before it was killed.
 
Last edited:
What type of service are you going to run? It may be worthwhile looking into the ExecutorService, specifically the newSingleThreadExecutor and newSingleThreadScheduledExecutor (for scheduling). Not sure if it will particularly fit in for your application because I don't know what sort of stuff you are doing in your service, but have a look anyway.

Also, what if the OS kills the service due to low system resources? Are you going to handle that? And if you do, do you want the service to start automatically again when resources are available or are you going to leave it as is(dead)? If you do restart the service, are you going to start it from scratch or continue from where you last left off?


The network has an intranet web service which when requested (via httprequest or something) returns XML/JSON

So for example there is a temperature service which is somehow connected to a thermometer, this service, when requested returns current the ambient temperature of the room. The Android App is supposed to periodically poll this web service and if the temperature is > x degrees then a push notification is published. it is really kinda simple stuff at this point.

The service, if killed will have to start from scratch as there is no need to keep state in a situation like this i think :o
 
The network has an intranet web service which when requested (via httprequest or something) returns XML/JSON

So for example there is a temperature service which is somehow connected to a thermometer, this service, when requested returns current the ambient temperature of the room. The Android App is supposed to periodically poll this web service and if the temperature is > x degrees then a push notification is published. it is really kinda simple stuff at this point.

The service, if killed will have to start from scratch as there is no need to keep state in a situation like this i think :o

Aah, I see.
 
I thought about this some more and maybe you would rather want to listen for a wifi event, instead of a powerup event, since your app from the sounds of it will probably only work while it is connected to your intranet over wifi. Something like this should do the trick:
http://stackoverflow.com/questions/...ect-when-wifi-connection-has-been-established

Just a though, depends on your exact use case if this is more what you need or not.
 
Top
Sign up to the MyBroadband newsletter
X