0

I'm developing an Android application that holds a socket connection open to a message server. I have a set of runnables that spawn their own threads and handle the connection / maintaining the connection. These are invoked from a foreground service. The foreground service is to handle all of the message processing / business logic. This is going to be nothing too complex, it'll involve manipulating XML, trawling through an SQLite DB. The activities will be thin and dumb - passing everything to the foreground service.

I was looking at a tutorial on mindtherobot.com that details building a basic twitter client, with a background service that periodically polls the Twitter API and passes that data to the activity. (I don't want to post an actual link to it as it's showing up on Google atm as being malware infested / harmful). For doing that, it uses a remote service.

Using the remote service means that it touches on AIDL to handle IPC, rather just using binding.

What I'm not sure about is there any need to do this. My service will not be used by any 3rd party application - and from what I've read it is frowned upon to use a remote service unless it's strictly needed (as it doubles on overheads).

In the future, I may want to add widgets to display notifications that have come from the foreground service - would this change anything wrt remote services?

Mark
  • 179
  • 1
  • 6
  • 15

1 Answers1

0

The standard pattern for this is to use:

  • Handler to fire a periodic Intent
  • BroadcastReceiver to listen for said intent. When it wakes up, poll the server and store any new data
  • ContentProvider to provide the data to the Activity

Be sure not to fire the periodic Intent too often, otherwise you'll drain the battery.

Then again, you could instead make a server that pushes the data over C2DM.

Yusuf X
  • 14,513
  • 5
  • 35
  • 47
  • It connects to a 3rd party server via the socket. I cannot make changes to that. The socket connection is vital; we need to be able to check if a client is online and the messaging needs to be as near to realtime as possible - polling is not an option, and nor is C2DM at this stage. – Mark Apr 26 '12 at 15:06
  • Oh. If you're (mayhaps) using XMPP, [asmack](http://code.google.com/p/asmack/) could do that for you; otherwise, keep the socket in [IntentService](http://developer.android.com/reference/android/app/IntentService.html) which is Service but with its own thread, and communicate with [Handler](http://developer.android.com/reference/android/os/Handler.html) which is easier than AIDL. Beware, keeping a socket open eats batteries. – Yusuf X Apr 26 '12 at 18:43
  • The socket connection is already in it's own thread, and communicates with the foreground service via a handler. I'm on about tying the foreground service to the activities and wanting to know if the foreground service should be remote or not. – Mark Apr 27 '12 at 07:06
  • Using [IRemoteService](http://developer.android.com/guide/developing/tools/aidl.html) just means AIDL, it's not related to whether or not your service is [foreground](http://developer.android.com/guide/topics/fundamentals/services.html#Foreground) which means "don't kill for memory". – Yusuf X Apr 27 '12 at 08:17
  • I'm not worried about it being killed, I understand what foreground does. I was just puzzled as to why the tutorial I was reading showed using a remote service for communicating with the Twitter API instead of just service. My service will be doing more expensive work than the a twitter service, so wondering if it's going to impact the responsiveness of my activities.. but if it's all done in discrete threads it should be fine. – Mark Apr 27 '12 at 08:44