Метрики сборки с разницей в 300мс репрезентативными не являются, это статистическая погрешность. Сборка модуля с плагинами происходит один раз, потом кэшируется, да и ваша система какой-то оверхед даст, какая разница, где лежит код, хоть в плагинах, хоть в косогорах.
В общем, как упражнение для разработчика чтобы разобраться в Gradle у вас получился хороший пример, но для применения в проде пока не видно ни одного преимущества по сравнению с convention плагинами :)
Тогда расскажите, что именно было медленным, какая именно часть кода внутри вызова provideApiService().getSomethingFromApi() исполнялась на главном потоке?
А вы случайно не измеряете время создания экземпляра Retrofit и вашего ApiService? Функция provideApiService() уж очень подозрительно выглядит, и конечно, если на каждый запрос создавать новый инстанс ApiService, будет медленно.
Другими словами, удалось ли понять, за счёт чего именно вы добились ускорения? Шаги "заметить проблему" и "решить проблему" были, а промежуточного "понять, где тормоза" я не заметил :)
1) Темы фрагментам задаёте в onCreateView, создавая ContextThemeWrapper? Что-то вроде:
override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View {
val contextThemeWrapper = ContextThemeWrapper(activity, R.style.Theme_MyApp_Dark)
val themedInflater = inflater.cloneInContext(contextThemeWrapper)
return themedInflater.inflate(R.layout.fragment_smoething_dark, container, false)
}
?
2) Передача данных с экрана на экран. Допустим, у нас в приложении есть экран, который умеет сканировать паспорт, и возвращать объект с паспортными данными. Если это Activity, то всё понятно, у нас одна точка выхода: onActivityResult(). Перегрузили, распарсили, передали куда надо.
Как правильно сделать это через фрагмент? Можете чуть подробнее рассказать о подходе к реализации "реактивного подхода", который использует ваша команда?
Спасибо за прекрасную статью! Многое разложилось по полочкам.
Есть вопрос по реализации репозитория, который Gateway. Если мы радостно впустили Rx в свою жизнь, чему я несказанно рад, то кто отвечает за управление потоками, в виде навешивания subscribeOn(...) или ещё чего-то? Я встречал два противоположных взгляда:
"Я умный репозиторий, и я сам решу, в каком потоке у меня будут идти запросы в сеть"
"Я синхронный репозиторий, и мне всё равно, в каком потоке меня будут использовать"
Вот с тем, что навешивать observeOn(mainThreadScheduler) на Interactor — это ответственность презентера, всё вроде ясно, хотя и тут нет единообразия. А как быть с фоновыми потоками?
Метрики сборки с разницей в 300мс репрезентативными не являются, это статистическая погрешность. Сборка модуля с плагинами происходит один раз, потом кэшируется, да и ваша система какой-то оверхед даст, какая разница, где лежит код, хоть в плагинах, хоть в косогорах.
Convention плагины это и есть максимально универсальная реализация. И конфигурацию они поддерживают https://docs.gradle.org/current/userguide/custom_plugins.html#sec:getting_input_from_the_build
В общем, как упражнение для разработчика чтобы разобраться в Gradle у вас получился хороший пример, но для применения в проде пока не видно ни одного преимущества по сравнению с convention плагинами :)
Вы ведь сами изобрели свои плагины, почему не использовать решение для плагинов, которое есть из коробки?
И работает ли ваша система с Configuration Cache?
Точно, я подумал что это с другого проекта результаты, невнимательно прочитал) Спасибо!
Тогда расскажите, что именно было медленным, какая именно часть кода внутри вызова
provideApiService().getSomethingFromApi()исполнялась на главном потоке?А вы случайно не измеряете время создания экземпляра Retrofit и вашего ApiService? Функция provideApiService() уж очень подозрительно выглядит, и конечно, если на каждый запрос создавать новый инстанс ApiService, будет медленно.
Другими словами, удалось ли понять, за счёт чего именно вы добились ускорения? Шаги "заметить проблему" и "решить проблему" были, а промежуточного "понять, где тормоза" я не заметил :)
https://github.com/kittinunf/Result вот ещё хороший аналог.
Спасибо за статью!
Пара вопросов:
1) Темы фрагментам задаёте в onCreateView, создавая ContextThemeWrapper? Что-то вроде:
?
2) Передача данных с экрана на экран. Допустим, у нас в приложении есть экран, который умеет сканировать паспорт, и возвращать объект с паспортными данными. Если это Activity, то всё понятно, у нас одна точка выхода: onActivityResult(). Перегрузили, распарсили, передали куда надо.
Как правильно сделать это через фрагмент? Можете чуть подробнее рассказать о подходе к реализации "реактивного подхода", который использует ваша команда?
Надо :) Почему риск утечек памяти (если вы о них) в Single Activity выше, чем в любом другом подходе?
Спасибо за прекрасную статью! Многое разложилось по полочкам.
Есть вопрос по реализации репозитория, который
Gateway. Если мы радостно впустили Rx в свою жизнь, чему я несказанно рад, то кто отвечает за управление потоками, в виде навешиванияsubscribeOn(...)или ещё чего-то? Я встречал два противоположных взгляда:Вот с тем, что навешивать
observeOn(mainThreadScheduler)наInteractor— это ответственность презентера, всё вроде ясно, хотя и тут нет единообразия. А как быть с фоновыми потоками?