I am looking for the best approach to share data between a service and 2 different clients (an app and a widget). Currently my application kicks off a thread that downloads a large amount of data every 15 seconds or so in the background, stuffs them into an object graph, which is then consumed by the main app on a configurable time interval. This works for the primary app but isn't sufficient for the widget that I want to develop as well, because the object graph will be out of process (and the approach is kind of messy IMO).
So I am looking to extract the data retrieval part into a service (or if there is a better suggestion, something else). My question is, what is the best way to communicate the data received from this service with the clients? Or would you not use a service and instead use something else?
Because of the overhead on the client, I want the service to notify the clients when data is ready as opposed to the client continuously polling the service.....if possible...of course.
I have looked at broadcasting the intent (both app and widget would receive) but I think I have to serialize the entire object graph and then inflate it in the client in order to do that. Is that correct? I am concerned with the speed at which I can accomplish the re-inflate client side.
Is there a better way to ship the data back to the clients? I would prefer to ship the objects if that is possible and not serialize...but if that is the best way, then I will do it.
Any help is greatly appreciated!
I think I have to serialize the entire object graph and then inflate it in the client in order to do that
passing large amount of data on an Intent extras and serializing / de serializing it is indeed not a good approach.
Because of the overhead on the client, I want the service to notify the clients when data is ready as opposed to the client continuously polling the service
since the class responsible for managing your widget extends AppWidgetProvider, it's automatically extends BroadcastReceiver, so it's simple sending some broadcast directly to it whenever you want, in case you did not know.
Is there a better way to ship the data back to the clients?
the right approach would be sending broadcast to the clients indicating that new data is available, but not pass the data itself on the intent. instead - store the data on SQLite database (with or without a ContentProvider) when the thread responsible for the network respond parsing it (probably initiated from your Service from your description). then it sends the broadcast that all client will receive and fetch the data from the database.
I strongly recommends you to see this video, explaining how to implement REST servers client and data consuming best approach.
Currently my application kicks off a thread that downloads a large amount of data every 15 seconds or so in the background
this is not a good idea at all. your user's battery will die very soon, and you'll get very bad reviews when user's will realize that your app draining their battery and consuming all the 3G/4G bandwidth.
instead of pulling, you should use GCM technology. the main idea is that the responsibility to notify when new data is avilible passes from the client side to the server's side, and you won't have to pull all the time to check if there is updates or not.