Still using MVP? Try MVVM!

advantage

stable

lightweight

• Minimum dependencies: Lifecycle and support lib only.
• Implementation lean: only a few dozen classes

Tip: These two dependency libraries are almost always included in any new Android Studio project, meaning almost zero dependencies.

Low access cost

simple

• Native friendly: You hardly need to learn the framework API to get started.
• People familiar with React and Flutter are very easy to learn

For details, go down to the basic tutorial.

The decoupling

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) { 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); }}Copy the code

High reuse

The design idea of the framework is similar to flutter’s “Everything’s a Widget”, which treats Everything as a control. Controls are independent of each other. Container controls can combine one or more controls, and each control has an independent life cycle. As a result, the reusability of controls is greatly improved.

Convenient life cycle

Asynchronous support (sending requests synchronously)

Most troublesome for client programming are the various asynchronous calls and state synchronization. Multithreaded programming is difficult, and the slightest mistake can leak memory or crash. The framework internally handles asynchronous requests and automatically cancellations child threads when onDestroy, preventing memory leaks or null-pointer problems caused by async.

The library provides the following methods to support data modification, and developers can choose their own methods.

• setState: Synchronously performs data modification operations (applicable to non-time-consuming data modification operations without thread switching performance consumption)
• setStateAsync: Data modification operations performed asynchronously, and the asynchronous thread is automatically stopped when the UI is destroyed
• setStateAsyncWithCache: similar tosetStateAsyncSupport for caching.

With it, you can send web requests synchronously. It becomes extremely easy to merge data from multiple requests (for example, request A first, then request B, and merge the result to C).

Cache support

Page State Management

No data pages, error pages, loading pages, pull-down refresh, and loading more are common in applications.

The common method is BaseActivity BaseFragment, but I don’t want to see them. Once I thought base was a good logical abstraction and encapsulation, but later I found that since the creation of base, migration and reuse almost become zero. Base makes them tightly coupled. If you don’t know what I’m talking about, let me give you an example:

I want to extract an Activity from project A that has similar page and logic for use in project B. The most common way to do this is to copy xxxActivity.java into project B, and you get the idea.

But the library provides a high degree of encapsulation for these page states, so you don’t have to rely on Base anymore. You can have all of these states for an activity or even a button.

For specific usage, please refer to advanced tutorial 1, 3 and 4

The request filtering

Retry support

Retry of failed requests is also a common requirement, but it is not easy to implement. There are basically two approaches:

• If you do this at the code level, you need to re-initiate the request in the failed callback, and keep track of the number of times, which is cumbersome.
• If you do it at the network layer, you need to wrap the network layer once and provide a method to set the number of retries. However, this approach has great drawbacks and does not relate well to the business. Retry network requests when they fail because the network layer does not know when to retry? Or do you return unsuccessful flags in the content and try again?

The library also provides retry support, because with asynchronous support, retry is a loop for the framework, but the loop is written for you, you just need to tell the framework the number of retries and when to retry.

Ability to set dynamic properties

Single-page application (Testing)

The front-end guys should know what this is, that all rendering is displayed on one page, and page hops are controlled by the front-end route. On the client side, all the UI is displayed in one activity.

What’s the point? The biggest problem with Android plug-ins is that the four components need to be registered in the manifest in advance. Although there are some open source projects that solve this problem through the underlying hook method, it is not clear whether the future version of Android will limit this. Moreover, current plugins require the merging of resources, which reduces the success rate.

Dynamic delivery of bytecode execution is also possible for single-page applications. And the success rate is theoretically close to 100%. I plan to try it sometime.

I mean like the front-end has the ability to update at any time, I don’t know if it will be blocked, escape…

Quick start

Import library

[optional] add java8 support

android {
...
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
...
}
Copy the code

Adding a Maven repository

allprojects {
    repositories {
        ...
        maven { url 'https://jitpack.io' }
    }
}
Copy the code

Add the dependent

Def support_version = '28.0.0 def lifecycle_version =' 1.1.1 'implementation' com. Making. Ittianyu: relight: 0.1.0 from ' implementation "com.android.support:appcompat-v7:$support_version" implementation "com.android.support:design:$support_version" // Support library depends on this lightweight import implementation "android.arch.lifecycle:runtime:$lifecycle_version"Copy the code

If java8 is enabled

// alternately - if using Java8, use the following instead of compiler
implementation "android.arch.lifecycle:common-java8:$lifecycle_version"
Copy the code

confusion

-keep class * extends com.ittianyu.relight.widget.Widget {*; }Copy the code

Introductory tutorial

1. AndroidWidget

2. StatefulWidget

3. TextWidget

4. LinearWidget

5. FrameWidget

6. RelativeWidget

7. setStateAsync

Advanced tutorial

1. LceeWidget

2. UpdateStrategy

3.LceermWidget

4.RmWidget

5.Retryable

6.Cache

7.StartActivity

8.xml

Widgets

As mentioned above, the design idea of this framework is “Everything’s a Widget”. Widgets are atomic controls with life cycle, which are roughly divided into three categories: native, stateful, and stateless.

native

stateful

Control with state.

• StatefulWidget: A base class for all stateful controls, with a lifecycle
• LceeWidget: a widget that encapsulates Loading, Content, Empty, and Error
• RmWidget: a control that encapsulates Refresh and LoadMore common states
• LceermWidget: a widget that encapsulates Loading, Content, Empty, Error, Refresh, and LoadMore

stateless

Asynchronous thread strategy

The framework uses thread pools to perform asynchronous operations. Considering different applications have different requirements, developers can set their own thread pool policies (it is recommended to set them during initialization).

ThreadPool.set(executorService);
Copy the code

. The default is used Executors newCachedThreadPool (), which is a period of time without the asynchronous task, automatic the release of internal threads, meeting the needs of most applications.

Core method call order

Widget

• Render: external through callrenderMethod to get a View and render it
• Update: whenStatefulWidgetPassively triggered when the status changes

StatelessWidget

render(first call) -> build -> widget.render -> initWidget
Copy the code

state

setState -> willUpdate -> update -> didUpdate

onDestroy -> dispose
Copy the code

StatefulWidget

render(first call) -> createState -> state.init -> state.build -> widget.render -> initWidget

state.setState -> state.update -> widget.update
Copy the code

AndroidWidget

Constructor -> createView Render (first call) -> initView -> initEvent -> initDataCopy the code

Lifecycle

render(first call) -> bind lifecycle
Copy the code

onStart
onResume
onPause
onStop
onDestroy
Copy the code

BaseAndroidWidget

Native widget with common View property Settings

initView -> initProps

onStart -> updateProps(when has LayoutParams)
Copy the code

InitView is triggered after Render

ViewGroupWidget

render(first call) -> children.render -> super.render(render self) -> add children to ViewGroup

addChildren -> updateChildrenProps -> updateProps
Copy the code

To Do List

The framework

Based on the control

• FrameWidget
• LinearWidget
• RelativeWidget
• RecyclerWidget
• TextWidget
• ImageWidget
• SwipeRefreshWidget
• ButtonWidget
• ToolBarWidget
• EditWidget
• FloatingActionButtonWidget
• DrawerWidget

Advanced controls

The theme of control

• material

The document

Thank you

Thank Guizhou Chuanqing for your support and help all the time

copyright

Name origin

• rekindle
• Moral: Find hope again
• Message: Life is hard. What I can do is, in your darkest moments, persuade you not to give up hope.
• Conclusion: if you can not understand the message, that you have a very happy, may you never understand. But maybe in the near future, if you do, I hope you’ll remember it.