Пишем под android с Elmslie

[BellaLugoshi]

я очень далёк от вэба (html не считается же) и от мобильных приложений (простите, но даже hello world в виде apk так и не смог освоить), но пишу для себя на С++/C#. Но я вижу ООП уже почти 30 лет и совершенно в неизменном виде и не могу до сих пор понять, почему для мобилок всё пишется в таком низкоуровневом виде? Одно дело написать например игру, другое дело клиент-серверное ПО для банка, то есть когда у вас клиентское приложение это скорее тонкий клиент. Так вот зачем вообще в мире занимаются низкоуровневой разработкой таких приложений? Это же банально устарело, непродуктивно, каждый городит какие-то библиотеки. Почему не писать так: на одном уровне рисуется набор интерфейсов, на другом в элементах интерфейса изменяются данные полученные с сервера, все равно без интернета такое приложение бесполезно. Зато вы получаете многоязыковое приложение из коробки, кастомный дизайн под каждого клиента. И разработка сводится к описанию того что именно вывести на экран. Я не знаю есть ли такой язык вообще, но это логичное развитие, а то что вы предлагаете для меня выглядит как сова натянутая на глобус джавы.

[diklimchuk]

В целом ситуация такая, как вы описываете. Эта библиотека помогает работать со слоем, где «в элементах интерфейса изменяются данные полученные с сервера». Очень грубое ближение — если рассматривать архитектуру MVP, то наша библиотека помогает более структурированно подойти к написанию Presentation слоя. Так приходится делать, потому что android приложения со временем становятся достаточно сложными проектами и не только отображают данные с бекенда. Со временем может появляться бд, логика кеширования и синхронизации, а некоторые приложения пишут более 100 разработчиков. По нашему проекту заметно, что часто логика экрана, на котором есть несколько запросов к бекенду, становится слишком сложной. Нужно обработать множество состояний, фиче тоглов, все это покрыть тестами и написать код так, чтобы можно было через год вернуться к нему и все понять. Это усложняет архитектуру, но позволяет писать более чистый код. В целом это частое явление для андроид приложений, есть примеры и более сложных архитектур, например MVICore или RIBS от Uber. Подробнее мы рассказывали про то как к этому пришли в первой и второй частях, возможно они помогут в этом разобраться.

[Stersh]

А как будет решаться в вашей библиотеки случай, когда нужна подписка на изменение данных из бд или вебсокета например?

[diklimchuk]

Все будет практически так же, как с загрузкой данных. При обработке события Init нужно отправить команду ObserveData. Actor будет выглядеть вот так:

class Actor : Actor<Command, Event> {
    override fun execute(command: Command) = when (command) {
        is Command.ObserveData -> ValueRepository.observeValues()
            .mapEvents(Internal::OnSuccess, Internal.OnError)
    }
}

Результатом выполнения команды является Observable, поэтому можно в любой из команд подписываться на обновление данных