In my app I have used IntentService and in it I call a webservice and parse my response. After my parsing is done I want to update the UI.
I saw that there is a way to update UI using broadcast receiver but is there any other way to update UI if I don't want to use broadcast receiver. If so then please share the link.
You could either make a bound Service, or use some lib like EventBus.
From the Android docs:
A bound service is the server in a client-server interface. A bound
service allows components (such as activities) to bind to the service,
send requests, receive responses, and even perform interprocess
communication (IPC). A bound service typically lives only while it
serves another application component and does not run in the
background indefinitely.
If you want to use this approach, you'll have to create a Service that implements the onBind() method. This method will return an IBinder that you'll also have to implement. And that Binder will use an interface, that again, you'll have to create.
Example:
MyService.java
public class MyService extends Service {
// ...
#Override
public IBinder onBind(Intent intent) {
return new MyBinder(this);
}
}
MyBinder.java
public class MyBinder extends Binder {
private MyServiceInterface mService;
public MyBinder(MyServiceInterface s) {
mService = s;
}
public MyServiceInterface getService() {
return mService;
}
}
MyServiceInterface.java
public interface MyServiceInterface {
int someMethod();
boolean otherMethod();
Object yetAnotherMethod();
}
For more details, you can check the docs I've linked above.
Downside of this approach: Regular Service class doesn't run on the background as IntentService do. So you'll also have to implement a way of running things out of the main thread.
And from EventBus page:
simplifies the communication between components
decouples event senders and receivers
performs well with Activities, Fragments, and background threads
avoids complex and error-prone dependencies and life cycle issues
To use EventBus, the best way to start is following the documentation.
So, either of those approaches seems to be a good choice for you, just as using the BroadcastManager (which I don't know why you can't use it).
Related
The scenario is like this: I have an activity and a service. There are a few things that need to be sent between both:
the activity can query the service to see if running
the activity can query the service for variable value
the activity can ask the service to perform action (run a method of it)
the service can send response to the activity on action
the service can respond back to activity on activity call
Since this looks more as a two-way communication, I am thinking of using LocalBroadcastManager and have something like:
public class MyActivity extents Activity{
private void receiver = new BroadcastReceiver(){
onReceive(){
//Handle Message from Service
}
}
onResume -> LocalBroadcastManager.registerReceiver(receiver);
onPause -> LocalBroadcastManager.unregisterReceiver();
}
and for service
public class MyService extents Service{
private void receiver = new BroadcastReceiver(){
onReceive(){
//Handle Message from Activity
}
}
onStart-> LocalBroadcastManager.registerReceiver(receiver);
onDestroy-> LocalBroadcastManager.unregisterReceiver();
}
This would allow to avoid binding or other methods of communication between app components but in the same time allows both to sent intents and listen for observers. Are there any drawbacks on this method?
There shouldn't be.
This is the recommended way of cross-component communication within an Android app. You're doing exactly what Google recommends, with local broadcasts instead of global broadcasts.
In a comment, you mentioned that binding a Service is usually what to do for Activity->Service communication. You don't need to use this in most cases. Binding a Service is kind of annoying, since it isn't instant and you need to use a listener to store a reference to the Binder. Broadcasts, in comparison, are relatively simple.
Looks like your activity should just bind to the service to get a Binder instance that you can use to access service methods. The service can send local broadcasts that the Activity can observe with Broadcast Receivers. My recent preference is have the service methods return LiveData instances that can be observed instead. LiveData objects are lifecycle aware so any observers will know to clean up after themselves.
I want to create an interface which will interact with an already running Service from the Activity in foreground.
viz, if there is a service called MyService running in background and I want to use the methods defined in the service from an activity called MyActivity then how will I do it.
There are several possibilities for an activity to communicate with a service and vice versa.
LocalBroadcast receiver that is provided by Android framework , v4 support library also provided.
AIDL for services in a different process
Handler and ResultReceiver or Messenger
To get details implementation visit following links :
http://www.vogella.com/tutorials/AndroidServices/article.html
http://developer.android.com/guide/components/services.html
You need to make your service bindable. or more specifically something like this LocalService taken from the android guide.
The above answers are pretty apt ....but if you are bent on interfaces then... below is how one can do using interfaces ...but a better and more preferred way is described here
Create a Interface with a function as below:
public interface OnChangeListener {
void onChange();
}
then in your service :
private OnChangeListener changeListener;
public void setChangeListener(OnChangeListener changeListener) {
this.changeListener = changeListener;
}
Some where in your service :
changeListener.onChange();
then from your Activity do this :
MyService.getInstance(this)
.setChangeListener(new OnChangeListener() {
#Override
public void onChange() {
// do something here
}
});
I'm writing a helper class for my activity, which uses an external service. Like in a standard design pattern regarding bound services, I want to bind on activity creation and unbind on activity destruction. However, I want to isolate this logic to my helper class, so that activity would only use an instance of that helper and don't call bind and unbind explicitly.
I can pass the activity to the helper class, but I cannot find any way to schedule a callback on activity's lifecycle's events - there's just no such methods in Activity class. While this most probably means that I cannot achieve what I want to, and also that it's probably not a good idea, I still want to ask the community about this. Is it possible? Is it a good idea? Is it possible to achieve similar results with some other classes (not the Activity)?
I'm new to Android development and I'm seeking for the best practices. Any ideas are appreciated.
Thanks!
EDIT: Basically, I want to be notified on activity creation and destruction. I want to be able to schedule a callback on onCreate and onDestroy methods, but from outside of the Activity. Those methods are protected and therefore inaccessible from other classes.
You can use the Application.ActivityLifecycleCallbacks class. Keep in mind that the class was introduced in API level 14. For lower versions you could make hook methods in your library and require that the target Activity will call the appropriate hook method from its corresponding lifecycle method. Of course, this would be a very fragile implementation.
Lifecycle methods are the means to implement behaviour which will be executed when DalvikVM decides to do something with Activity (pause/resume/create/destroy), not to invoke that behaviour artificially.
If you want to externalise logic in helper/controller of some sort and be able to use service connection do initialization within ServiceConnection handler.
private ServiceConnection mConnection = new ServiceConnection() {
#Override
public void onServiceConnected(ComponentName className,IBinder service) {
...init helper here...
}
#Override
public void onServiceDisconnected(ComponentName arg0) {
...shutdown helper here...
}
};
then handle connections as usual.
I have an Android service which collects data from some external hardware. I am making that data available to my Activities using a callback structure shown here.
The data I'm making available is an ArrayList<MyClass>. While reading the Android API docs, it seems that a suggested way is to use broadcast events and Parcelable. I've also seen callbacks used in Android apps, so the question is what's the advantage of refactoring my code to use broadcasts?
Now, in the future, I am looking to allow external apps to access this service (Tasker, for example), so I'm guessing that the callback method I use will be for use in the local app only. So the question is how to do a callback from a Service to an Activity using an AIDL description.
The way to allow a service to callback into an Activity is to have the service aidl interface define a registration function that takes another aidl interface as a parameter.
ServiceAidlInterface.aidl:
package com.test;
import com.test.CallbackAidlInterface;
interface ServiceAidlInterface {
void registerCallback(in CallbackAidlInterface callback);
}
CallbackAidlInterface.aidl:
package com.test;
interface CallbackAidlInterface {
void doCallback();
}
In your activity you need to define the following:
ServiceAidlInterface mService = null;
private CallbackAidlInterface mCallback = new CallbackAidlInterface.Stub() {
#Override
public void doCallback() throws RemoteException {
}
};
So when the activity binds your onServiceConnected() gets called you can do the following:
mService = ServiceAidlInterface.Stub.asInterface(serviceBinder);
service.registerCallback(mCallback)
I am trying to make a live wallpaper on Android. I have one class
public class MyWallpaperService extends WallpaperService {
}
And annother class:
public class SettingsActivity extends Activity {
}
I need to make the SettingsActivity communicate with MyWallpaperService in order to set values on the live wallpaper. I have used aidl before and have tried to apply it to this situation. However it seems like WallpaperService has the following method:
/**
* Implement to return the implementation of the internal accessibility
* service interface. Subclasses should not override.
*/
#Override
public final IBinder onBind(Intent intent) {
return new IWallpaperServiceWrapper(this);
}
Therefore I cannot return my own custom aidl defined binder in the onBind method of my service due to the final declaration on the superclass, WallpaperService's, onBind method. To me this seems like an oversight by the Android platform development team. Does this effectively removes all possible inter process communication abilities from any live wallpaper?
What are my options here? I know I can put the Activity and the Service in the same process and have the Activity set global variables on the Service, but that seems like it could get messy fast and I want to do this right. Is adding a Broadcast Receiver in the Service the right move here?
You could also use BroadCasts to achieve communication between a wallpaper service and some controller activity, source below.
http://developer.samsung.com/android/technical-docs/Effective-communication-between-Service-and-Activity