Какова логика проектирования фрагментов как статических внутренних классов по сравнению с автономными общедоступными классами?

Это возвращает меня к исходной точке, и у меня возникает вопрос: ну, если дизайн фрагмента был принят для того, чтобы отделить код, то почему мы объединяем фрагмент с действием, помещая его в класс действия, а не помещая их как автономные общедоступные классы? Разве это не противоречит самому существованию Фрагментов?

Основной движущей силой фрагментов является не разделение, а скорее композиция: повторно используемые части пользовательского интерфейса, которые можно легко скомпоновать вместе в различных конфигурациях. Из компонуемости следует модульность, а из нее — развязка, так что да, развязка есть, но это не главная задача.

Узнайте больше об философии проектирования фрагментов.

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

Один из часто встречающихся способов хранить фрагменты в отдельных классах, но близко к связанным действиям, например, использовать префикс именования, чтобы они сортировались вместе в алфавитных списках в одном пакете: например. FooActivity с FooDetailsFragment.

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

Просто постарайтесь быть последовательным, чтобы другие люди, читающие код, могли легко ориентироваться в кодовой базе, а метрика кода WTF/минута оставалась низкой.

Мы все еще страдаем от упомянутой выше проблемы с утечкой памяти?

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

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

Есть ли способ, чтобы фрагменты оставались внутренним классом и по-прежнему использовались в других местах? Возможно, я тоже что-то упускаю... так что сообщите мне.

Вы можете ссылаться на общедоступные внутренние классы с помощью точечной нотации Outer.Inner в коде или Outer$Inner с отражением (например, файлы XML).

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

Я хотел бы лучше знать логику против вашей идеи; Я постоянно создаю фрагменты в своем собственном классе, и мои приложения работают как часы во время переориентации. Я использую интерфейс для общения с управляющей активностью, использую адаптеры для управления фрагментами и выполняю базовый учет, чтобы гарантировать, что я не запускаю несколько фоновых потоков из-за повторной загрузки.

Поэтому я проверяю http://developer.android.com/guide/components/fragments.html, который всегда стоит перечитать, и что вы знаете, пример внизу - это именно то, что вы предлагаете, и я использую каждый день: два общедоступных фрагмента в автономных классах, которые присоединены к действию и посредством действия.

Если кто-то действительно предполагает то, что вы говорите, я подозреваю, что он придерживается линии «Фрагмент всегда должен быть встроен в действие, и жизненный цикл фрагмента напрямую зависит от жизненного цикла основного действия». слишком, слишком буквально; они означают встроенные в среду выполнения.

gl hf!