Design Guidelines

In general we always:

• Use activities with fragments
• Use Constraint Layout as the root layout for views
• Subscribe to observables before calling functions that force them to output a result
• Write lifecycle callbacks in LifecycleObserver classes like our presenters
• Store cross activity data in a service, persistent storage, or injectable model
• Use constructor injection whenever possible. We only use field injection when injecting classes we don't own like services, fragments and activities

Navigation

• We use one activity with multiple fragments
• Descending into another activity is simulated by showing a new fragment with an up navigation arrow in the toolbar and hiding the navigation bar. This is accomplished in DefaultActivity.showFragment and DefaultFragment.onHiddenChanged

Activities Design

• All activities will contain a fragment if any user interface is to be displayed.
  
• A fragment will contain a presenter, and a view if any user interface is to be displayed.
  
• A presenter may or may not have a view. If it does have a view, it is set by the owning fragment in onCreateView. A presenter may clean up the view in onStop, onDestroy, or when signaled to by a Fragment from onDestroyView
  
• All presenters and views will be injectable. This requires them to only have injectable parameters in their primary constructors.
  
• The presenter with a view will subscribe to any events it needs from the view as soon as possible. It will then update the view state by calling any appropriate functions. In a terminating lifecycle function (onPause, onStop or onDestroy) the presenter will unsubscribe from the view. The terminating function must correspond to the initiating function (onStart -> onStop, onCreate -> onDestroy)
  
• The Presenter only responds to data events from the view or the model. Click actions are observed through the view. Background thread actions and results are observed through the model.
• The model is used for communicating with background services, communication and signalling outside of the Android lifecycle, and starting asynchronous tasks.
• Always prefer to react to activity state changes versus saving the changes. We are attempting to interface with Android in a functional way. Hence, do not save state is resumed or state is paused, and write code later that checks that. Instead, we subscribe to callbacks in onResume and unsubscribe in onPause. Less state to maintain makes code easier to modify in the future.

Views

• When possible avoid using a fixed value for view sizes. Prefer anchors and percentages of the Parent view group