6 Commits (f953c5ec94181f2af73688ce4d7e470fba5e3b62)

Author	SHA1	Message	Date
Mugurell	621c388c12	For #17917 - Finish migrating all synthetics usages	3 years ago
codrut.topliceanu	c52b6615e5	For #17917: Use View binding in Share views	3 years ago
Tiger Oakes	333ff8c941	Fixes #4528 - Prevent share menu from jumping ... Plus a bunch of docs and refactoring	5 years ago
Emily Kager	9a4610f068	For #2897 - Add Action States To Share Sheet	5 years ago
Mugurell	16eba61b25	For #4007 - ShareFragment will set the contained Views' state ... 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.	5 years ago
Mugurell	095870145f	For #4007 - Refactor AppShareView in standalone Share Views ... 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	5 years ago