Milos Marinkovic "Modular Android UI"
1 like380 views
The document provides an overview of modular UI design principles for Android, focusing on responsive layouts, varying navigation for different devices, and architectural patterns like MVC, MVVM, and MVP. It emphasizes the importance of decoupling components, managing screen lifecycles, and utilizing appropriate UI elements like RecyclerView for better performance and organization. Additionally, it discusses challenges and strategies for creating a maintainable and effective UI, suggesting the use of a coordinator for managing page navigation and state.
Milos Marinkovic "Modular Android UI"
- 2. A visual introduction What does it mean to have a Modular UI?
- 4. Adjust padding and View positions on larger screens
- 5. Different item lists on different devices
- 6. List presented as Grid on larger screens
- 8. Different list arrangement on larger screens
- 9. Displaying the same content in different containers
- 10. Compress layout vertically in split-screen scenario
- 11. Different navigation on different devices
- 13. Android SDK helps.. with some stuff ● Screen sizes: small, normal, large, xlarge ● Screen aspect ratio: long, notlong ● Device orientation: land, port ● Screen densities: ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi ● Density pixels (dp) instead of pixels (px) ● Precise screen sizes: w__dp, h__dp, sw__dp
- 14. Phones
- 15. Small Tablets (7”, 8”)
- 16. Large Tablets
- 17. Android layouts ● Less layouts; more styles ● Print and slice UI on paper ● Sub-layouts belong to static containers ● Use phone UI in tablet containers
- 18. MVC Model:View:Controller ● Model - SQLite, Shared prefs ● View - main_activity.xml, ListFragment.java ● Controller - MyController.java, MainActivity.java (don’t)
- 19. MVVM Model:View:ViewModel ● Model - SQLite, Shared prefs ● View - main_activity.xml, ViewGroup or View, AccountListFragment.java ● ViewModel - AccountListFragmentUiModel.java
- 20. MVP Model:View:Presenter ● Model - SQLite, Shared prefs ● View - main_activity.xml, ViewGroup or View ● Presenter - MainActivity.java ListFragment.java
- 21. MVP - Variations Passive View ● View not aware of the Model ● Presenter does the hard work Supervising Controller ● View interacts directly with the Model ● Presenter handles extreme cases
- 23. How we divided Android components
- 24. Lifecycle ● Service, Activity, Fragment, Dialog, Application - all different ● Create a custom UI entity? I do it anyway ● Unreliability, bugs, appcompat, gotchas ● API levels… ● Fragment caching mechanism… Solution: Move away from Android APIs?
- 26. Android Lists with RecyclerView ● Decouple! ● Android: Recycler View, Adapter, Layout Manager, Item Animator, Item Decorator, Recycled Pool, Cache, Item Decoration Advice: Split “adapter” component (1) data provider and (2) recycler adapter
- 28. Asynchronous work ● UI events must go to a UI thread ● Long operations go on a background thread ● Thread or AsyncTask or RxJava ● Events? Otto or GreenRobot or others ● A swarm of events Advice: Keep it minimal for your needs
- 29. Self-contained UI parts (Pages) ● Keep pages focused on the UI ● Presenters prepare data for pages ● Pages handle dialogs internally ● Complex dialogs? Contain pages inside them ● Persistent presenters or Presenter pool? Advice: Instantiate in one place
- 30. Android Activity ● Context is everywhere ● Difficult to decouple ● Components: LoaderManager, Cursor, FragmentManager, Fragment backstack, Fragment caching, Content Providers, Intents, Menus, etc. Advice: It’s worth decoupling, try to do it
- 31. Intents ● Handle all intents in one place ● Allow the IntentHandler to navigate ● Use an ActivityResolver ● Allow easy Activity switching Advice: React in onResume() method if possible
- 33. Rules for a ‘happy’ UI ● Enumerate pages somehow (enum optimized?) ● Pages need a common navigation API ● Framework creates (and caches) pages ● Follow the Activity lifecycle Example of a ‘happy’ UI code: navigate().with(myBundle).to(Pages.LOGIN);
- 34. Show and hide pages (Page Manager) ● Static containers or dynamic containers ● Watch out: component lifecycles ● Decoupled mechanism for show/hide ● The dark pit of FragmentManager Advice: Small app - use FragmentManager Big app - build your own PageManager
- 35. Layout and navigation (The Coordinator) ● Decoupled navigation & layout component ● Uses the PageManager to show/hide ● Handles back and “up” ● Holds the IntentHandler component Advice: Make Coordinator also a page, a ‘super-page’ that holds all other pages
- 36. Visible UI on Phones Actual layers on Phones The Coordinator Content Page Navigation drawer page
- 37. The Coordinator Branding bar List page Details page FAB List Page Toolbar & menu List - Item photo - Item name Details Page Toolbar & menu Large title Content Actual layers on Tablets
- 38. Page Modularity External configuration causes trouble ● A lot of if-else branches in pages ● Custom Views rule the app (learning curve) Solution: Have a distinct page for each UI Advice: Create a PageResolver component
- 39. Drawbacks ● A lot of decoupling and cosmetic work ● A lot of method references ● Difficult to switch to ● Makes sense only for complex UIs ● Team education ● Limited support (open-source?)
- 40. To recap... ● Self-maintained UI components (pages) ● Data is always prepared (presenters) ● Intent handling happens in one place ● Page Resolver helps with modular UIs ● Separate navigation mechanism ● Wrap it all up in a Coordinator ● Have a Coordinator for each screen variant
- 41. Finally done. Modular Android UI GitHub / Twitter / LinkedIn @ milosmns Blog www.angrybyte.me Questions?