Выглядит так, что большинство разработчиков будет просто этим пренебрегать. Посмотрим: может быть, скоро кто-то придумает, как оптимизировать поддержку сохранения состояния, так как сама идея крайне правильная и нужная.
Сохранять состояние не всегда хорошо. Например, приложение банка тинькофф меня прям выбешивает своим восстановлением back stack. Я захожу в приложение, чтобы с главной стартануть, а он мне открывает экран результата успешного платежа и мне приходится жать кучу раз на кнопку назад, только чтобы добраться до главной. Каждый раз злюсь.
Вот сколько статей не прочитал, нигде нет примера с implementation by delegation для CoroutineScope. Мне кажется, лучше использовать его, если нет какой-то необходимости хранить экземпляр Job отдельно.
class MyViewMode : BaseViewMode(), CoroutineScope by MainScope() {
fun onDestroy() {
cancel() // метод CoroutineScope
// or
coroutineContext[Job]?.cancelChildren()
}
fun showSomeData() = launch {
draw(data)
}
}
Спасибо. Я правильно понимаю, для того чтобы появилась возможность обновлять данные карты в кошельке, эту карту нужно добавить в кошелек из приложения на айфоне, а генерация на бекенде и отправка на почту не позволяют в дальнейшем обновлять карту?
А вы пробовали запустить TextInputLayout с новым дизайном, потому что когда я пробовал RC, там ну вот совсем не по гайдам было. Например, hint, когда нет текста и фокуса, был прижат к низу, хотя по гайдам по центру.
Так же проблемы при фокусе или если поле содержит текст, подсказка, которая уезжает наверх имела слишком большой отступ сверху. В итоге пришлось наследоваться и немного поправить отступы, чтобы получить то, что надо.
На самом деле эти аккаунты хранятся в системной базе, доступ к которой есть только у системных сервисов Android. Единственным нормальным способом получить оттуда данные, не являясь Android или приложением, которое за них отвечает, является получение root на телефоне. Но если у вас root на телефоне, то вам мало чем можно помешать.
Все не совсем так. К сожалению чужое приложение может получить доступ к аккаунту на андроиде c API < 24 даже если подпись не совпадает.
вот кстати поэтому я именую id вьюх в lowCamelCase стиле, в IDE и так видно, что это вьюха среди других переменных. Именование с подчеркиванием напоминает устаревшие префиксы m и s, которые стали ненужны с появлением умных IDE с подсветкой.
1) Мне как раз и не нужны живые объекты, они несут неоднозначность в себе и кучу потенциальных багов.
Что на счет выборок — то тут не могу сказать, на мобилке не должны храниться такие объемы данных, чтобы разница производительности при выборке небольшой части и всей таблицы была огромной.
2) Не важно, бд или кэш. Да, там шедулеры, но делать еще одну ненужную вещь, ради того, что это будет работать на 100мс быстрей как-то сомнительно в данном случае.
Сохранять состояние не всегда хорошо. Например, приложение банка тинькофф меня прям выбешивает своим восстановлением back stack. Я захожу в приложение, чтобы с главной стартануть, а он мне открывает экран результата успешного платежа и мне приходится жать кучу раз на кнопку назад, только чтобы добраться до главной. Каждый раз злюсь.
Как же много времени прошло уже…
Так же проблемы при фокусе или если поле содержит текст, подсказка, которая уезжает наверх имела слишком большой отступ сверху. В итоге пришлось наследоваться и немного поправить отступы, чтобы получить то, что надо.
Что касается Java/Kotlin, то тут уже сказали, это огромный мир энтерпрайза
Все не совсем так. К сожалению чужое приложение может получить доступ к аккаунту на андроиде c API < 24 даже если подпись не совпадает.
Что на счет выборок — то тут не могу сказать, на мобилке не должны храниться такие объемы данных, чтобы разница производительности при выборке небольшой части и всей таблицы была огромной.
2) Не важно, бд или кэш. Да, там шедулеры, но делать еще одну ненужную вещь, ради того, что это будет работать на 100мс быстрей как-то сомнительно в данном случае.