Skip to content
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

Synthetic up scopes for keys #287

Open
Zhuinden opened this issue Sep 11, 2024 · 1 comment
Open

Synthetic up scopes for keys #287

Zhuinden opened this issue Sep 11, 2024 · 1 comment

Comments

@Zhuinden
Copy link
Owner

Currently, UP is somewhat of an issue with ScopeKey.

It would work with ScopeKey.Child.

But the problem is that the idea behind ScopeKey is that the key defines the scope that must be created, and in the case of properly implemented deeplinking (which, not even Jetpack Navigation can do), you do not have those in the history, but this would break your code unless you change from ScopeKey to ScopeKey.Child on those specific screens.

The idea is that you'd be able to say implements SyntheticUpTarget (name subject to change) and return a List<ScopeKey> to determine scopes that should exist as implicit scopes even if they are not in the history.

The downside is that it is quite literally just like ScopeKey.Child so it could also theoretically be a List<String>, but then you need to consider parameters (you'd need to still retain the previous key's scopeKey.getScopeTag() as a field and return that in your list). Maybe that's not too bad though.

@Zhuinden
Copy link
Owner Author

Zhuinden commented Oct 3, 2024

I was thinking about this; while it would work reliably and shouldn't be too hard to implement per say, but from end-user side you'd start getting the latter key from getKey<T> and not the key of that given screen. So you'd need special considerations, unless I somehow make you actually return the old key from the new key for that given scope. Neither is particularly convenient, but each is necessary.

Reminds me of Flow's getParent() for HasParent interface, but that only returns one. Maybe I could do a search for getScopeName() and have a list of keys as synthetic parent, that way I can match the key from the latter key and not end up with Screen 3 having to know the exact arguments of Screen 1 with a bunch of whacky interfaces in it..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant