In Virgil Dobjanschi talk during Google I/O he mentioned using Services for doing the fetching and then using a callback to notify the Activity when this was completed. He never went into specifics on how to implement this callback and I can't seem to find anything helpful on this topic anywhere.
I think he said that you didn't need to implement binding at all?
Any clues?
Option #1: Service sends a broadcast Intent, which the Activity catches via a BroadcastReceiver registered via registerReceiver().
Option #2: If the Activity is binding to the Service, have the Activity pass a listener to the Service, which the Service invokes when the work is complete.
Option #3: Service doesn't do much, but the ContentProvider calls notifyChange() when the data changes, which can ripple back through to the Activity and/or its Cursor on the data.
Option #4: Singletons, which should be avoided.
...
Option #237: Service sends a letter via FedEx to the Activity. :-)
...
All that being said, once they release the Twitter app as open source, you'll know for certain what the Twitter app does.
Check out the Google I/O 2010 app. It uses the pattern he was referring to. It uses Option #2 from CommonsWare's answer.
i think they're talking ab out using AIDL to communicate between the activity & the service...
Related
I'm trying to develop an Android application consists of an Activity and a Service. The Activity launch a process on the Service of indefinite duration, which will be closed from Activity. Do not use then the subclass IntentService, but directly Service. Controlled by onStartCommand and OnDestroy.
I obviously need to pass information from the Activity to the Service: the status of the Service and some strings.
I tried to use LocalBrodcastManager, but when turning the devices or when the activity goes in state onPause, the message will lost. I tried to follow several examples, but with little success. This in particular I could not complete it because of some missing information, evidently deemed obvious, but which are not obvious to me: https://developer.android.com/training/run-background-service/report-status.html
I then tried to use Messenger via IBinder ( Example: Communication between Activity and Service using Messaging ), But the program seems a bit complex and I can not able to fit my needs.
What I need is to launch the service from my activity (possibly make binding automatically?, in case of Messenger use), the Service should signal the Activity to be active, then Service records some points via GPS LocationListener, writes it to a file and should point out, again the Activity, the data that is recording, the file size, etc.
What do you recommend to use to pass this information and can you provide to me some example?
I am actually in the midst of a tutorial explaining and comparing many different approaches to IPC in Android but since it's not ready and because you need an easy fix i'll recommend https://github.com/greenrobot/EventBus.
Also feel free to look in an old but still relevant example me and my friends made a while back here: https://github.com/RanNachmany/AndconLab
Goodluck.
My android application needs to communicate with a couple of Rest Services. Now i am decided to avoid using AsyncTasks for this. My architecture will be based on one Service and a couple of Intent Services. Each of my activity will send an intent containing parameters to a single service. Based on these parameters, the Service will invoke various IntentServices. The intent service will then perform the network operations and broadcast the result back into the calling activity. Is this approach correct ? Might be an idea for the Activity to directly invoke the IntentService ? What are the cons of this approach ?
Kind Regards
Use robospice :)
Motivation :
http://thumbnails.visually.netdna-cdn.com/RoboSpice_508a372b320e5.png
the WebApp i.e. the REST service should answer with a response very quickly (so the client app doesn't lock). If your request takes some time to process, the response should be 202. So you may have to look up that resource again, and that is indeed a nice job for AsyncTasks.
You can use RESTDroid that implements the service pattern designed by Virgil Dobjanschi in the Google IO video
(I have a remote service with an AIDL interface that is used by several client apps. I would like to add an asynchronous method to the interface for calls that take some time, but I need the solution to be secure, meaning that only my applications can communicate with the service. The client applications are signed with the same signature as the service app. Currently the apps just bind to the service and call a single interface method to perform various operations.
One option is broadcasting an Intent from the service when the operation is complete and using a BroadcastReceiver in the client application, but (Question #1) can this be done in a way that ensures only my apps can receive the Intent? setPackage() seems to do this, but I need to support Gingerbread devices, which seems to rule out that approach according to the answer here: setPackage for intent in gingerbread
So it seems I need to add a second .aidl interface with the callback interface for the service to use, implemented by the client. I have seen examples that use listeners here, but I am not sure what the difference is versus the client just passing in the second interface object as an argument (as used in the IScript / IScriptResult example from this answer: Service call backs to activity in android)
Question #2, what is the benefit of using a listener here vs. a callback method?
A callback method/listener is the right thing to do. (As CommonsWare says, it's pretty much the same thing). I would say it's much simpler than fiddling around with BroadcastReceivers, since you're already using aidl.
Something like this:
IAsyncThing.aidl:
package com.my.thingy;
import com.my.thingy.IAsyncThingListener;
interface IAsyncThing {
void doSomething(IAsyncThingListener listener);
}
IAsyncThingListener.aidl:
package com.my.thingy;
import com.my.thingy.IAsyncThingListener;
interface IAsyncThingListener {
void onAsyncThingDone(int resultCodeIfYouLike);
}
You can enforce that only your apps can bind to the service by using a signature-level permission on your service (see the note on 'service permissions' here: http://developer.android.com/guide/topics/security/permissions.html). Specifically:
Declare a permission in your service's AndroidManifest.xml. Ensure it is signature level.
Add that permission in your service tag
In all the other apps, use uses-permission to use it.
A couple of other things to bear in mind:
In the caller, you'll need to subclass IAsyncThingListener.Stub. Your calling application code may already be subclassing something else, so that means you'd have to use an extra (probably inner) class to receive the completion notification. I mention this only because this might be the answer to question #2 - which I don't fully understand.
If the service is potentially in different processes from the caller, each should register for death notification of the other using IBinder.linkToDeath.
I'm currently learning to develop for Android and I'm having a somewhat hard time figuring out when and how to use services. I have already seen the numerous questions asked about very similar things, but I can't quite find the exact answer to my questions.
I have an app which talks to a restful api. I fetch several lists which I would like to cache in memory and only update if the user hits a refresh button, or certain activities are created. If a list is refreshed, sometimes several activities need to be notified, so that they update their content (if they are on screen at the time). I store the data I retrieve in value objects.
On a non-android app I would usually create a sort of dataproxy class in a singleton pattern. I could ask the dataproxy to update its data via http request, and then it would send some kind of system-wide notification as soon as the data is changed, so the interested views can all be updated. I hope this makes sense.
My question is now: How do I do this the android way? Do I bind and unbind to a dataproxy service, which I can actively ask to fetch certain data? Should I do my non-persistent caching in this service or somewhere else? Do I need AIDL, or can I just use normal objects for moving data between a service and an activity? Although I find the android dev guide pretty well written and useful, I haven't found much information on services best practice.
Thank you in advance!
How do I do this the android way?
You assume that there is a single "android way".
Do I bind and unbind to a dataproxy service, which I can actively ask to fetch certain data?
You can either bind, or send commands via startService().
Should I do my non-persistent caching in this service or somewhere else?
If you're sure that you only want it to be in RAM, I'd lean towards static data members. Make the service be the "do-er", not the store.
That being said, I'd treat this more as a synchronization pattern, with the real store being a database or directory, with a cache in RAM. Users will find this less frustrating -- under your current plan, if they are in your app, then take a phone call for a while, they'll have to have you download all the data again.
Do I need AIDL, or can I just use normal objects for moving data between a service and an activity?
If they are all in the same process, normal objects is fine via binding, or use Intent extras for the command pattern.
Now, back to:
How do I do this the android way?
Option #1: Wrap your store in a ContentProvider and use ContentObserver for changes.
Option #2: Have your service send a broadcast to your package when the data changes, so the foreground activity can find out about the change via a BroadcastReceiver registered via registerReceiver(). Other activities simply grab a fresh look at the data in onResume() -- the only one that immediately needs to know of the data change is the one the user is interacting with, if any.
Option #3: Use the binding pattern with the service, and have the foreground activity register a listener with the service. The service calls the listener when data is updated. Once again, ather activities simply grab a fresh look at the data in onResume()
Option #4: Cook up your own listener system as part of your static data members, being very very careful to avoid memory leaks (e.g., static reference to an activity or service that is destroyed, preventing its garbage collection).
There are probably other options, but this should get you started.
The Google IO session mentioned by Andrew Halloran:
http://www.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html
Check out the Google I/O session videos. I implemented REST api calls the easy BUT wrong way. It wasn't until watching this Google I/O video that I understood where I went wrong. It's not as simple as putting together an AsyncTask with a HttpUrlConnection get/put call.
I'm new to Android development and I couldn't find this in the Dev Guide.
I would like to create a background service so that any other app could connect to it and get some data from it. I saw android.app.Service, but it seems that it only allows other apps to ping the service, it doesn't allow them to register for some specific events.
I had in mind something like the built in LocationManager and its addProximityAlert or even requestLocationUpdates.
Is anything like this possible with the existing sdk?
maybe this sample could help you: RemoteService.
This is the description from android developer site:
Remote Service Controller and Remove
Service Binding
Demonstrates starting a service in a separate process, by assigning
android:process=":remote" to the
service in the AndroidManifest.xml
file. Shows how those clients can
either start/stop it with {#link
android.content.Context#startService
Context.startService} and {#link
android.content.Context#stopService
Context.stopService}, or bind and call
it with {#link
android.content.Context#bindService
Context.bindService} and {#link
android.content.Context#unbindService
Context.unindService}. Binding is
similar to the local service sample,
but illustrates the additional work
(defining aidl interfaces) needed to
interact with a service in another
process. Also shows how a service can
publish multiple interfaces and
implement callbacks to its clients.
Hi and welcome to android development. I hope you enjoy your stay :D.
About your question:
What you are asking is done with a Service.
If you want apps to register for events what is usually done is the following:
Create the service with all the logic.
Make the service send a Broadcast msg.
All interested apps will have a receiver class to get that msg.
I would like to know what you are trying to do to give you further assistance.