Принцип из оригинальной статьи предлагает хорошую модель поведения. Как же ваш поможет в реальных ситуациях, не так понятно, пусть даже он "правильней" или точнее. Я голосую за оригинал как более приземлённый.
Почему "вместо"? Подразумевается, что был выбор между Kotlin Channels и RxJava?
Можно я отвечу? Coroutines — экспериментальная функция, RxJava — стабильное проверенное временем решение. Этого достаточно, чтобы не использовать Kotlin Channels.
Запись и передача видео происходит исключительно при наличии Wi-Fi-соединения и никогда не производится через мобильные сети. www.appsee.com/tutorials/recording-settings
Открываем ссылку, одна из опций:
Always Record & Upload — Sessions are always recorded and uploaded both on WiFi and cellular connections
Итог: своим же пруфом подтвердили ложность высказывания
Сохранять компонент в saved state. Сериализация не нужна, если обернуть объект в Binder. Подробнее техника описана тут https://habrahabr.ru/post/274635/. Всё, что есть в статье не нужно, достаточно ValueBinder + BundleCompat.
Правильным решением было бы предотвращать пересоздание Activity-компонента при смене конфигурации (как — отдельный вопрос, есть несколько способов), но с dagger-android, насколько я понял, разработчик не контролирует время жизни компонента. Тогда остается либо вносить изменения в сам dagger-android, либо отказаться от него.
если использовать поля для поддержания состояния View на обоих платформах в одной ViewModel
Во ViewModel не должно быть платформозависимого кода, иначе теряется то самое преимущество MVVM, о котором сказал Don_Eric.
А если приходится это делать, или писать разные ViewModel, это нужно рассматривать как симптом того, что-то вы делаете не так. Возможно, в ViewModel оказывается часть кода, который должен быть в View (просто предположение).
Возник вопрос по первому варианту. Что и с чем сервер будет сравнивать? Если клиент посолит пароль одноразовой солью и захеширует, как сервер поймет, что за хеш ему прислали?
Можете объяснить подробнее или привести пример реализации?
По результатам собственных тестов НЕ рекомендую Google Photos владельцам iOS:
А вот ещё случай из октября, это уже не относится к iOS, делал в веб-морде. Мои действия по порядку:
После этого всего моё доверие к гуглу сильно упало. Для хранения фото его больше не собираюсь использовать, плачу за iCloud.
Спасибо! Обязательно попробую на следующем проекте
Желание-то есть. Дружко.jpg
Планируете поддержку ReactiveCocoa и RxSwift?
Принцип из оригинальной статьи предлагает хорошую модель поведения. Как же ваш поможет в реальных ситуациях, не так понятно, пусть даже он "правильней" или точнее. Я голосую за оригинал как более приземлённый.
Ох уж эти лидеры в онлайн образовании...
И не gotta, а gonna. Gotta это got to.
Почему "вместо"? Подразумевается, что был выбор между Kotlin Channels и RxJava?
Можно я отвечу? Coroutines — экспериментальная функция, RxJava — стабильное проверенное временем решение. Этого достаточно, чтобы не использовать Kotlin Channels.
Запятые невпопад, постоянно спотыкаюсь во время чтения
Открываем ссылку, одна из опций:
Итог: своим же пруфом подтвердили ложность высказывания
Ну нет у вас такой потребности, но зачем так категорично? Слой навигации — полезная вещь, сами используем похожее, правда, в iOS.
Это две разные ситуации. В случае с Exception — это "отсекающие" условия. В вашем примере уместнее оставить else.
Да
Посмотрите внимательней, нет там ускорения. Так лишь кажется, оттого что вращение совмещено со схлопыванием/расхлопыванием арки.
ValueBinder+BundleCompat.Правильным решением было бы предотвращать пересоздание Activity-компонента при смене конфигурации (как — отдельный вопрос, есть несколько способов), но с dagger-android, насколько я понял, разработчик не контролирует время жизни компонента. Тогда остается либо вносить изменения в сам dagger-android, либо отказаться от него.
Я правильно понимаю, что при смене конфигурации пересоздаются Dagger-зависимости, но ViewModel остается прежней?
Напротив, статья хорошая и нужная. Я, например, давно смотрю в сторону Upwork, но никак не решусь. И статьи вроде этой — то, что мне нужно.
Во ViewModel не должно быть платформозависимого кода, иначе теряется то самое преимущество MVVM, о котором сказал Don_Eric.
А если приходится это делать, или писать разные ViewModel, это нужно рассматривать как симптом того, что-то вы делаете не так. Возможно, в ViewModel оказывается часть кода, который должен быть в View (просто предположение).
Возник вопрос по первому варианту. Что и с чем сервер будет сравнивать? Если клиент посолит пароль одноразовой солью и захеширует, как сервер поймет, что за хеш ему прислали?
Можете объяснить подробнее или привести пример реализации?