NPE Fragment.mNextAnim about fragnav HOT 8 CLOSED

I am pushing out a fix right now for 1.2.5. I am not 100% sure that it will fix the issue, because I am surprised it is happening the way it is now. Give it a shot and if you continue to see it, let me know.

from fragnav.

Thank you for the response.

I will try it.

from fragnav.

Could you update to 1.2.4 and see if you're still experiencing the issue?

from fragnav.

Uh, sorry, my bad. I am using 1.2.4. Updated comment.

from fragnav.

Got it. Should be a fairly easy fix. I should be able to post a fix in the next couple of days.

from fragnav.

Great! Thanks!

Offtopic: Do you suggest using Fragment getRootFragment(int index) over giving a list of fragments on initialization?

from fragnav.

There's no inherent performance advantage to using one over the other. Using getRootFragment performs lazy initialization of the object vs creating them all at once when you first initialize
FragNav, so technically those are different, but the difference in minimal. Really it's about three things:

1. If you don't know what the root fragments for each tab will be on creation, (i.e., until you actually click on it, you may not know what it's going to be) then you need getRootFragment.
2. Overriding. If you have a base class that's implementing RootFragmentListener, there's some cases where it's nice for the base class to handle a couple of tabs, and then the subclasses handle indexes that are unique to them.
3. Preference. No real reason behind this one, but to me having a function returning what the fragments are seems a bit clearer/cleaner. I can totally see the opposite argument being made and that having a list being made at construction being a bit clearer. So whichever makes the most sense to you, I wanted to have both.

(Theoretically there's a 4th point, which is that if for some reason that rootFragment is lost, it can still call that function and get a newInstance of the fragment. This was handled in the earlier days as a safety precaution, but in reality, if the library is well built, should never have to happen.)

from fragnav.

I experienced this bug too. Now using 1.2.5 hope no crash anymore.
Thank you for the fix

from fragnav.