Комментарии 5
По прежнему большая часть работы остается в Activity, хотелось бы большей энкапсуляции в отдельные классы, что бы этот класс делал все внутренние проверки:
if (shouldShowRequestPermissionRationale(Manifest.permission.CAMERA)) {
// доступ к камере запрещен, нужно объяснить зачем нам требуется разрешение
} else {
singlePermission.launch(Manifest.permission.CAMERA)
}
Возможно это идея для новой библиотеки.
if (shouldShowRequestPermissionRationale(Manifest.permission.CAMERA)) {
// доступ к камере запрещен, нужно объяснить зачем нам требуется разрешение
} else {
singlePermission.launch(Manifest.permission.CAMERA)
}
Возможно это идея для новой библиотеки.
И в результате разработчики Android значительно усложнили поведение. Принцип SRP здесь совершенно ни при чём, т.к. активность сама по себе часто не SRP.
Проблема в том, что активности могут многократно передавать данные между другими активностями и фрагментами. Длительная навигация по активностям и фрагментам приводит к тому, что приходится постоянно везде передавать setResult(RESULT_OK, data), не менять случайно данные. Если где-то забыли, что прилетит RESULT_CANCELED.
Затем нужно прописать в каждой активности множество коллбеков от других активностей и фрагментов. Затем нужно отследить, от какого фрагмента и от какой активности пришёл коллбек, нигде никакой не забыть. Всё было просто, когда был единый onActivityResult.
Затем надо не забыть вовремя зарегистрировать коллбеки (в onAttach, onCreate) до их первого использования.
В итоге имеем десятки часов отладки в огромном приложении и раздутый код.
Проблема в том, что активности могут многократно передавать данные между другими активностями и фрагментами. Длительная навигация по активностям и фрагментам приводит к тому, что приходится постоянно везде передавать setResult(RESULT_OK, data), не менять случайно данные. Если где-то забыли, что прилетит RESULT_CANCELED.
Затем нужно прописать в каждой активности множество коллбеков от других активностей и фрагментов. Затем нужно отследить, от какого фрагмента и от какой активности пришёл коллбек, нигде никакой не забыть. Всё было просто, когда был единый onActivityResult.
Затем надо не забыть вовремя зарегистрировать коллбеки (в onAttach, onCreate) до их первого использования.
В итоге имеем десятки часов отладки в огромном приложении и раздутый код.
Совершенно с вами согласен. Причем ощущение что само SDK идет в другую сторону от каких либо принципов. Можно конечно весело шагать в том же направлении и махать флажками гугла, но как то не хочется…
Спасибо! Мне приятно, что на «Хабре» есть единомышленники. Да, этот ActivityResultApi, с одной стороны, немного упорядочил код, но с другой стороны, сильно его увеличил, а также привёл к многочисленным крэшам. Сколько на нём в результате было поймано багов при сложной навигации (особенно через push-уведомления и DeepLink'и).
Также ежемесячные мучения по переписыванию депрекейтов в андроидных библиотеках. Меняют не только классы, но целые библиотеки.
Также ежемесячные мучения по переписыванию депрекейтов в андроидных библиотеках. Меняют не только классы, но целые библиотеки.
они сами то хоть пользовались этой шнягой?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Получаем результат правильно (Часть 1). Activity Result API