January 14, 2014

Android. Support library. Nested fragments and startActivityForResult()

This post will be dedicated for nested Fragments from support library and for their big issue.

There are available methods inside Fragment: startActivityForResult() and onActivityResult(). First one just delegates invocation to FragmentActivty.startActivityFromFragment(), and second one is called from FragmentActivity.onActivityResult().

If this behavior just wrapped around Activity, then how result is delivered into Fragment instance?

All magic is hidden inside method's argument requestCode. FragmentActivity allows to use only 16 lower bits for external purposes. Higer 16 bits used to store private index of Fragment inside FragmentManager:

FragmentActivity replace requestCode by modified one. After that, when onActivityResult() will be invoked, FragmentActivity parse higher 16 bits and restore index of original Fragment. Look at this scheme:

Well, this dirty bitwise hack allows us to start Activity for result from Fragment and handle answer inside Fragment. So, what's the problems?

If you have few fragments at the root level there is no problems. But if you have nested fragments, for example Fragment with few tabs inside ViewPager, you guaranteed will meet with a problem (or already met it).

Method Fragment.onActivityResult() will not be called for nested fragments.

Because only one index is stored inside requestCode. That is index of Fragment inside it's FragmentManager. When we using nested fragments, there are child FragmentManager, which has own list of Fragments. So, it's necessary to save whole chain of indices, starting from root FragmentManager.

How to correct this? We have only 16 bits allowed to use in requestCode. I tried to totally skip default behavior and use whole 32 bits, but FragmentActivity throws Exception inside it's methods (see picture 1) if you try to use higher 16 bits yourself. I created issue on bug tracker which describe this situation.

While it is not fixed, all we can do - use lower 16 bit to store fragments chain and externally used requestCode.

In the real app there are not so many Fragments. From 1 to 4 Fragments on one screen are in the typical app. Rare app will has deep structure of nested fragments - just 1 or 2 levels of nesting with ViewPager. To store theirs indices int variable is very big (one int for one index). So, we can significantly reduce usage of precious bits to store indices. 

For example, using 3 bits we can store numbers from 0 to 7. Reserving 3 levels of depth we will spend just 9 bits of allowed 16. There are 7 bits (values from 0 to 127) available for external usage.

You can clone and check this solution from the github. If you checkout "Initial commit" you will see problem which is described above. In the HEAD of repository problem is fixed.

Of course, this solution make much more restrictions.
  • We can't use requestCode more than 127.
  • We can't place more than 3 levels on nested fragments.
  • We can't use more than 7 fragments on one level.
But look at the real app - this limits are quite suitable!

Well, if you read this, that means post was interesting for you. Thanks so much!
I'm waiting for comments, critics, improvements, counter arguments and bug-reports.

Sources from this post available on github. Subscribe and check for updates.


  1. After reading your article I was amazed. I know that you explain it very well
    Java Training institute Coimbatore I am mani lives in Chennai. I have read your blog, its really useful for me. I did java development course in coimbatore at reputed java training centre this is useful for me to make a bright career in IT industry. So If anyone want to get best please vist Qtree Technologies.

  2. certainly like your website however you have to test the spelling on several of your posts.
    Several of them are rife with spelling problems do my homework assignment online and I find it very troublesome to inform the truth however I will certainly come back again.

  3. Reliability – we provide our services 24 hours a day, 7 days a week as needed and will always be available when asset protection in London
    you need us. For example, for our residential security in London, we will be in charge of opening gates and doors, screening visitors and mail,

  4. Innovation – with the constant changes in technology, there is an increased need for innovation. At UK Close asset protection in London
    Protection Services, we continuously improve our safety management skills to ensure we are best equipped to deal with new threats before they become apparent and become a danger.