1. 17 Sep, 2019 1 commit
  2. 11 Sep, 2019 2 commits
  3. 03 Sep, 2019 1 commit
    • Petru Lingurar's avatar
      Fix #5067 - Refactor ShareController to use SendTabUseCases · f7087e46
      Petru Lingurar authored
      Navigation between app fragments uses ShareTab as arguments. The newly used
      SendTabUseCases uses TabData which is not Parcelable.
      For minimal changes we'll keep both data classes and ShareController will know
      how to map between the two.
      Removed the `sessionId` property of ShareTab as it isn't needed anymore.
      f7087e46
  4. 30 Aug, 2019 3 commits
    • Mugurell's avatar
      For #4007 - Add ShareController for handling ShareFragment's business logic · e165868a
      Mugurell authored
      `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.
      e165868a
    • Mugurell's avatar
      For #4007 - ShareFragment will set the contained Views' state · 16eba61b
      Mugurell authored
      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.
      16eba61b
    • Mugurell's avatar
      For #4007 - Refactor AppShareView in standalone Share Views · 09587014
      Mugurell authored
      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
      09587014
  5. 03 Aug, 2019 1 commit
  6. 12 Jul, 2019 2 commits
  7. 10 Jul, 2019 1 commit
  8. 25 Jun, 2019 1 commit
  9. 06 Jun, 2019 1 commit
  10. 29 May, 2019 1 commit
  11. 28 May, 2019 2 commits
  12. 23 May, 2019 3 commits