Stop accessing non-public fields in Fragment about mosby HOT 25 CLOSED

AndroidX is now stable 1.0.0. Even more, Google wrote that the Support 28.0.0 is the last version that supports android.support package. It is time to move on.

from mosby.

As a temporary workaround until then for those who want to continue using AndroidX, you can exclude the utils-fragment module dependency in your build.gradle:

compile 'com.hannesdorfmann.mosby3:mvi:3.1.0' {
    exclude group: 'com.hannesdorfmann.mosby3', module: 'utils-fragment'
}

and then define your own androidx.core.app.BackstackAccessor class:

package androidx.core.app;

import androidx.fragment.app.Fragment;

public class BackstackAccessor {
    public static boolean isFragmentOnBackStack(Fragment fragment) {
        return false;
    }
}

from mosby.

I discussed with Adam Powell some time ago, the method isInBackStack() should actually become public.

stops working after migrating to AndroidX due to the change of package names.

that is true unfortunately but there is no easy way around this. The plan is the following: Once androidx is a stable release I will pump version of Mosby to Mosby 4.0 and Mosby 4 will be compatible with androidx only. Open to discuss this and happy for any feedback.

from mosby.

Hello @sockeqwe !
BackstackAccessor used for checking that we should persist presenter on screen rotation because isRemoving == true for fragments inside backstack on screen rotation. Right?

But we can check it other way: android calls onSaveInstanceState for this fragments before screen rotation.

abstract class BaseFragment : AppCompatFragment() {

    private var instanceStateSaved: Boolean = false

    //This is android, baby!
    private fun isRealRemoving(): Boolean =
        (isRemoving && !instanceStateSaved) //because isRemoving == true for fragment in backstack on screen rotation
            || ((parentFragment as? BaseFragment)?.isRealRemoving() ?: false)

    //It will be valid only for 'onDestroy()' method
    private fun needDestroyPresenter(): Boolean =
        when {
            activity?.isChangingConfigurations == true -> false
            activity?.isFinishing == true -> true
            else -> isRealRemoving()
        }

    override fun onResume() {
        super.onResume()
        instanceStateSaved = false
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        instanceStateSaved = true
    }

    override fun onDestroy() {
        super.onDestroy()
        if (needDestroyPresenter()) {
            //destroy presenter
        }
    }
}

I think @guyca code is dirty hack 😉

from mosby.

Thabks a lot. I m going to publish a new release at the end of this week containing this. This makes it useable with jetifier. However I plan to make a 4.0 release that is fully backed on androidx soon (3.x sticks with old support library)

from mosby.

@sockeqwe When do you plan to release 3.1.1?

from mosby.

from mosby.

I have to double check it but Conductor should not be a problem. It doesn't use BackstackAccessor at all.

from mosby.

I have some problems with gradle uploading files of 3.1.1 release to different locations instead of just one single location. I asked that question on stackoverflow, if someone knows how to fix it, here is the link to stackoverflow:
https://stackoverflow.com/questions/53200255/gradle-uploadarchives-runs-in-parallel-causing-multiple-staging-repositories-on

Meanwhile I have at least published a new 3.1.1-SNAPSHOT containing this stuf or you can use jitpack

allprojects {
		repositories {
			...
			maven { url 'https://jitpack.io' }
		}
}

dependencies {
	        implementation 'com.github.sockeqwe:mosby:345efbb0c0'
}

from mosby.

With androidx.fragment 1.2.0 the @guyca dump() hack does not work anymore. There's a bug in FragmentManager trying to dump a detached fragment. Reported it as https://issuetracker.google.com/issues/148189412

As a workaround, changed the hack to another, reflection-based one:

private static boolean isInBackStackAndroidX120(final Fragment fragment) {
        try {
            Field backStackNestingField = Fragment.class.getDeclaredField("mBackStackNesting");
            backStackNestingField.setAccessible(true);
            int backStackNesting = backStackNestingField.getInt(fragment);
            return backStackNesting > 0;
        } catch (NoSuchFieldException | IllegalAccessException e) {
            throw new RuntimeException(e);
        }
    }
}

from mosby.

@sockeqwe
Would you consider using this workaround in mosby:

public static boolean isInBackStack(final Fragment fragment) {
    try {
        return fragment.isInBackStack();
    } catch (IllegalAccessError e) {
        return isInBackStackAndroidX(fragment);
    }
}

/**
* Hacky workaround because Fragment#isInBackStack is inaccessible with AndroidX
*/
private static boolean isInBackStackAndroidX(final Fragment fragment) {
    final StringWriter writer = new StringWriter();
    fragment.dump("", null, new PrintWriter(writer), null);
    final String dump = writer.toString();
    return !dump.contains("mBackStackNesting=0");
}

Another possible solution is to keep current implementation and introduce a BackStackAccessorProvider which will let users use a different logic for determining if a fragment is in the back stack or not.

from mosby.

I've read and responded to Your SO issue. TLDR; make sure You have no org.gradle.parallel=true in your project root gradle.properties file. Based on Your local Gradle configuration, using command line parameter to disable above mentioned paralellism might not work properly. It is worth to give a try.

from mosby.

from mosby.

@sockeqwe Hannes, does this affect users of Mosby with Conductor? I guess it'll not since Conductor handles its own backstack and lifecycle which Mosby makes use of it, but I'll soon enough have to migrate to AndroidX for a mammoth of a project and don't want this to be an issue 😕

from mosby.

from mosby.

Thanks @sockeqwe, submitted a pr.

Edit 1: submitted a new pr

Edit 2: I published my fork which is compatible with AndroidX on jitpack. If anyone is interested you can use it until the PR is merged: implementation 'com.github.guyca:mosby:3.1.6'

from mosby.

@sockeqwe still no new release version ((

from mosby.

Thanks for answering, I have that set, doesn't help unfortunately. Will try it on a different machine over the weekend.

from mosby.

Im still waiting

from mosby.

Unfortunately, the build fails with this exception, because of duplicate BackstackAccessor.
Warning: Exception while processing task java.io.IOException:
Can't write [/home/me/projects/myappAndroid/myapp/build/intermediates/transforms/proguard/prodmyapp/release/0.jar]
(Can't read [/home/me/projects/myappAndroid/myapp/build/intermediates/transforms/RealmTransformer/prodmyapp/release/0(;;;;;;;**.class)]
(Can't read [androidx]
(Can't read [core]
(Can't read [app]
(Can't read [BackstackAccessor.class]
(Duplicate jar entry [androidx/core/app/c.class]))))))

from mosby.

Looking forward to this issue solved. I'm getting the same issue.
java.lang.IllegalAccessError: Method 'boolean androidx.fragment.app.Fragment.isInBackStack()' is inaccessible to class 'androidx.core.app.BackstackAccessor'

from mosby.

Yes error similar to @Jeff11 persists in 3.1.1-SNAPSHOT version using gradle dependency 'Program type already present: androidx.core.app.BackstackAccessor'

from mosby.

I just released 3.1.1 (not snapshot)

@LukasStancikas is your code available somewhere to reproduce this issue? I guess jetifier is doing to much "smart" things ending up having BackstackAccessor somehow twice ... Do you use Mosby in app and in a library that uses Mosby as well?

from mosby.

In our AndroidX-enabled app the 3.1.1 does not work out of the box, BackstackAccessor crashes with NoSuchMethodError and not with IllegalAccessError as handled in the code. The configuration I was testing has proguard optimizations enabled so it might be part of the issue here.

My workaround:

• keep a BackstackAccessor fork and utils-fragment exclusions as in #318 (comment) above
• base the fork on utils-fragment but just call the isInBackStackAndroidX() hack directly

I believe this could be fixed in the library by catching NoSuchMethodError as well.

from mosby.

Thank for compile 'com.hannesdorfmann.mosby3:mvp:3.1.1' // Plain MVP
Issue was resolved for me.

from mosby.