Last active
May 15, 2020 17:40
-
-
Save ftabashir/a6fd76af7180e4702d5e2987e65a1070 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- when to use removeObservers? | |
- reuse LD in repo or create new instance per repo requet? i prefer to reuse | |
- use singleton repos? | |
- use single event? or LiveData.setValue(null)? | |
- best practice: use Event class (see https://link.medium.com/qjuB2VGnoV) | |
- use live data or single event in repo? | |
- if we don't reuse LD in repo, then we could use LD (single event is useless) | |
- observeForever is not implemented in single live event | |
- mediators internally use observeForever | |
- Use a repo livedata in two view models: | |
- it should be single but two VMs can't observe single LD | |
- a repo request should return: | |
- corresponding live data? | |
- void? | |
- use a getter to get LD | |
- who is responsible for navigation logic? | |
- activity/fragment? | |
- view model? | |
- use command design pattern | |
- a live data to emit commands | |
- activty/fragment observes command live data and does the navigation | |
problems: | |
use-case: | |
- single events in repo | |
- two VMs listening on same single event | |
- reusing LD | |
solution1: | |
- use removeObservers before triggering the repo request | |
then observe repo LD, finally trigger repo request | |
solution2: | |
- don't reuse repo LDs, create new LD per repo request | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment