Kotlin code style

Это было тяжелое решение — на самом деле тут trade off между camelCase в xml и snake_case в котлин файлах. Мы выбрали второй вариант, хотя тут команда разбилась на два лагеря.

На самом деле — это вкусовщина.

Стратегии в Moxy (Часть 2)

Довольно часто встречается ситуация: На экране есть состояния: LOADING, DATA, STUB.
Соответсвенно, у нас будут методы у SomeView

interface SomeView : MvpView{
   fun showData(data: Data)

   fun showError(error: Error)

   fun showStub()

   // еще методы
}

мы хотим, чтобы эти методы были взаимоисключающие, при этом, остальные методы должны лежать в очереди команд. Тут нам поможет кастомная стратегия

Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM

Спасибо за интересную статью! dmdev а как подразумевается обработка ситуации, когда процесс убился и произошло последующее восстановление Activity?

В этом случае у Вас PresentationModel будет в состоянии A а View в состоянии B

Стратегии в Moxy (часть 1)

Всегда говорил, что писали его в Arello командой Пруф ;)

Стратегии в Moxy (часть 1)

Создатели библиотеки я и senneco это известная информация. Я работаю в REDMADROBOT, поэтому статья публикуется от блога компании — не вижу каких то противоречий

Стратегии в Moxy (часть 1)

"Наш" = нас с Юрой

Стратегии в Moxy (часть 1)

Спасибо за замечание, исправим! По умолчанию AddToEndStrategy.

Как мы делали приложение международной программы лояльности PINS: кейс

Да, тернарного оператора не достает, но зато if/else являются выражениями и есть очень мощный оператор when.

Еще из таких маленьких неудобств — catch блоки не могут иметь несколько типов исключений. Странно, что JB не ввела в язык еще и этот сахар

Как мы делали приложение международной программы лояльности PINS: кейс

главным, да и по сути единственным серьезным недостатком остается debugger у Android Studio, потому что то он все еще плохо работает с Kotlin.

В остальном, котлин значительно увеличил скорость разработки и уменьшил число багов. Попробуйте котлин, после него на Java не хочется писать от слова совсем;-)

Как мы делали приложение международной программы лояльности PINS: кейс

Полностью, за исключением форков сторонних либ. В Роботах разработка Android приложений ведется полностью на kotlin

Moxy — реализация MVP под Android с щепоткой магии

Да, излишне запутанно. Это тот самый случай когда надо выбирать простоту

Cicerone — простая навигация в Андроид приложении

Без команды SystemMessage это можно сделать двумя способами

А еще есть третий способ, презентер, на который возвращаемся, подписывается на ивенты/обсервер модели о протухании авторизации.

Таким образом, при возврате на экран он примет состояние: показать ошибку авторизации

Moxy — реализация MVP под Android с щепоткой магии

terrakok нужно третье мнение

Moxy — реализация MVP под Android с щепоткой магии

senneco можем сделать дополнительный слой абстракции:

В каждой вью нужно будет подключаться к PresenterStore через метод MvpFacade.getPresenterStore

Дефолтная map Presenter с PresenterImpl будет генериться статической кодогенерацией и подаваться как параметр к PresenterStore

MvpFacade будет инициализировать либо тестовым PresenterStore, либо живым с дефолтной мапой.

Остался вопрос, есть ли в этом потребность и на сколько станет все сложнее для понимания)

Kotlin 1.0. Задай вопрос команде

Добрый день, belovrv

Есть ли способ создать .kt файлы c помощью javax.annotation.processing.Processor?

Moxy — реализация MVP под Android с щепоткой магии

C первого взгляда кажетя, что использование MVP на экранах с одной кнопкой избыточно. Но, в последствии, начинаешь воспринимать MVP как философию от которой не хочется отходить. Более того, использование одного подхода повсеместно делает приложение консистентным и легким для поддержки.

Основные проблемы MVP подхода уже решены

• boilerplates связи презентеров и вью решается статической кодогенерацией шаблонов
• хранение состояние в презентерах решается динамической кодогенерацией

Так что смело используйте!

MVP на стероидах: заставляем робота писать код за вас

А у Вас все слои архитектуры в одном пакете? А общие классы куда-нибудь выносите? К примеру, если объект продукт нам понадобится и в каталоге и в корзине, то в какой пакет нам его поместить?

MVP на стероидах: заставляем робота писать код за вас

В результате на каждое Activity и Fragment будет свой пакет? В большом проекте в корневом пакете будет слишком много вложенных пакетов. Это осложнит навигацию.

Мы используем описанную иерархию. Она зарекомендовала себя как довольно практичная

В любом случае, разделение по пакетам советую делать так, как удобно Вам, т.к. единого мнения не существует

MVP на стероидах: заставляем робота писать код за вас

HotIceCream, складывать все в один пакет удобно до тех пор, пока приложение не разрастается. Представим, что к пакету car относятся 4 Fragment и Activity которое ими управляет. Это означает что в одном пакете будет лежать как минимум 15 классов.

Также непонятно куда складывать базовые классы для Presenter, Activty. По такой логике нам нужно создавать пакет base?

senneco, я уже пробовал раскладывать по логическим пакетам, в результате было не очень удобно. Если в пакет складывать только один экран, то получается слишком мелкое деление, а если несколько, то огород.

для data объектов мы используем отдельный пакет ui_data, в нем также сохраняется разбиение на пакеты