1) Мы не используем “чистую архитектуру” в ее первозданном виде, скорее некую адаптацию. Интерактор сохраняет свое состояние только для кеширования результатов части запросов. В ситуации описанной вами скорее всего за это будет отвечать верхнеуровневый презентер.
2) Чаще всего в проекте используется MVP. Пристально смотрим в сторону однонаправленных архитектур и экспериментируем с ними.
Мы стараемся максимально изолировать презентеры и интеракторы от взаимодействия с android-классами. Это облегчает юнит-тестирование: тесты можно запускать без Robolectric.
Новое приложение я бы писал на привычном Kotlin, для сетевого взаимодействия выбрал бы OkHttp в паре с Retrofit, RxJava2 для поддержки reactive streams и обязательно посмотрел бы в сторону Architecture Components. MVP же заменил бы однонаправленной архитектурой (Redux, MVI).
Примерно так же, как работает режим «в перчатках» на некоторых устройствах — повышается чувствительность сенсора настолько, что экраном можно управлять с небольшого расстояния до него.
В контексте системы сборки для Android ANT морально устарел. Во первых, более сложные скрипты на ANT читать затруднительно, из — за мягко говоря странного синтаксиса (на мой взгляд). Во вторых, для таких простых и часто используемых операций как смена packageName, изменения поля в каком — либо классе для различных task'ов, приходится использовать мягко говоря не тривиальные методы. По большому счету вины ANT тут нет, есть плохая поддержка со стороны разработчиков Android, ведь для Gradle вышеописанные задачи решает отдельный плагин.
Попробовать настройки SQLite и множественный insert действительно интересно, стоит провести эксперимент. Спасибо за совет.
Список о котором идет речь в статье (который сохранялся 40 секунд) состоял из 10 полей, одно из которых было ссылочным полем на другую сущность. Список состоял примерно из 500 объектов.
Мобильные клиенты используют БД как кэш, чтобы обеспечить работу приложения без интернета. Особенно это актуально для Android где приложение может быть выгружено из памяти в любой момент. Согласитесь, что гораздо приятнее смотреть на кэшированные данные, чем на сообщение об ошибке.
1) Мы не используем “чистую архитектуру” в ее первозданном виде, скорее некую адаптацию. Интерактор сохраняет свое состояние только для кеширования результатов части запросов. В ситуации описанной вами скорее всего за это будет отвечать верхнеуровневый презентер.
2) Чаще всего в проекте используется MVP. Пристально смотрим в сторону однонаправленных архитектур и экспериментируем с ними.
Мы стараемся максимально изолировать презентеры и интеракторы от взаимодействия с android-классами. Это облегчает юнит-тестирование: тесты можно запускать без Robolectric.
Новое приложение я бы писал на привычном Kotlin, для сетевого взаимодействия выбрал бы OkHttp в паре с Retrofit, RxJava2 для поддержки reactive streams и обязательно посмотрел бы в сторону Architecture Components. MVP же заменил бы однонаправленной архитектурой (Redux, MVI).
Отдельно с этой функцией Mockito 2 проблем не было, но в связке с Robolectric она не работает. Не совсем понятно как включать ее для отдельных тестов.
Код сохранения списка после введения оптимизации:
На самом деле точное время взято больше для красного словца, точные значения уже забылись, но порядок примерно такой.
Список о котором идет речь в статье (который сохранялся 40 секунд) состоял из 10 полей, одно из которых было ссылочным полем на другую сущность. Список состоял примерно из 500 объектов.
Могу ошибаться о закрытости кода ядра, создатели приводят инструкцию по сборке.