-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
please annotate method parameters with Nullable and NonNull #42
Comments
in there si a null check on previousKey... either it is unnecessary or the annotation is wrong |
DefaultStateChanger.NO_OP_VIEW_CHANGE_HANDLER is private... but it is a static immutable variable of a public final class ! |
I'll get home and get to work on that! |
Can you please verify that 1.6.3 fixes all issues in Kotlin? Btw: if previousKey is null, then view change handler is not called. So the annotation is ok |
The annotations (and the explanation) fix my (minor) issues, thanks. As I would like to create views through code (anko, anvil, or something else) or xml, I'm not going to use StateKey. I saw in the samples that Key extends StateKey for services, so I'm not going to use that either. I have a few questions :
Should there instead be : view creation, view state restoration, tying the view to boservables/subscriptions ?
My needs aren't extreme : I could make do with app/activity scope
|
I've been thinking a lot about introducing out of the box scoping (and brainstormed about it here #25 ) but I came to the realization that it's only the Backstack that could provide scope per each key, but then managing whether it is the root of a service tree or a child of one is difficult, and also it'd be hard to create a sufficiently customizable way for users. Managing composite keys ( So I had to come to the conclusion that "scoping is not the responsibility of the library. For scoping, do it in The I was experimenting with nesting in this repository, maybe it can give some ideas?
If you replace the
If you start observing in Back in Flowless I had a callback for "onViewRestored()" and "onViewDestroyed()", sometimes I think about whether I should have brought it over here as well.
Subscoped Dagger2 components that are stored in either MortarScope or ServiceTree.Node. If you check the Both ServiceTree and Mortar are capable of building the scopes you need; I just don't trust the BundleServiceRunner so the example managed to end up reimplementing it using
No, nested stack example would have been storing backstack instances in subscopes. But I messed up somewhere, so it has state restoration bug atm. :| The |
But if that seemed like rambling I can explain it better, I guess. I've been meaning to solve the scoping problem, but honestly it's kinda hard. So in real life what we did is that we used I prefer ServiceTree to Mortar because you can traverse your scope hierarchy, while Mortar doesn't let you do that. |
I'm indeed using a GetViewChangeHandlerStrategy and LayoutInflationStrategy. Thanks for the explanation about onAttachedToWindow. I'll probably try ServiceTree. I like library that are pure java and avoid android types. Scoping might be a difficult problem (not thought enolugh about it to give valuable advice). Btw, Is there a (reliable) way with simple-stack to get "onEnterActivities" callback when creating an activity a bit like with mortar ? (not that I used it on my dagger/flow/mortar applications : I was recreating my observables when entering/exiting views regardless of orientation change...which was one of the selling point of mortar) |
onExit and onEnter are provided in ServiceTree via Config changes don't affect ServiceTree, as long as it is kept alive across config change. But that is also why you need to explicitly create and destroy nodes (similarly to how you'd call Activity callbacks are a pain, Mortar used |
The issue is closed because annotations are added, but feel free to ask any more questions and stuff :) |
@Lakedaemon Just asking to see if everything's working? I remember your name from the Been there, wasn't fun. 😄 |
I haven't ported my complex app to simple-stack yet. Everything works so far. So I'm quite happy. Btw, Thanks for the library and the support :) |
Hello, I'm giving a try at Simple-stack (a bit pissed of by the slow pace of development of flow and also
hoping that it has better state management...)
Could you please annotate paramethers in methods, like in LayoutInflationStrategy ?
When using Simple-stack from kotlin, lots of things look nullable when they shouldn't be.
The text was updated successfully, but these errors were encountered: