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.
Related
I wonder if it is a bad idea to pass critical data between application's activities via intent extras.
For example, assume an application have 2 activities: A and B. Activity B will be started by A and A passes some critical information such as password via an intent extra when starting B.
I wonder if this is a dangerous or bad practice in android. For example, can such an approach leak password to other apps? Is there any better way to do so? Generally, do you know any good reference for learning about bad practices in android coding?
Assuming that you're referring to intents that just start specific Activities, I think you don't need to worry too much.
To take advantage of sensitive information in such intents, attacker will need to do at least one of the following:
Find a bug in Android framework that can be exploited
Upload custom ROM with malicious additions to user's device without user noticing
Upload application APK with malicious additions to user's device without user noticing
While all these scenarios can theoretically happen, I wouldn't bother to safe-guard against them in most cases.
As relatively new to the android platform I was given the task of implementing a email client. For this I want to use an service that allways run in the background (client should allways receive emails as soon as the server gets them, requirement from the customer).
Now I've looked into the Service's in android, but can't seem to find any good answer on whether or not the Service should be local or remote.
What would the main advantages/disadvantages be with choosing one over the other? Bare in mind the Service must be running at all times. I know, I know. BAD. But it is essential to core features of the application.
First, the correct/efficient way to do instant notifications from a remote server like this on Android is to use Google Cloud Messaging. GCM lets you remotely wake up the device by sending an Intent to your application, which you can then use as a signal to fetch the message from the server, post a notification to the status bar, etc.
Doing what you're describing with an eternally running service will have a significant effect on battery life unless you get everything exactly right. Keeping the phone awake all the time is not a viable option. Use GCM and do not roll your own solution for this.
But since your question was more general about whether to run a service in a separate process, in general simpler is better and in this case simpler means running in the same process. You'll have access to all of the various elements of your app's process in memory and in general you will probably have a much easier time. Your events will all happen on the same main thread's Looper. Everything will be much more straightforward.
If you don't already have a very good reason for using a separate process for your service, you should run it in the same process.
Generally I don't know the reason why you can want to use another process. If you will - you'll have to deal with Inter-process communications, with all this AIDL, Parcels etc.
And if you will keep the same process - it will be much easier to transfer the data between your components.
The only reasons to make several processes I think is to try to avoid Android Heap budget limitation. You can try to move heavy objects between processes and try to double your limit. However I think you don't need this, also it's bad way too.
So I will recommend not to play with processes and keep things as simple as possible.
Good luck
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.
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.