Dev Easy Notes

Что не так с Fragment Factory?

В комментах меня попросили рассказать почему я считаю FragmentFactory не очень хорошим решением для фрагментов. Я не буду тут приводить описание того, что это и как работает. Есть вот такая статья которая достаточно просто и понятно описывает эту технологии и основные кейсы.

Начну с мысли о том, что не бывает плохой технологии. Оценивать технологии стоит исходя из их списка плюсов и минусов, а также проблем которые она решает. Выбор технологии это всегда trade off, мы всегда чем-то жертвуем.

Какую проблему решает FragmentFactory? Единственная проблема которую она решает это внедрение зависимостей во фрагмент через конструктор. Для зависимостей все проекты используют какую-либо DI библиотеку. Вне зависимости от того, существующее это решение для DI или самописное у нас во фрагменте будет завязка на этот DI. Если это Dagger, то будет аннотация inject, если это Koin, то специальные extension функции и т.д. FragmentFactory позволяет внедрять зависимости через конструктор, что означает что сам фрагмент ничего не будет знать про DI.

Это безусловно плюс этого решения. Один из кейсов когда это может понадобиться это когда вы свой фрагмент предоставляете как либу. И чтобы пользователи вашей либы не тянули зависимости на ваш DI можно использовать FragmentFactory. Это обяжет пользователей вашей либы создавать FragmentFactory, но зато предоставит возможность им выбирать с помощью чего внедрять зависимости. Вот один из вариантов через Dagger.

Из минусов этой библиотеки, проблема с передачей аргументов. Посмотрев внимательнее вы заметите, что динамическая информация вроде id по-прежнему передается через bundle. В этом и заключается неудобство. С обычным созданием фрагмента мы делаем метод newInstance который четко говорит какие данные нужны для показа фрагмента. Это четкий контракт который не позволить создать фрагмент без нужных данных. 

С использованием FragmentFactory мы уже не можем создать такой четкий контракт. Потому как мы не создаем фрагмент, мы лишь передаем класс фрагмента в транзакцию, а создается фрагмент уже в FragmentFactory. Это приводит к тому, что у нас размазывается логика передачи аргументов и мы не можем корректно проконтролировать что эти данные вообще передаются. 

Помимо этого возникает трудность интеграции с инструментами навигации. Например, тот же Cicerone, обязывает нас передавать именно объект фрагмента, уже с аргументами чтобы его запустить.  Еще из минусов вытекает, что если у вас много фрагментов, то FragmentFactory становится единой точкой у которой есть риск разрастись. FragmentFactory также обязана знать про все зависимости, что может добавить геморроя. 

Конечно проблемы которые я перечислил решаемы, за исключением аргументов. Однако нужно ли вам такое решение, которое помогает решить одну проблему, но создает целый ворох других. Причем решает она проблему, которую уже давно решили. FragmentFactory прикольное решение, однако для очень узкого круга задач.

👍25

www.tgoop.com/dev_easy_notes/104

1.87K viewsMay 25, 2022 at 05:50

Что не так с Fragment Factory?

В комментах меня попросили рассказать почему я считаю FragmentFactory не очень хорошим решением для фрагментов. Я не буду тут приводить описание того, что это и как работает. Есть вот такая статья которая достаточно просто и понятно описывает эту технологии и основные кейсы.

Начну с мысли о том, что не бывает плохой технологии. Оценивать технологии стоит исходя из их списка плюсов и минусов, а также проблем которые она решает. Выбор технологии это всегда trade off, мы всегда чем-то жертвуем.

Какую проблему решает FragmentFactory? Единственная проблема которую она решает это внедрение зависимостей во фрагмент через конструктор. Для зависимостей все проекты используют какую-либо DI библиотеку. Вне зависимости от того, существующее это решение для DI или самописное у нас во фрагменте будет завязка на этот DI. Если это Dagger, то будет аннотация inject, если это Koin, то специальные extension функции и т.д. FragmentFactory позволяет внедрять зависимости через конструктор, что означает что сам фрагмент ничего не будет знать про DI.

Это безусловно плюс этого решения. Один из кейсов когда это может понадобиться это когда вы свой фрагмент предоставляете как либу. И чтобы пользователи вашей либы не тянули зависимости на ваш DI можно использовать FragmentFactory. Это обяжет пользователей вашей либы создавать FragmentFactory, но зато предоставит возможность им выбирать с помощью чего внедрять зависимости. Вот один из вариантов через Dagger.

Из минусов этой библиотеки, проблема с передачей аргументов. Посмотрев внимательнее вы заметите, что динамическая информация вроде id по-прежнему передается через bundle. В этом и заключается неудобство. С обычным созданием фрагмента мы делаем метод newInstance который четко говорит какие данные нужны для показа фрагмента. Это четкий контракт который не позволить создать фрагмент без нужных данных. 

С использованием FragmentFactory мы уже не можем создать такой четкий контракт. Потому как мы не создаем фрагмент, мы лишь передаем класс фрагмента в транзакцию, а создается фрагмент уже в FragmentFactory. Это приводит к тому, что у нас размазывается логика передачи аргументов и мы не можем корректно проконтролировать что эти данные вообще передаются. 

Помимо этого возникает трудность интеграции с инструментами навигации. Например, тот же Cicerone, обязывает нас передавать именно объект фрагмента, уже с аргументами чтобы его запустить.  Еще из минусов вытекает, что если у вас много фрагментов, то FragmentFactory становится единой точкой у которой есть риск разрастись. FragmentFactory также обязана знать про все зависимости, что может добавить геморроя. 

Конечно проблемы которые я перечислил решаемы, за исключением аргументов. Однако нужно ли вам такое решение, которое помогает решить одну проблему, но создает целый ворох других. Причем решает она проблему, которую уже давно решили. FragmentFactory прикольное решение, однако для очень узкого круга задач.

BY Dev Easy Notes