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.
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 have a main Activity that's happily been working with a Service I created for a while now. Recently I've had to add a DialogFragment to my app and although its working nicely as well, I now need to make a call to my Service and pass along more than the usual Intent type strings. Basically I need to pass an array of Bitmaps to the Service, and I don't think it's reasonable to try and stuff them into an Intent.
So I was hoping, without luck so far, that I could bind to the service while the DialogFragement is open so I can make a direct method call to the Service.
Is there any way to do this? So I have to copy the entire ServiceConnection class and bind to it from onStart()? I figured there must be a less messy way to do this.
Thanks in advance.
As there is no code, I assume that your DialogFragment serves to capture some kind of input from the user (Yes/No or something similar), as most dialogs do. If this is the case, then you can simply return the input back to the calling Activity and make a call to the Service based on this input. Another question is where to the Bitmaps come from? Passing an array of Bitmaps from an Activity to a Service doesn't seem a good decision for me, you should probably consider moving the Bitmap retrieving logic to the Service itself, whether the Bitmaps come from the network or from resources.
Most part of my answer is based on assumptions about the design of your application, so if those assumptions go wrong you can post some code or add a broader description of your app and I'll be glad to review my answer.
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.
I'm writing a XMPP Client using SMACK.
So when I want to update my contactList - the ListAdapter.notifyDataSetChanged requires to be run in the UI thread, but obviously the SMACK Library uses Multithreading on the RosterListener (which in fact is a good thing). But here is the problem: to run s.th. in the UI thread, I need a valid context.
But how do I get it? Passing the Context of the Activity down to the register function of the RosterListener was the first that came to mind - but I have some functions in different classes there before I even get to the register function, and I don't really like it to pass the context over and over again until it finally reaches its destination, where it will be used.
I guess, I'm not the only one, who has encountered this problem, so how would you solve it?
Maybe a Singleton, just to save this one Context (in my opinion an even less favourable idea...)
Or is maybe my whole design flawed?
Is there a possibility to get the UI thread from anywhere?
Bottom line: I don't really have a clue how to handle it, at the moment I'm passing the context as argument through multiple functions, but is there a better way to do it.
Thanks for any help.
Put XMPP code into Service and then send broadcasts. Interested Activities can simply register for those broadcasts. That way you'll never again worry about UI thread and availability of Activity context.
I found a neater and more modular way of doing it. For this you need to have defined an Application Context. Once you have that, you can call RunOnUIThread from any class library without the mess of having a reference to the Activity.
From anywhere within your class library call:
Handler handler = new Handler(Application.Context.MainLooper);
handler.Post(() => doStuff());
Please bear in mind that this is written in C# as I use MonoDroid, but I believe it is very similar to Java.
For how to create an ApplicationContext look at this thread
I do not get what exactly you try to do but if you are in some thread and you want to shitch back to UIThread than
Looper is your solution
http://developer.android.com/reference/android/os/Looper.html
Reading you, I get a feeling like you are working with callbacks. Smack or whatever that is is calling you back from a worker thread, and you want to post to the main UI thread when that happens.
In my experience, callbacks can always be associated to a custom piece of data, which you pass when registering the callback, and receive when you are actually called back.
In your context there are two approaches which I consider to be poor design:
using any kind of global thingy, call it a singleton if you like
let your Model expect and return the (Android-and-UI-specific) Context
Instead, I would create a small interface which is implemented by the Activity, have the Model accept an instance of this interface, and yes pass it over the different layers until registration.
The methods exposed by this interface will be called asynchronously, which you could document appropriately, to indicate that runOnUiThread() or similar must be used.
This way, you're not exactly passing the Context (which is a platform and UI detail) all over the place and into the Model. Plus, you avoid global/static data, which leads to various problems, conflicts and other memory leaks.
I wanna start an android service but I need to pass some info to it before it starts how can I do this?
There are a few approaches you could take.
Take a look at http://programmerbruce.blogspot.com/2011/04/simple-complete-app-widget-part-1.html for an example of adding a value to the Intent extras, which is then received by an IntentService in onHandleIntent.
Another approach would be to use an AsyncTask, which makes it very easy to provide an arbitrary data structure.
For more ideas, take a look at how Jeff Sharkey's android-sky app handles threading.