1. Постараюсь перефразировать комментарий: VPS в топку, поднимаем в облаке. Принимаю этот фича реквест, после выпуска MVP (1 октября) посмотрим как перенести бек на AWS/ЯОблако. Да, это действительно проще, но в бесплатный тариф мы не уложимся. Плюс сравним производительность бюджетной VPS с микроинстансами AWS.
2. Я скорее ждал от читателя Хабра патча к теме статьи по поводу запуска Докера под рутом, советов по настройке iptables и пр. Такой контекст был бы полезнее для других читателей.
3. Предлагаю обсудить те фичи, которые по вашему мнению будет сложнее решить чем, например на NodeJS.
Отличный перевод. В оригинале несколько витиеватый английский и несколько настораживает рейтинг «для начинающих» (ИМХО: половина этой статьи нужна исключительно НЕначинающим). Хорошо, что такой материал теперь есть на русском.
Восстановил пароль от Хабра для этого комментария.
Полностью поддерживаю автора. Ушел на похожую «архитектуру» год назад (с MVP, кстати). Не пожалел ни разу:
1. «Эфемерность» андроидных вью решается встроенным объектом стейта (vanilla/Bundle, Icepick), либо «улучшенными фрагментами Conductor».
2. Однонаправленный поток данных? Сетевой слой в сервис (по возможности IntentService — чтобы о байндингах и экземплярах при множественных запросах не думалось). Никаких ответов во вью слой: результат — в удобный storage ObjectBox.
3. Обновление вью? Подписка на представление хранилища (Rx рулит).
4. Несколько сетевых API, использование аппаратных провайдеров, логика на стороне клиента? О да, достаем DI. Только не монструозного Dagger2, а лаконичного Toothpick.
— И, ой! Это же классический MVC?! Ему же лет 40! Фу! Да, это так.
— И что, приложение магазина «весит» меньше 10МБ вместе с картинками? Да, но мне и не за LOC (количество строк кода) платят.
— А какая «магия» нужна для обновления данных отображаемых в неактивном parentView при изменениях в его Child? Никакой, это дефолтная особенность «архитектуры».
2. Я скорее ждал от читателя Хабра патча к теме статьи по поводу запуска Докера под рутом, советов по настройке iptables и пр. Такой контекст был бы полезнее для других читателей.
3. Предлагаю обсудить те фичи, которые по вашему мнению будет сложнее решить чем, например на NodeJS.
Астрономы говорят, что на Солнце в телескоп можно посмотреть два раза. Один раз левым глазом а потом ещё один раз. Эти же какие-то хитрые астрономы…
А ну как Толерасты набегут? Где, скажут, многообразие и самоидентификация в полах?! Да и поржать на разборе ответов можно будет...
Восстановил пароль от Хабра для этого комментария.Полностью поддерживаю автора. Ушел на похожую «архитектуру» год назад (с MVP, кстати). Не пожалел ни разу:
1. «Эфемерность» андроидных вью решается встроенным объектом стейта (vanilla/Bundle, Icepick), либо «улучшенными фрагментами Conductor».
2. Однонаправленный поток данных? Сетевой слой в сервис (по возможности IntentService — чтобы о байндингах и экземплярах при множественных запросах не думалось). Никаких ответов во вью слой: результат — в удобный storage ObjectBox.
3. Обновление вью? Подписка на представление хранилища (Rx рулит).
4. Несколько сетевых API, использование аппаратных провайдеров, логика на стороне клиента? О да, достаем DI. Только не монструозного Dagger2, а лаконичного Toothpick.
— И, ой! Это же классический MVC?! Ему же лет 40! Фу! Да, это так.
— И что, приложение магазина «весит» меньше 10МБ вместе с картинками? Да, но мне и не за LOC (количество строк кода) платят.
— А какая «магия» нужна для обновления данных отображаемых в неактивном parentView при изменениях в его Child? Никакой, это дефолтная особенность «архитектуры».