1

I need a shared list of computers made available to all my app's activities. The list of computers needs to be upated by two background tasks of some kind, one that blocks on a socket waiting to receive data, and another task that periodically purges computers from the list. What is the proper Android way of doing this to avoid running into activity lifecycle problems? Specifically,

  • Can/should I use a singleton to maintain and expose the list to the activities and background tasks? (I'm familiar with thread synchronization issues and am prepared to deal with that.)

  • Can/should I use the IntentService class (two separate instances for the work I need to carry out) or is there a better way? Do I need to use a BroadcastReceiver in that case or could I still store the list in some common place, like a singleton?

  • How do I avoid keeping my services running when my application is put in the background?
soderbjorn
  • 21
  • 5
  • @soderbojn you may want to simplify your post. right now it has too much fluff, a lot will actually be treated as TL;DR... just a recommendation. Think about bullet points, don't make us have to do work to understand what you're saying should be simple and easy to read :) – JoxTraex Aug 27 '15 at 08:18
  • A good example is this : http://stackoverflow.com/questions/32243852/how-to-pass-a-large-collection-between-activities-master-detail-flow – JoxTraex Aug 27 '15 at 08:23
  • 1
    Thank you, I've rewritten my question and hope it's is a little bit more concrete now. – soderbjorn Aug 27 '15 at 08:32

2 Answers2

1

Updated answer for updated question

  • You can use a Singleton if you don't have a problem with losing your data when your app get's killed (e.g. when you can rebuild the data on restart). In this case you should check that all your components run in the same process (which is default).
  • You should not use IntentService for intra-app-communication, however bound Services might be an option here
  • If you bind services from an Activity and unbind them in onPause, they get automatically stopped (if there are no other bound contexts and they weren't started with startService)

If you think your tasks are too complex to accomplish in the same Service, I would recommend two Services bound by an Activity and backed by a ContentProvider which e.g. can be backed by a database.

Old answer

  • The issues you expierenced might be a problem of Thread-safety (or the lack of it)
  • Two Intent Services just to share data within an application is definetly way over the target
  • A broadcast is the right way to notify components of a change
  • You might want to take a look at Content Providers
  • Another solution might be a service, which can be bound by all your other components
F43nd1r
  • 7,690
  • 3
  • 24
  • 62
0

You can use Database to maintain the UDP packets with timestamp. Also periodically check the last sync time from Database to check whether UDP packet is coming or not. Hope you know how to use Database.

Ashish Vora
  • 571
  • 1
  • 8
  • 27
  • Thanks for the advice. I assume you're referring to the android.database package? In my case I'm thinking it's overkill since I don't need to keep any state between application re-starts, the list should only live as long as one of my activities is in the foreground. – soderbjorn Aug 27 '15 at 08:37
  • For that you can use ArrayList with Data Type Object. This will store your data as long as Activity is in foreground. – Ashish Vora Feb 10 '16 at 06:24