Unrestrict subscribe?

[airbnb]

Unrestrict subscribe?

[aneophyte]

This is what I did:

abstract class BaseActivity : BaseMvRxActivity(), MvRxView {
    override val mvrxViewModelStore by lazy { MvRxViewModelStore(viewModelStore) }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        mvrxViewModelStore.restoreViewModels(this, savedInstanceState)
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        mvrxViewModelStore.saveViewModels(outState)
    }

    override fun onStart() {
        super.onStart()
        // This ensures that invalidate() is called for static screens that don't
        // subscribe to a ViewModel.
        postInvalidate()
    }
}

inline fun <T, reified VM : BaseMvRxViewModel<S>, reified S : MvRxState> T.activityViewModel(
        viewModelClass: KClass<VM> = VM::class,
        noinline keyFactory: () -> String = { viewModelClass.java.name }
) where T : AppCompatActivity, T : MvRxView = lifecycleAwareLazy(this) {
    val stateFactory: () -> S = { _activityViewModelInitialStateProvider(keyFactory) }
    if (this !is MvRxViewModelStoreOwner) throw IllegalArgumentException("Your Activity must be a MvRxViewModelStoreOwner!")
    MvRxViewModelProvider.get(viewModelClass.java, this, keyFactory(), stateFactory)
            .apply { subscribe(this@activityViewModel, subscriber = { postInvalidate() }) } //red line here
}

@Suppress("FunctionName")
inline fun <reified S : MvRxState, T : AppCompatActivity> T._activityViewModelInitialStateProvider(keyFactory: () -> String): S {
    val args: Any? = intent.getBundleExtra(MvRx.KEY_ARG)
    if (this is MvRxViewModelStoreOwner) {
        this.mvrxViewModelStore._saveActivityViewModelArgs(keyFactory(), args)
    } else {
        throw IllegalArgumentException("Your Activity must be a MvRxViewModelStoreOwner!")
    }
    return _initialStateProvider(S::class.java, args)
}

[BenSchwab]

@aneophyte You can use the subscribe methods exposed in MvRxView, so just delete this@activityViewModel.

However -- we haven't been consistent on this -- but all the methods named starting with _ are also not meant to be publicly used.

I feel like a solution here is to change MvRxExtensions.viewModel to apply a subscribe call if the receiver is a MvRxView.

However, I would be hesitant to make this change without first understanding a bit more about what your refactoring to MvRx looks like. One of MvRx opinion's is that activities are just shells for fragments. It makes sense that this is different than may exist in applications which want to switch to MvRx. However I would imagine you will already need to refactor your activity to confirm to the invalidate model, and am curious how much extra work it would be to pull it into a fragment?

[aneophyte]

I haven't used any subscribe method outside the extension function. The subscribe method in question came because it was part of the activityViewModel method. This is the method, I believe, that is used to create view model under the activity scope. It leads me to another question that if that subscribe method were to be removed, would persistence and lifecycle related stuff work?

MvRxExtensions.viewModel is definitely the better option, though the restriction is still there. I tried to make an extension function around it.

inline fun <T, reified VM : BaseMvRxViewModel<S>, reified S : MvRxState> T.activityViewModel(
        viewModelClass: KClass<VM> = VM::class,
        noinline keyFactory: () -> String = { viewModelClass.java.name }
) where T : BaseActivity, T : MvRxView = lifecycleAwareLazy(this) {
    viewModel(viewModelClass, keyFactory).run{this.value}.apply {
        subscribe(this@activityViewModel, subscriber = { postInvalidate() })
    }
}

This is how I'm using activityViewModel currently.

class SimpleActivity : BaseActivity() {
    val viewModel by activityViewModel(ActivitySplashViewModel::class)

    override fun invalidate() {
        withState(viewModel) {
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_simple)
    }
}

The problem with refactoring to Fragments, here in my case, is a lot has been written already and would require quite a lot of changing. And moving from Activity based flow to Fragment one, I suppose would require using the Navigation library from the AndroidX family. I'm a bit hesitant with that because it's currently in experimental state, also I did not have pleasant experience in using Fragments as a prominent thing in previous projects.

Having said all this, maybe applying your solution would allow Activitys to be used as Views, would make the library more open for developers choosing to use Activity, but to be honest, I don't really want my requirements to affect the conventions that MvRx has opted for.

Thanks for the input! I apologize for responding late.

[gpeal]

@aneophyte I'm going to close this for now because we don't plan on adding support for Activities out of the box but you can also make your base activity implement MvRxView.

Fragments are also not tied in any way to jetpack navigation.