Recipes about simple-stack HOT 16 CLOSED

After evaluating it, I didn't try to migrate my app to a redux-like architechture because

• the app was working just fine with simple-stack (navigator) only (implementing the bookmarking feature actually was really simple and only required code in the onRestore/onSaveState custom view routines). Everything works now, I'm happy
• it would have required rethinking all the RxJava pipeline and this is a lot of work (and along the way you get subtle and hard to debug bugs...)

But, my feeling is that UI development for android really really sucks (and is a monstrous waste of time). And, in my future projects, I'll try to implement apps that from the start do navigation in the core/language/business logic part (with list of pojos) and only uses android to display data (dumb custom view, redux like rendering, transitions, saving/restoring view states (but not app state)).

Avoiding android stuff always feel so great....

from simple-stack.

I guessed that I created the new view in a bad way, without a contextwrapper holding the key...
What is the best way to achieve that ?

from simple-stack.

actually, solution 2 looks like it is working once I create the new view with the context of the oldview (instead of the wrapped AppcompatActivity)
I wonder why simplestack uses 2 KeycontextWrapper (with the same key) though...

I stumbled on another issue : in a view, I would like to access the fields in the key but it throw an axception when I do something like this :
val wordDocId = Navigator.getBackstack(context).top<KeyJapaneseWord>().docId

I guess because the key isn't at the top of the backstack yet.
To achive the same thing in flow, I had to use Path.get().docId

What is the correct way to do that in simplestack ?

from simple-stack.

Nevermind, I already had the solution (it just took my brain some time to realize) :
KeyContextWrapper.getKey<SomeClass>(context)

So far, so good with the migration.
At some point, I'll want to go to a screen and to inject some stuff in it's state bundle.
Is there some canonic way to do that ?
Also, what is the canonic way to test if a screen starts from scratch or if it had state restored ?

from simple-stack.

Path.get was replaced with KeyContextWrapper.getKey(), but as that is not obvious from an API standpoint that is also accessible from Backstack.getKey(context).

If the view implements Bundleable, then you receive a null state bundle in fromBundle() if that helps.

Normally if you want to provide parameters to a view, it is part of the key.

Sorry about the delay, droidcon totally took all my attention during the day.

Simple Stack shouldn't need multiple key context wrappers to work afaik.

from simple-stack.

I think the reason why you got the crash initially was because

https://github.com/Zhuinden/simple-stack/blob/master/simple-stack/src/main/java/com/zhuinden/simplestack/navigator/DefaultStateChanger.java#L98

To create a context that wraps the base context with a key parameter, you had to do LayoutInflater.from(stateChange.createContext(activity, key));

from simple-stack.

Normally the Navigator should do that, but you might have been doing something tricky with your addView method which I didn't really account for.

Possibly just didn't do stateChange.createContext(). It's not really obvious that you have to do that, but there is no better place to put it either. It just creates a new KeyContextWrapper, just like what you ended up doing.

The DefaultStateChanger is a bit tricky in its design because it has a re-configurable default implementation for every single line, but you can replace it with your custom StateChanger implementation. As long as for your view-based app you keep the contract which is:

• persist state of current
• remove current
• inflate new with a context obtained from stateChange.createContext(base, key) using LayoutInflater.from(context)
• restore state of new
• add new
• completion callback

Then it should work just fine.

A custom implementation can ignore the check for being at the same key.

from simple-stack.

I have opened #61 to track that I should tell people to use stateChange.createContext() when they create a view they want to persist without their key.

@Lakedaemon any luck?

from simple-stack.

@Zhuiden I stripped my app of mortar and flow and it is now partially working with simplestack
I managed to fix the few issues that happenend because of my code (and not because of simplestack)
I have yet to experiment with going to a view and changing it's state (with the data included in a key, through a previous bookmark)

but so far, I'm happy : the code is much simpler than what I had before. And I also hope to manage view state correctly this time (I wasn't doing it correctly with mortar view presenters)

from simple-stack.

Next, I'll look how to make the app fully working the simplestack way

from simple-stack.

I also hope to manage view state correctly this time (I wasn't doing it correctly with mortar view presenters)

Gah I still have nightmares about that, rotating the screen and navigating away then navigating back used to break things in awkward ways >.>

but so far, I'm happy : the code is much simpler than what I had before. Next, I'll look how to make the app fully working the simplestack way

Well, if you run into any issues, I'm here to help 😄 Hopefully with smaller delay than while I was in berlin

from simple-stack.

@Lakedaemon so, how's the migration going?

from simple-stack.

I have not reimplemented the bookmark feature yet. Appart from that, it looks good.
I'm happy to be rid of mortar, flow and aloso gson.

I'll probably try to implement something close to redux, having an app state (the many data containers and the rx observables) in the business/pure kotlin/non-android layer and using custom views to only subsribe/unsubscribe observables and save/restore state view.... while having the possibility to time travel with the ui actions

from simple-stack.

It would probably make saving restoring state of views with adapter with scroll to search simpler
It will probably require having something close to a backstack in the app layer

from simple-stack.

@Lakedaemon did it work? I always had some trouble wrapping my head around navigation with MVI. the backstack you think of typically ends up being a merged stream of Observable.

from simple-stack.

I'll try to implement apps that from the start do navigation in the core/language/business logic part (with list of pojos)

That wanted to be the original intention of simple-stack and possibly of flow, in its core it's a list of objects that are parcelled out and brought back 😄

The tricky thing about it is that I generally only use the Backstack to store initial parameters, but maybe there is hidden potential in storing current state in it. Just make sure loading is transient.

from simple-stack.