Migrate Share Sheet to LibState #4007
Comments
Differing this ticket until we have consensus in #4275. |
Labeling this as p5 until we have a decision :) |
We're sticking with this custom sheet! |
Engineering notes: the share sheet actually keeps no state at all, so this would really be a refactor to remove the old architecture stuff and follow the view/interactor patterns similar to other refactors. Also consider taking out the old send tab code and make use of the SendTabUseCases which are much easier to deal with. |
@Mugurell are you actively working on this? If you aren't planning to work on it next week, do you mind if I steal this then? :) |
Got sidetracked a little but finishing it up right now with some tests. |
Looked into using SendTabUseCases but found a few issues in doing so:
|
As per #4341. Also reformatted layouts to have a more consistent style. Also refactored `AppShareRecyclerView` and `AccountDevicesShareRecyclerView` by defining their LayoutManager in XML to reduce code complexity.
In an effort to respect the initial MVI architecture I've broken the complex `AppShareView` in 3 separate Views - `ShareCloseView` - `ShareToAccountDevicesView` - `ShareToAppsView` They are standalone Views (extending LayoutContainer) which know nothing about each other or their parent and so offer their container the possibility to order or display them in any form later. According to the lib-state contract they are only responsible to - inflate themselves in their injected containerView - render a certain state (to be added in later commits) - delegate all user interaction to an associated Interactor
ShareFragment which acts as a container would contain all business logic needed for populating it's Views. Data initialization should be done only once since the app state has no reason to change after the ShareFragment is created and is done as soon as possible, in onAttach(). Because of the expected short lifespan of this fragment, given the fact that the state has no reason to change and we handle orientation changes ourselves to keep things simple I didn't use a ViewModel to persist the state.
… logic `ShareController` defines a contract with all possible `ShareFragment`'s behavior changes and comes with a default implementation - `DefaultShareController`. It is to be delegated by all `ShareFragment`s contained Views' Interactors following any user interactions.
For QA: Refactor of the share sheet implementation. Please smoke test sharing to different apps and send tab 👍 |
Feel free to map the
At one point the sessionId may have been used, but I no longer see references to it so let's just nuke that from the data class. |
Hi, verified as fixed on Fenix 2.0.0-rc.1 Tested the following: Tested the following:Quick Action bar - Share button |
We don't need most of the stateful stuff in the current ShareFragment so we can start on removing this.
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: