Dev Easy Notes

Мой коллега недавно написал серию статей про фрагменты. И вот меня довольно сильно заинтересовала часть про Result API. В статье показаны базовые кейсы как это использовать. Однако в статье не указаны недостатки Result API для фрагментов, не порядок я считаю. И так как я очень люблю похейтить либы гугла, поговорим о минусах этого подхода. 

Значит, если вдруг пропустили, Result API это новый подход к тому, как мы можем получать результат с других Activity или Fragments. Вот раньше допустим был геморрой с обработкой разрешения. Нужно разрешение сперва запросить, потом переопределить метод onActivityResult, для это нужно придумывать специальные Id для этого. Мягко говоря это неудобно.

Сейчас все намного проще, вызываем специальный метод, устанавливаем в него лямбду. Затем запрашиваем разрешение и система уже дернет нашу лямбду с нужными уже распарщеными данными. Уже намного удобнее.

Result API крутая штука и по факту сейчас это единственный путь как обрабатывать разрешения или например получать фото с галереи. Метод onActivityResult сейчас помечен как Deprecated. Другими словами, Result API круто использовать когда нужно получить данные извне, однако часто это используется для передачи данных м/у своими же Activity. А когда речь заходит за использование Result API для передачи данных м/у фрагментами начинается вообще мрак. 

Основная идея, которой я уже давно придерживаюсь, и которая не раз меня спасала, сводится к следующему: “Передавайте данные м/у своими экранами через Domain слой”. View очень сильно ограничивает в плане передачи данных по трем простым причинам:

1️⃣ Формат передачи данных всегда Bundle. Если конечно не дергаются методы других фрагментов напрямую, где нужно быть ну очень аккуратным.
2️⃣ View очень неустойчивая штука. Этот слой часто меняется, он может умереть в любой момент.
3️⃣ Сложность с навигацией. Даже у библиотеки от самого гугла нет адекватной интеграции с Result API. Мб она конечно есть, но я так и не нашел как нормально это сделать.

Подход с передачей View через Domain слой куда гибче, тут 100 способов как передавать данные удобным тебе способом, в удобном тебе формате и ты целиком и полностью все контролируешь. 

Еще основная проблема, что Result API для фрагментов заставляет тебя создавать ебучие строковые константы. Это вообще проблема у всех библиотек гугла, они видимо прям в восторге от строковых констант. Иначе как объяснить это и это и вот это.

В Result API для Activity сделано круто, потому как там есть специальный класс контракт, благодаря которому, ты сразу задаешь правила как преобразовать данные из Bundle в нужный объект. Для фрагментов такого нет, в итоге тебе передают Bundle, а ты иди сам ищи в коде, что вообще в него упаковали!

Подводя итог, хотите облегчить тебе жизнь, передавайте данные м/у фрагментами через Domain слой, этот подход реально спасает когда навигация неожиданно меняется, а она будет меняться. Не хотите лишних сложностей, не тащите Result API во фрагменты!

👍24🤔2

www.tgoop.com/dev_easy_notes/179

2.08K viewsedited  Oct 26, 2022 at 14:35

Мой коллега недавно написал серию статей про фрагменты. И вот меня довольно сильно заинтересовала часть про Result API. В статье показаны базовые кейсы как это использовать. Однако в статье не указаны недостатки Result API для фрагментов, не порядок я считаю. И так как я очень люблю похейтить либы гугла, поговорим о минусах этого подхода. 

Значит, если вдруг пропустили, Result API это новый подход к тому, как мы можем получать результат с других Activity или Fragments. Вот раньше допустим был геморрой с обработкой разрешения. Нужно разрешение сперва запросить, потом переопределить метод onActivityResult, для это нужно придумывать специальные Id для этого. Мягко говоря это неудобно.

Сейчас все намного проще, вызываем специальный метод, устанавливаем в него лямбду. Затем запрашиваем разрешение и система уже дернет нашу лямбду с нужными уже распарщеными данными. Уже намного удобнее.

Result API крутая штука и по факту сейчас это единственный путь как обрабатывать разрешения или например получать фото с галереи. Метод onActivityResult сейчас помечен как Deprecated. Другими словами, Result API круто использовать когда нужно получить данные извне, однако часто это используется для передачи данных м/у своими же Activity. А когда речь заходит за использование Result API для передачи данных м/у фрагментами начинается вообще мрак. 

Основная идея, которой я уже давно придерживаюсь, и которая не раз меня спасала, сводится к следующему: “Передавайте данные м/у своими экранами через Domain слой”. View очень сильно ограничивает в плане передачи данных по трем простым причинам:

1️⃣ Формат передачи данных всегда Bundle. Если конечно не дергаются методы других фрагментов напрямую, где нужно быть ну очень аккуратным.
2️⃣ View очень неустойчивая штука. Этот слой часто меняется, он может умереть в любой момент.
3️⃣ Сложность с навигацией. Даже у библиотеки от самого гугла нет адекватной интеграции с Result API. Мб она конечно есть, но я так и не нашел как нормально это сделать.

Подход с передачей View через Domain слой куда гибче, тут 100 способов как передавать данные удобным тебе способом, в удобном тебе формате и ты целиком и полностью все контролируешь. 

Еще основная проблема, что Result API для фрагментов заставляет тебя создавать ебучие строковые константы. Это вообще проблема у всех библиотек гугла, они видимо прям в восторге от строковых констант. Иначе как объяснить это и это и вот это.

В Result API для Activity сделано круто, потому как там есть специальный класс контракт, благодаря которому, ты сразу задаешь правила как преобразовать данные из Bundle в нужный объект. Для фрагментов такого нет, в итоге тебе передают Bundle, а ты иди сам ищи в коде, что вообще в него упаковали!

Подводя итог, хотите облегчить тебе жизнь, передавайте данные м/у фрагментами через Domain слой, этот подход реально спасает когда навигация неожиданно меняется, а она будет меняться. Не хотите лишних сложностей, не тащите Result API во фрагменты!

BY Dev Easy Notes