Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Android : Do Application Login in background on boot-up

I have a VOIP Application, I need to login the application in background on device bootup.

Currently the init to my application is done on UI Active(onCreate()).

I have the following things in my mind, can anyone help and clear my doubts.

  1. The service design is must to achieve this task??
  2. Which Service Remote(AIDL) or Local Service and why?
  3. How does the UI and Service interaction happens?
  4. After UI is active who gets the Call- Backs? UI or Service?
  5. Should i make Service as my Controller i.e Service to UI data Pass Vice-versa?

Sample App: Skype.

like image 230
NitZRobotKoder Avatar asked Apr 26 '12 10:04

NitZRobotKoder


People also ask

What apps are running in the background on my phone?

To open Quick Settings, from the top of the screen, swipe down twice. To see the number of active apps running in the background: At the bottom left, tap # active apps. Or, at the bottom right, tap the number next to Settings and Power .

Does Android system need to run in background?

Processing data in the background is an important part of creating an Android application that is both responsive for your users as well as a good citizen on the Android platform. Doing work on the main thread can lead to poor performance and therefore a poor user experience.


2 Answers

So there are many ways to achieve what you want, it is a matter of what fits your style and design better. Hopefully you will find this information useful.

  1. For the application to login in the background on startup there are a few option. The first thing you will need is a BroadcastReceiver which is defined as a receiver in the manifest. Have the BroadcastReceiver catch the ACTION_BOOT_COMPLETED intent. From here you can launch your Service. This leads to #2.

  2. If all you are doing are RESTful calls then really an IntentService would be ideal. The difference between an IntentService and a Service is simple: An IntentService runs off of the main thread, executes it's 'code' and dies. A Service, however runs on the main thread (this is an important fact) and is long running so it has to be told to stopSelf(). To take matters further, a Service is also less likely to be killed compared to an Activity (application components are killed to make room in memory for newly launched apps), ie. it takes higher precedence. The service can also be declared a foreground service which requires a notification but give even higher precedence. I think in your case a Service would be perfect.

  3. Once your UI (Activity) is opened the best way to connect to the Service would be the Binder. This will allow multiple interfaces to the Service from different applications / components if need be. AIDL is pretty cool stuff but from my experience much harder to manage since all parameters must be primitive or Parcables. AIDL is also slower an less efficient because it is really a form of IPC. When a Service is started with an intent the onStartCommand() method is called. If the service is started by an application trying to bind to it then the onBind() method is called. But you can start the Service with and Intent and then bind to it. If you prefer the RESTful approach where you just have quick calls for data you can use an IntentService with a ResultReceiver. This is a great article written about Google I/O examples and just overall well implemented if you are interested in the IntentService and ResultReceiver.

  4. This is up to you. Using the Binder or AIDL your Activity can call the Service methods just like object method where the 'callback' would just be the method return. If you use a ResultReceiver the Activity interfacing the Receiver would be the callback. You could also just pass Intents back and forth but this could get messy. Again for your case the Binder approach would be good as well as a Receiver.

  5. Think of the Service as a model in the MVVM system - use it as a helper to get data from, not as something that controls the logic of the application.

Sorry if this seems messy there are so many ways to achieve what you are looking for. Its just a matter of what fits your situation best what you 'feel' is better. Not to mention the Android SDK is pretty large. I tried to hit on all the topics that could help you out. Good luck!

like image 84
jjNford Avatar answered Nov 10 '22 03:11

jjNford


Try a service with a boot reciever. Here is an example I found after a quick google search. Then make sure to store in the login info somewhere for when the app starts. Not sure what callbacks you might have, so really hard to answer that part. I would say that if the callbacks should affect the UI then let the activity take them over when it starts up. If you need a UI when only the service is running, probably best to throw up a notification and have it call the appropriate activity with the callback data.

like image 1
MikeIsrael Avatar answered Nov 10 '22 01:11

MikeIsrael