Про модели — верно. Каждому слою свои модели, часто обмазанные своими аннотациями (например, для room-энтитей, или для моделей, которые будут сериализовываться gson/moshi/kotlinx-serialization). Между слоями модели гоняются через мапперы. К тому же в моделях респонсов сервера желательно все поля сделать nullable — нельзя доверять тому, что приходит извне.
Пару замечаний:
— в методе requestWithCallback() в блоке try результат доставляется в main-потоке, а в блоке catch ошибка доставляется уже в io-потоке — потенциальный крэш во viewOneError()
— data-класс Event вместе с enum Status лучше и компактнее будет выглядеть в виде sealed-класса
— отдавать MutableLiveData наружу из ViewModel — плохая практика. наружу должна торчать LiveData (через backing-property или какой-нибудь get-метод)
С каких пор паттерн Наблюдатель зло? Может вы не умеете его готовить?
Работа с активити-тасками и стеком активитей хорошо описана в документации, и «прочие неработащие флаги» работают так как и должны. Хранить ссылки на все активити — вот где зло.
Пересмотрите подход. В двух словах — вам не должны быть нужны строки локализации вне активити/фрагмента. Текст отображается на UI, а не там, где нет контекста. Тот код, где вы решаете какой текст вывести (бизнес логика), не должен зависеть от каких-то там ресурсов
Хм. Пока не совсем понятно преимуществ. Не проще и не функциональнее упомянутого выше okhttp. Как минимум нет interceptorов (для логирования, авторизации и т.п.), sslfactory. Не совсем понятно, что под капотом, насколько решены проблемы совместимости с разными версиями андроида. И не всегда нужно получать callback в main-потоке — тот же парсинг json по-хорошему нужно делать не выходя из io-потока. А если еще притянуть архитектурные подходы… И почему в заголовке упомянуты rest/rpc, ведь библиотека не об этом
Например, если использовать LiveData, то после OnStop, данные придут в LiveData, и при следующем OnResume наш observer сработает и мы увидим сообщение.
Для этого в Rx есть BehaviorSubject/BehaviorProcessor — хранит текущее значение и возвращает его сразу при подписке на него (и само собой все последующие изменения тоже эмитит)
Эм, а что такого сложного изображено на этой карте, что появилась нужда в SurfaceView/TextureView? И зачем сразу рендерить карту в 5000х5600?
Судя по скринам — десяток линий, кружков и подписей можно чуть ли не в реалтайме рисовать/скейлить/перемещать на обычном канвасе.
И да — можно рисовать и за границей канваса. Просто layout, в котором лежит вьюха, делает clip по размерам вьюхи, что можно отключать через clipChildren=«false»
Все модули равноценны на уровне проекта, «модулей внутри модулей» нет.
Сами модули можно размещать в разных папках и подпапках проекта (с указанием пути в settings.gradle)
В таком случае фрагмент будет жестко привязан к MainActivity, т.е. если использовать этот фрагмент в другой активити, то придется во фрагменте еще проверку и кастинг для другой активити добавлять. Не тестируемо, не расширяемо.
Runnable не создает новый поток. Он вообще ничего не создает, это просто интерфейс. А вот его реализацию уже можно передать, например, в Thread, или Executor, или Handler
Ну вам же написали про onSaveInstanceState/onRestoreInstanceState. Стандартные компоненты по возможности восстанавливают свое состояние. Для всего остального уже есть готовые инструменты, на которые большинство разработчиков забивают, потому что на возросших мощностях девайсов нужно еще постараться, чтобы воспроизвести пересоздание активити системой.
Но на одних позитивных сценариях далеко не уедешь, максимум это все эти запреты переворотов сойдут только для низкобюджетных или pet-проектов.
Уже миллион раз сказано — пересоздание активити происходит не только при перевороте, а еще при смене локали, сим-карты, подключении внешней клавы, смене размера шрифта, смене размера экрана (multiwindow), смена ui-режима (dex-станция).
Будете все запрещать?
Да даже при входящем звонке система может прибить активити, а после окончания звонка пользователь вернется в приложение без восстановленного стейта.
Доводилось мне видеть некоторое дерь приложения, «архитектура которых не сильно интересовала разработчиков». Вот честно — лучше бы там была архитектура, чем новомодности и быстро-фреймворки. (Против котлина ничего против не имею)
— в методе requestWithCallback() в блоке try результат доставляется в main-потоке, а в блоке catch ошибка доставляется уже в io-потоке — потенциальный крэш во viewOneError()
— data-класс Event вместе с enum Status лучше и компактнее будет выглядеть в виде sealed-класса
— отдавать MutableLiveData наружу из ViewModel — плохая практика. наружу должна торчать LiveData (через backing-property или какой-нибудь get-метод)
Работа с активити-тасками и стеком активитей хорошо описана в документации, и «прочие неработащие флаги» работают так как и должны. Хранить ссылки на все активити — вот где зло.
Пересмотрите подход. В двух словах — вам не должны быть нужны строки локализации вне активити/фрагмента. Текст отображается на UI, а не там, где нет контекста. Тот код, где вы решаете какой текст вывести (бизнес логика), не должен зависеть от каких-то там ресурсов
Сборник костылей и вредных советов. Где-то в углу заплакали паттерны и чистая архитектура
Хм. Пока не совсем понятно преимуществ. Не проще и не функциональнее упомянутого выше okhttp. Как минимум нет interceptorов (для логирования, авторизации и т.п.), sslfactory. Не совсем понятно, что под капотом, насколько решены проблемы совместимости с разными версиями андроида. И не всегда нужно получать callback в main-потоке — тот же парсинг json по-хорошему нужно делать не выходя из io-потока. А если еще притянуть архитектурные подходы… И почему в заголовке упомянуты rest/rpc, ведь библиотека не об этом
Для этого в Rx есть BehaviorSubject/BehaviorProcessor — хранит текущее значение и возвращает его сразу при подписке на него (и само собой все последующие изменения тоже эмитит)
Все по делу.
А в чем databinding провинился? Без него начинает грустить mvvm
Судя по скринам — десяток линий, кружков и подписей можно чуть ли не в реалтайме рисовать/скейлить/перемещать на обычном канвасе.
И да — можно рисовать и за границей канваса. Просто layout, в котором лежит вьюха, делает clip по размерам вьюхи, что можно отключать через clipChildren=«false»
Сами модули можно размещать в разных папках и подпапках проекта (с указанием пути в settings.gradle)
Runnable не создает новый поток. Он вообще ничего не создает, это просто интерфейс. А вот его реализацию уже можно передать, например, в Thread, или Executor, или Handler
Но на одних позитивных сценариях далеко не уедешь, максимум это все эти запреты переворотов сойдут только для низкобюджетных или pet-проектов.
Будете все запрещать?
Да даже при входящем звонке система может прибить активити, а после окончания звонка пользователь вернется в приложение без восстановленного стейта.
дерьприложения, «архитектура которых не сильно интересовала разработчиков». Вот честно — лучше бы там была архитектура, чем новомодности и быстро-фреймворки. (Против котлина ничего против не имею)