Fragment transition when restoring from saved state

[liquidninja24]

Hey Nick,

When restoring from saved instance state the default transition animations are being applied to the current fragment: https://github.com/ncapdevi/FragNav/blob/master/frag-nav/src/main/java/com/ncapdevi/fragnav/FragNavController.java#L901

I believe the call to switchTab should be invoked with an empty set of FragNavTransactionOptions so that the default options are overwritten, and the current tab / fragment is immediately shown.

[ncapdevi]

@liquidninja24 makes sense to me. I'll go ahead and add that.

[liquidninja24]

@ncapdevi Thanks! Any idea when that change would get committed and tagged?

[ncapdevi]

Everything is seemingly stable so I can push an update (2.2.2) this evening.

[liquidninja24]

Sweet, thanks man!

[liquidninja24]

Had a look at the code. I think you need to pass an empty FragNavTransactionsOptions object here:

a478a4e#diff-d9ef9db018ea0b9cdc4dce6b5cbfa071L901

otherwise it'll use the default transaction options as defined here:

FragNav/frag-nav/src/main/java/com/ncapdevi/fragnav/FragNavController.java

Line 670 in a478a4e

if (transactionOptions == null) {

[ncapdevi]

Ah, you appear to be correct, good catch. Apologies for that.

[liquidninja24]

Also, It may be better / helpful to create a static constant to signify no transaction options that can reused, rather than creating a new object every time. In FragNavTransactionOptions:

public static final FragNavTransactionOptions NO_OPTIONS = new FragNavTransactionOptions(new Builder());

[liquidninja24]

I'm sorry to keep bugging you about this, but I'm trying to add a feature to my app and this is an annoying bug. I know you're busy, but I would really appreciate it if you could push out a tag in the next day or two.

[ncapdevi]

Ah, should be out now in compile 'com.ncapdevi:frag-nav:2.2.2' Apologies, pushed it the other night, but should've given you a heads up.
Also, I thought about a static variable for it, but it's only happening on restoreState, which in the vast majority of sessions never happens, so it's totally find to lazily create it when it's needed. Plus would never happen in a loop. If we end up needing a NO_OPTIONS anywhere else in the code, then I'll make it a constant, but for the time being, this is technically more efficient.

[liquidninja24]

Thanks a lot man!

[ncapdevi]

👍 Cheers. Thanks, as usual, for your insight and help.