Scope: Have to update activity UI in different ways. Update depends on broadcasts received from service.
Problem: There are two common ways to find out which way UI should be updated:
register only 1 broadcast receiver but put different extras in its intent and check for them in OnReceive() method in activity;
register broadcasts for each update command.
The 2nd ways seems to be more elegant and more understandable. But I wonder if it will consume more memory. What would you recommend? Thanks!
It should not make a major difference either way.
I agree with CommonsWare. From a perfomance standpoing this isn't really something you need to worry about. That said, I'd probably go with 2nd way for the sole reason that it will make your code more modular thus improving maintainability.
Related
I would like to describe how the communication in my app works in the hopes that someone can tell me if it's good/bad/just okay design.
My app is single Activity multiple Fragments. The Activity has several generic functions such as show/hide a Progressbar animation on the screen or showing a Snackbar. This is functionality that should only be implemented in one place.
My Fragments send broadcasts whenever they need functionality that is not in the Fragment. For example, if the Fragment wanted to show a Snackbar message, I would send a broadcast like this:
localBroadcastManager.sendBroadcast(new SnackBarIntent("Show this text"));
The Activity receives this broadcast, and shows the Snackbar message. Of course, this is a one way message. My Fragment doesn't know if the broadcast was received. But all in all, it works. I can send broadcasts from anywhere, a Service, an Adapter, etc. I can also send Broadcasts between Fragments if I wanted.
I understand there are alternatives to this. There is an EventBus. Or I could pass a reference of the Activity into the Fragment, Adapter, etc. To me this sounds like a terrible idea that could prevent proper garbage collection.
Then there is RxJava where I guess my fragment subscribes to an Observable that I get from the Activity.
But the question remains, is it bad to use BroadcastReceiver in this way? And if so, why?
Is it wrong? No, they were meant for things like this. I'd make sure I was using a local broadcast and not a global one, for efficiency. Some of the alternatives may provide a nicer API or more features, but they all do more or less the same thing.
I would say that unless the part of the code that broadcasts is really buried that you're better off with interfaces and method calls than broadcasts. The problem with any kind of event broadcast is that it decouples the sender and receiver. That can have advantages when you'd otherwise need to pass objects through multiple levels or to places that shouldn't know about that part of the system. But it has drawbacks in maintenance, especially if multiple places can put similar messages on the same bus.
I found a lot of useful answer on this great site that helped me a lot in learning app programming. Now it's my time to make a question as I cannot find something similar. Things are: I have an activity (suppose main activity) that uses a class to execute various background operation with async task. In the onPostExecute method I return values to the main activity using a public static method (es. MainActivity.setResult(asyTaskResult); my question is: is this the correct way to handle the result? Should I use a broadcast receiver? Are there any better methods to use? I'm new In posting questions and I don't really know if I made it in the correct way. I will appreciate any help or link pointing to a useful answer. Thanks in advance.
is this the correct way to handle the result?
Probably not, as it is easy to get a memory leak that way.
Should I use a broadcast receiver?
Probably not in the way that you are thinking.
Are there any better methods to use?
Have the AsyncTask be managed by a retained fragment, and have the task talk to the fragment instance, as in this sample app.
Or, use an event bus, such as LocalBroadcastManager, Square's Otto, or greenrobot's EventBus, as in this sample app.
Has anyone really used this? I am so in the habit of registering/unregistering my BroadcastReceivers inside an Activity that I almost stuttered when I saw this. Does this keep all my Broadcasts to my specific Linux Process ID that my app is running on? My Actions and Extras are package specific and the ones that are not are meant to be that way to allow other applications to possibly pick up an intent. I can see one easy use, I just did a test case with an AsyncTask, ProgressDialog, and an Activity. But what is the purpose? Is this for security? I am not a linux guru and was hoping for some input.
Per the LocalBroadcastManager documentation, the advantages are:
You know that the data you are broadcasting won't leave your app, so don't need to worry about leaking private data.
It is not possible for other applications to send these broadcasts to your app, so you don't need to worry about having security holes they can exploit.
It is more efficient than sending a global broadcast through the system.
You can also take a look at the LocalBroadcastManager source if you'd like to determine exactly how it works.
How much performance does it costs to broadcast intents?
Is it okay to broadcast multiple per second or are intents expensive?
Intents are meant to launch different activities within the Android OS or to inform about basic actions. It seems like a bad design pattern to use them otherwise. As they travel between different processes and therefore implement the Parcelable interface, they are not the most light-weight.
If you are looking to update different activities at the same time you might consider using a common service.
According to this blog post, intents are 10 times slower than direct function calls
http://andytsui.wordpress.com/2010/09/14/android-intent-performance/
It doesn't cost THAT much, but think of it the same way as you would a broadcast in a network environment. If you want to continually send a message to a device, you wouldn't send broadcasts every 100ms. That would just flood the network. Sending a broadcast once every, say, 10 seconds might be appropriate though.
What exactly the best implementation is entirely depends on what you're doing. In certain circumstances, if you have several services running that need to be run independently, and you're only broadcasting these intents that fast for say, 10 or 15 seconds. That might be ok.
But we can't really say.
I can find several examples of how to build a service, but I'm having a difficult time finding a working example of how to send messages between an Activity and a Service. From what I can find, I think my options are to use Intents, AIDL, or to use the service object itself as per this question.
In my case, my activity is the only activity that will ever access the service, so a local service will do. When the activity is open, I want to see some status messages from the service, which will be coming in at up to 20 Hz. Are there any limitations on how many messages per second those communications methods will support? Basically, which method is going to be best for my situation?
Thanks.
Since your Actvity and Service are a part of the same app, then no need to use AIDL. You may simply use your Service as a local one.
The limitation is only affected by the performance of your device. There is no cap on requests per second.
Usually there is a context switch involved, that uses quite a lot of cpu (compared to other parts of the transmission), but since you use a local service you don't suffer from that. In any case, 20Hz is not a problem.
The best solution for you would be to use AIDL, and set up a callback that the service can call to report its status.
There is good example of how this is done in the APIDemos.