Homework_BasicArchitecture#38
Homework_BasicArchitecture#38AnGuru-60 wants to merge 3 commits intoAndroid-Developer-Basic:masterfrom
Conversation
| override fun afterTextChanged(s: Editable?) { } | ||
| }) | ||
|
|
||
| editTextCity.addTextChangedListener(object : TextWatcher{ |
There was a problem hiding this comment.
@AnGuru-60, привет! Есть удобная функция для этого в KTX. Чтобы не городить эти оверрайды
| class AddressViewModel @Inject constructor( | ||
| private val cache: WizardCache | ||
| ): ViewModel() { | ||
| private var _canGoNext = MutableLiveData<Boolean>(false) |
There was a problem hiding this comment.
@AnGuru-60 , тут все хорошо и правильно. Как вариант, я бы предложил закинуть реактивные свойства (лайвдату или флоу) прямо в визардкеш и проксировать их оттуда через модель. Таким образом, у нас будет один источник истины в данных. Во вьюхе подписываться на них из модели.
Сейчас у нас получается два источника:
- инпуты. Они управляются пользователем + saved state выполняет ОС
- кеш. Мы кладем туда состояние при помощи логики
Где "истинное" значение данных?
Это может быть потенциальной проблемой, так как у нас несколько мест хранения и состояние не централизовано. Такие штуки описываются концепциями "single source of truth", UDF, MVI и прочим. И композ тоже делить состояние и отображение явно - как раз с этой целью
| import javax.inject.Inject | ||
| import javax.inject.Singleton | ||
|
|
||
| @Singleton |
There was a problem hiding this comment.
@AnGuru-60, в рамках нашего примера, синглтон тут хорошо. Однако, следует подумать о времени жизни этих данных. Например, нам они больше не нужны, если мы выполнили регистрацию и закрыли активити. В таком случае, в рамках поэкранной архитектуры, мы могли бы привязать наш визард к какой-то RegistrationActivity. Если мы пометим кеш ActivityRetainedScoped, то как только мы закончим с регистрацией, кеш уйдет из памяти. При этом, для всех фрагментов внутри активити регистрации он будет в ЕДИНСТВЕННОМ экземпляре (локальный синглтон)
No description provided.