Преимущества

• Стабильность

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

• Лёгкий вес

  • Минимум зависимостей: требуется только lifecycle и support lib.
  • Упрощённая реализация: всего несколько десятков классов.

  Примечание: эти две библиотеки почти всегда включены в новые проекты Android Studio, то есть зависимость практически равна нулю.

• Низкие затраты на внедрение

  • Низкая инвазивность: не нужно изменять существующий код.
  • Бесшовное встраивание: можно использовать его косвенно как View, независимо от того, используется ли MVP или MVC ранее, просто добавив View внутрь, это не повлияет на вашу структуру.

• Простота

  • Удобство для разработчиков: вам практически не нужно изучать API фреймворка, чтобы начать его использовать.
  • Легко освоить для тех, кто знаком с react и flutter.

**Подробное описание можно найти ниже.

• Разделение

Сильная сторона MVVM заключается в разделении UI и логики, позволяя разработчикам не беспокоиться о UI при обработке логики и не заботиться о данных при создании UI.

При обновлении данных вы напрямую изменяете их, что автоматически вызывает перерисовку. Не нужно беспокоиться о проблемах с производительностью, так как по умолчанию старый View не будет отброшен, а будет обновлён только один раз.

public class StatefulUserWidget extends StatefulWidget<View, UserWidget> {
    private UserBean user = UserDataSource.getInstance().getUser();

    public StatefulUserWidget(Context context, Lifecycle lifecycle) {
        super(context, lifecycle);
    }

    @Override
    protected State<UserWidget> createState(Context context, Lifecycle lifecycle) {
        return StateUtils.create(new UserWidget(context, lifecycle, user));
    }

    @Override
    public void initWidget(UserWidget widget) {
        widget.setOnClickListener(v -> setState(() -> {
            user = UserDataSource.getInstance().getUser();
        }));
        update();
    }

    @Override
    public void update() {
        super.update();
        widget.setUser(user);
    }
}

В методе initWidget виджету назначается обработчик кликов, который после нажатия получает новые данные и автоматически инициирует обновление UI. Фактически, вызывается метод setState для запуска обновления, аналогично react и flutter, где операции обновления данных должны быть помещены в этот метод, иначе обновление не произойдёт.

• Высокая степень повторного использования

Дизайн этого фреймворка похож на концепцию «Everything's a Widget» во flutter, которая рассматривает все как виджеты. Каждый виджет независим, контейнерные виджеты могут объединять один или несколько виджетов, каждый виджет имеет свой собственный жизненный цикл. Таким образом, повышается возможность повторного использования виджетов.

• Удобный жизненный цикл

Благодаря недавно представленному Google жизненному циклу, каждый виджет теперь может иметь полный жизненный цикл, даже данные могут иметь свой жизненный цикл.

• Поддержка асинхронности (синхронный запрос)

Для клиентского программирования наиболее сложной задачей является обработка асинхронных вызовов и синхронизация состояний. Многопоточное программирование сложно, и малейшая ошибка может привести к утечкам памяти или сбоям. Этот фреймворк внутренне обрабатывает асинхронные запросы и автоматически отменяет операции дочерних потоков при уничтожении, предотвращая утечки памяти или проблемы, вызванные асинхронными вызовами.

Фреймворк предоставляет следующие методы для изменения данных:

• setState: синхронное выполнение операций по изменению данных (подходит для операций, не требующих времени, без переключения потоков).
• setStateAsync: асинхронное выполнение операций изменения данных, автоматическое прекращение асинхронного потока при уничтожении.
• setStateAsyncWithCache: аналогично setStateAsync, поддерживает кэш.

С его помощью вы можете синхронно отправлять сетевые запросы. Объединение нескольких запросов данных становится очень простым (например, сначала запросить a, затем b, объединить результаты в c).

• Кэширование

Кэширование сложно. Существует тысяча приложений и тысяча видов кэшей. Я видел много грубых решений для кэширования в Интернете, которые обычно реализуются через прокси-серверы. Это позволяет избежать вмешательства в бизнес-код. Однако у такого подхода есть серьёзные недостатки, он недостаточно гибкий. Хотя такие сетевые библиотеки, как okhttp, предоставляют поддержку кэширования, например, возможность установить использование только кэша или сети, но это всё ещё недостаточно гибко.

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

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

• Управление состоянием страницы

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

Хотя реализация проста, распространённым подходом является BaseActivity BaseFragment, я не хочу видеть их снова, потому что раньше я думал, что base — это хорошая логическая абстракция и инкапсуляция, но позже обнаружил, что после появления base миграция и повторное использование почти равны нулю. base заставляет их тесно связываться друг с другом. Если вы не понимаете, о чём я говорю, я приведу пример:

Я хочу извлечь страницу и логику, похожую на проект A, из проекта B. В этом случае наиболее распространённым способом является копирование XxxActivity.java в проект B, а затем...

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

Конкретное использование см. в продвинутом руководстве 1 3 4.

• Фильтрация запросов

Не знаю, сталкивались ли вы с этим, но продукт говорит вам, что пользователь может нажимать кнопки безумно, прося вас добавить проверку, чтобы уменьшить ненужные запросы. Звучит просто, но на самом деле это непросто. Достаточно просто предотвратить многократное нажатие кнопки, но несколько кнопок? Вы говорите, что можете извлечь BaseButton? А что, если это кнопка text или fab? Конечно, base может решить многие повторяющиеся проблемы с кодом, но вам также придётся заменить соответствующие кнопки на base, что требует больших усилий.

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

• Повторная попытка

Повторная попытка также является распространённым требованием, но её реализация непроста, в основном есть два метода:

• Если это делается на уровне кода, вам необходимо повторно инициировать запрос в обратном вызове при ошибке, а также вести учёт количества попыток. Это хлопотно.
• Если это сделано на сетевом уровне, вам нужно инкапсулировать сеть, предоставив метод для установки количества повторных попыток. Однако этот подход имеет серьёзные недостатки и не может хорошо сочетаться с бизнесом. Поскольку сетевой уровень не знает, когда следует повторить попытку, следует ли повторять попытку при сбое сети или возвращать содержимое, указывающее на неудачу, и повторять попытку?

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

• Динамическое свойство

Динамическая смена скинов или изменение стилей также являются распространёнными требованиями, но для реализации таких требований разработчикам часто приходится заранее писать код для модификации UI в соответствии с конфигурацией.

Этот фреймворк также обеспечивает поддержку, вы можете использовать json для настройки свойств wiget. Поэтому изменить скин или стиль очень просто.

• Одностраничное приложение (тест)

Те, кто занимается фронтендом, должны хорошо понимать, что это такое, то есть весь рендеринг происходит на одной странице, а переходы страниц контролируются фронтенд-маршрутизатором. Соответствующий клиент — это все UI в одном activity. Создание состояния (createState) и жизненный цикл виджета

Метод createState(Context context, Lifecycle lifecycle) используется для создания объекта State.

• Рендеринг (render) при первом вызове -> создание состояния (createState) -> инициализация состояния (state.init) -> построение состояния (state.build) -> рендеринг виджета (widget.render) -> инициализация виджета (initWidget).

• Обновление состояния: вызов setState в состоянии (state.setState) -> обновление состояния (state.update) -> обновление виджета (widget.update).

AndroidWidget

Конструктор (конструктор) -> создание представления (createView).

Рендеринг при первом вызове (render) -> инициализация представления (initView) -> инициализация событий (initEvent) -> инициализация данных (initData).

Виджет с жизненным циклом (Lifecycle)

Порядок вызова: рендеринг при первом вызове (render) -> связывание жизненного цикла (bind lifecycle).

Важно отметить, что связывание жизненного цикла происходит после полной инициализации виджета.

Жизненный цикл: связывание жизненного цикла позволяет виджету получить полный жизненный цикл.

Методы жизненного цикла:

— onStart;

— onResume;

— onPause;

— onStop;

— onDestroy.

BaseAndroidWidget — базовый виджет с поддержкой native виджетов и общих свойств View.

Инициализация представления (initView) происходит после рендеринга.

Привязка к окну (onStart) -> обновление свойств (updateProps) при наличии LayoutParams.

ViewGroupWidget

Рендеринг при первом вызове (render): рендеринг дочерних элементов (children.render), затем рендеринг самого виджета (super.render(render self)), добавление дочерних элементов в ViewGroup.

Добавление дочерних элементов (addChildren) -> обновление свойств дочерних элементов (updateChildrenProps) -> обновление собственных свойств (updateProps).

To Do List

Фреймворк

— [x] базовая структура;

— [x] асинхронная поддержка;

— [x] поддержка повторных попыток;

— [x] фильтрация;

— [x] кэширование;

— [x] улучшение базовых свойств и API BaseAndroidWidget;

— [x] запуск активности (startActivity);

— [x] XML-поддержка;

— [] поддержка модульного тестирования;

— [] CoroutineState (kotlin сопрограммы);

— [] управление состоянием приложения (аналог redux или mobx);

— [] шаблоны Android Studio.

Базовые виджеты

— FrameWidget;

— LinearWidget;

— RelativeWidget;

— RecyclerWidget;

— TextWidget;

— ImageWidget;

— SwipeRefreshWidget;

— ButtonWidget;

— ToolbarWidget;

— EditWidget;

— FloatingActionButtonWidget;

— ScrollWidget;

— HorizontalScrollWidget;

— DrawerWidget.

Продвинутые виджеты

— LceeWidget;

— LceermWidget;

— RmWidget;

— ListWidget;

— HorizontalListWidget;

— Route, Navigator.

Виджеты с темами

— material: ChipWidget, ChipGroupWidget, MaterialButtonWidget, TextInputLayout, TextInputEditText.

Документация

— преимущества;

— быстрое начало работы;

— вводное руководство;

— продвинутое руководство;

— виджеты;

— стратегия асинхронных потоков;

— внутренняя структура;

— каталог;

— английская версия;

— список задач.

Благодарности

Благодарим liyujiang-gzu за постоянную поддержку и помощь.

Лицензия

Apache License 2.0.