Android – what is the preferred way to save / restore screen state using flow mortar dagger2?

I'm trying to convert the acticity fragments application to flow mortar dagger2

Invalid Sign

I spent a lot of time looking at the flow and mortar readme files and samples, but I couldn't figure it out (there were few documents and samples, only dealing with simple / static / unique data)

For example, you have a browser like application that moves from page to page. Each page uses the same pageview class and the same pagepresenter class, but has different dynamic content, depending on the URL string entered by the user

Using dagger2 (compilation type annotation) to save / restore state through injection is quite complex / difficult, isn't it? (this requires a complex parent / cache structure)

I googled and stumbled upon: https://github.com/lukaspili/flow-navigation

However, this is mainly an experiment... If possible, I would rather base my production funds on official / reliable / test / support / support solutions

I also looked:

1) https://github.com/square/flow/issues/11 However, this example uses dagger to inject data into 2 screens with different view categories (not a valid answer)

2) https://github.com/square/flow/issues/76 (no answer given)

3)Mortar / Flow save view and presenter in backstack

I also saw this: we now perform this internally by adding a variable field to the screen object:

public void setViewState(SparseArray<Parcelable> viewState) {
this.viewState = viewState;
}

public void restoreHierarchyState(View view) {
view.restoreHierarchyState(viewState);
}

When we switch out of the view, we get its instance state and set it on the screen object (already on the Backstack). We will use this mode for some time before we promote it to the library

But neither flow samples nor mortar samples use this solution (they use dagger2 to inject the list... Is no longer a valid solution)

So what is the best date / recommended method to restore / save the screen state in the mortar stream (dagger2) app?

resolvent:

Invalid Sign

>Flow saves the view state of the previous view and attempts to restore the previously saved state of the new view. Through the view state, I mean Android view state, which is completely independent of flow. It does not save the mortar range associated with the previous screen. The code fragment you copy and paste has been implemented in flow, and as I said above. > using flow path, It defines the logic of how to switch from screen a to screen B, how to set the view conversion animation from a to B, and how to set / destroy the pathcontext wrapper of a and B. It is defined in the pathcontainer class. > pathcontext is a class from flow path, which is used to set the context associated with screen and its view (it is the wrapper of android.content.context and works in the same way as the mortar context wrapper). You usually have a custom pathcontextfactory called by the pathcontainer and set the mortar range associated with the screen and pathcontext. > flow path does not provide any "official" of the pathcontainer Implementation. The only one is the simplepathcontainer in the sample project. If you view the source code of simplepathcontainer, you will see that it destroys the path context associated with the previous screen. By destroying its context, it also destroys its mortar scope and all its internal contents, such as the dagger2 component containing the viewpresenter instance. > if you want to keep the mortar scope of the previous screen, The only way to do this is to write your own pathcontainer implementation, which will not destroy the previous scope in the history. This is flow navigation（ https://github.com/lukaspili/flow-navigation ) As you said, its purpose is to make history disappear during configuration changes and application processes. However, with the correct mortar configuration, the mortar range will not be destroyed during configuration changes. Therefore, you do not need to save / restore viewpresenter instances because these instances will not be destroyed (view only) You still need to do this for process kill

Now my 2cents:

Flow navigation is the first evidence of the concept of not destroying the previous screen mortar range (anticline) in history. Since then, I have written an alternative flow library from scratch, which handles navigation, manages the history of mortar range, and provides view conversion in a separate way to meet my needs: https://github.com/lukaspili/Mortar-architect

This doesn't work for you because you are looking for square support and supported solutions. However, I invite you to check the source code, which may let you know how to write your own pathcontainer to keep the mortar range in the flow history