Onactivityresult in fragment

On activity result in fragment

One of the common problems we always meet in the world of Fragment is onactivityresult in the fragment. although we could call directlystartActivityForResult from Nested Fragment it appears that wouldonActivityResult never be called which brought a lot of trouble to handle Activity Result from Nested Fragment.

Why does this happen? That’s because Fragment is not first designed to be nested. Once its capability was expanded, the architecture behind Fragment couldn’t cover all the case. And we developers have to handle the problem case by case by ourselves.

But don’t worry, we already have a sustainable and robust workaround for this problem. Ok, let’s start!

The architecture behind Fragment’s startActivityForResult

On activity result in fragment

Although we could call directlystartActivityForResult from Fragment actually mechanic behind are all handled by Activity. Once you call startActivityForResult from a Fragment, requestCode will be changed to attach Fragment’s identity to the code. That will let Activity be able to track back that who send this request once the result is received.

Once Activity was navigated back, the result will be sent to ActivitiesonActivityResult with the modified requestCode which will be decoded to original requestCode + Fragment’s identity. After that, Activity will send the Activity Result to that Fragment through.onActivityResult And it’s all done.

The problem is: Activity could send the result to only the Fragment that has been attached directly to Activity but not the nested one. That’s the reason why onActivityResult of nested fragment would never be called no matter what.

The Solution

This behavior is one of the most popular issues in town. We could found a lot of thread related to this in StackOverflow. There is a lot of workarounds provided by people there. Anyway none of them is sustainable enough to be used in any case (at least all of those that I discovered). So we spend a day research all the mechanic behind and try to find the way to cover all the cases available. And finally, we found one!

The problem, as described above, is the request could be sent from nested fragment but couldn’t be received properly. Thus there is no need to do those things in Fragment. Let them be all done in Activity level.

So we will call fromgetActivity().startActivityForResult(...) Fragment instead of just fromstartActivityResult(...) now on. Like this:

As a result, all of the result received will be handled at the single place: onActivityResult of the Activity that Fragment is placed on.

Question is how to send the Activity Result to Fragment?

Due to the fact that we couldn’t directly communicate with all of the nested fragment in the normal way, or at least in an easy way. And another fact is, every Fragment knows that which requestCode it has to handle since it is also the one that calls startActivityForResult. So we choose the way to “broadcast to every single Fragment that is active at a time. And let those Fragments check requestCode and do what they want.”

Talk about broadcasting, LocalBroadcastManager could do the job but the mechanic is the way too old. I choose another alternative, an EventBus, which has a lot of choices out there. The one that I chose was Otto from the square. It is really good for performance and robustness.

First of all, add the following line in build.gradle to include Otto to our project:

In the Otto way, let’s create a Bus Event as a package carry those Activity Result values.


And of course, also create a Singleton of Event Bus which will be used to send a package from an Activity to all of the active Fragments.


You may notice that I also create a custom method named inpostQueue the bus object. This one is used to send a package onto the bus. And the reason why we have to do it this way is that we have to delay a package sending a little bit since at the moment that Activity’s onActivityResult has been called, the Fragment does not become active yet. So we need to let Handler send those commands to the queue of Main Thread with handler.post(…) like coded above.

And then we will override onActivityResult on Activity and add the following line to send the package to the bus once the result is received.


In Fragment part, we need to listen to the package sent from Activity. We could do it easily in Otto way like this.

That’s all. Fragment's onActivityResult will be called from now on! You can now just simply override onActivityResult, check the requestCode and do what you want.


With this solution, it could be applied for any single fragment whether it is nested or not. And yes, it also covers all the case! Moreover, the codes are also nice and clean.


There is just only one limitation. Don’t use the same requestCode in different Fragment. As you can see, every single Fragment that is active at a time will receive the package. If you use the same requestCode in different Fragment, it may deliver the wrong outcome. Except that you intend to do it, you can.

Make it easy with StatedFragment

Good news! The code we described in this article is already included in our StatedFragment in version 0.9.3 and above. You could now use it easily like this:

Add a dependency in build.gradle


In case you use Fragment from android.app.*, please add the following instead.


To enable it, just simply override a method onActivityResult in the Activity and add the following line:


For Fragment, you could simple extends StatedFragmentonActivityResult will be now useful.


As I said. Easy, huh?

Hope that this article is helpful to you all. Best wishes to you all =)

 3,986 total views,  9 views today

(Visited 1,704 times, 1 visits today)

You May Also Like

About the Author: Android Developer

This is Mohammad I am Android Application Developer. I am the founder of Android Tutorial Online blog. I am programming lover and professional blogger from India. I spend most of my time doing programming and helping other programmers. This Android tutorial online blog for learning and share Android code.
My Chatbot
Powered by Replace Me