Visual mode adaptation (DarkMode) of seven weapons

As we introduce AppCompat-v7 and have AppCompatActivity available, We find that the TextView/Button components we render become AppCompatTextView and AppCompatButton respectively. Similarly, we can set up our own LayoutInflaterFactory using LayoutInflaterCompat. Then, following Google's lead, we turn native controls in XML into our own custom controls.

// We can emulate Lollipop's android:theme attribute propagating down the view hierarchy // by using the parent's context if (inheritContext & & parent ! = null) { context = parent.getContext(); } if (readAndroidTheme || readAppTheme) { // We then apply the theme on the context, if specified context = themifyContext(context, attrs, readAndroidTheme, readAppTheme); } if (wrapContext) { context = TintContextWrapper.wrap(context); } View view = null; // We need to 'inject' our tint aware Views in place of the standard framework versions switch (name) { case " TextView" : //view = new AppCompatTextView(context, attrs); view = new SkinnableTextView(context, attrs); // view break; case " ImageView" : view = new AppCompatImageView(context, attrs); break; . } if (view == null & & originalContext ! = context) { // If the original context does not equal our themed context, then we need to manually // inflate it using the name so that android:theme takes effect. view = createViewFromTag(context, name, attrs); } if (view ! = null) { // If we have created a view, check it's android:onClick checkOnClickListener(view, attrs); } return view;Copy the code

} " data-snippet-id="ext.31d55951ca97c8a347768df7cc13bc38" data-snippet-saved="false" data-codota-status="done"> public final View createView(View parent, final String name, @NonNull Context context, @NonNull AttributeSet attrs, boolean inheritContext, boolean readAndroidTheme, boolean readAppTheme, boolean wrapContext) { final Context originalContext = context; // We can emulate Lollipop's android:theme attribute propagating down the view hierarchy // by using the parent's context if (inheritContext && parent ! = null) { context = parent.getContext(); } if (readAndroidTheme || readAppTheme) { // We then apply the theme on the context, if specified context = themifyContext(context, attrs, readAndroidTheme, readAppTheme); } if (wrapContext) { context = TintContextWrapper.wrap(context); } View view = null; // We need to 'inject' our tint aware Views in place of the standard framework versions switch (name) { case "TextView": //view = new AppCompatTextView(context, attrs); view = new SkinnableTextView(context, attrs); // view break; case "ImageView": view = new AppCompatImageView(context, attrs); break; . } if (view == null && originalContext ! = context) { // If the original context does not equal our themed context, then we need to manually // inflate it using the name so that android:theme takes effect. view = createViewFromTag(context, name, attrs); } if (view ! = null) { // If we have created a view, check it's android:onClick checkOnClickListener(view, attrs); } return view; }

The setDayNightMode function is called every time Skinnable is needed, which notifies all objects in the View hierarchy that implement the Skinnable interface. Call their applyDayNight method to switch their styles. When the View is generated, we record some resource ids referenced by it. After the UiMode is switched, the real resources obtained by the same resource ID have different characteristics to complete the night mode switching scheme. Css-like view control scheme The server delivers a CSS-like style sheet. Key is defined by the client, corresponds to a property of a view of a type on the client, and value is a style value. At render time, the client reads the style values according to predefined rules. The key to this approach is whether the read-set process is centralized or whether each view needs to be controlled by itself. It depends on the level of protocol design, and it also determines the cost of development. We will introduce this in detail in the later part of Youku practice. The server delivers the desired mode by setting different parameters through the switch. The component developer treats this mode as a normal parameter and renders different parameters. This puts all the work into component development. The design is the simplest.

At the end, there are a number of schemes to implement mode switching, which are not superior or inferior, depending on business requirements and technology ecology. For example, there are pain points that need to make concrete Activtiy in the scheme of switching theme or UIMode, and the way resource IDS are mapped needs to modify the usual way of obtaining resources, and imitate CSS Settings as custom views of code or ways of implementing specific interfaces. Although there are great flexibility and generality, Each component needs to be modified, which is terrible for the workload of super App.

Specifically, DarkMode is an adaptation of a visual mode defined by the system. The system does some preliminary work for it, which makes the DesignToken solution simple and efficient. At Youku, combining the DesignToken system with the existing skin change solution, you can cover most scenarios, and only need to check some details. In addition, DarkMode switching is a system behavior in the latest system version, and should be actively triggered by the user in the lower system version, so there seems to be no need for server control.