To develop great applications, we need to understand Ability.

Ability is what

Ability is officially defined as an abstraction of the capabilities of an application and an important part of the application.

It is visible and hosts a business visual interface; Can also be hidden, silently behind you to do dirty work; It can also bridge data access between multiple applications to facilitate data communication.

Hongmeng applications are deployed based on Ability, and developers implement the capabilities required by the application by inheriting Ability classes.

From the perspective of Android API capabilities, the capabilities provided by The Ability of Hongmeng OS include Activity, Service and ContentProvider.

Ability can be divided into Feature and Particle according to whether they can be interacted.

Different types can be subdivided according to their supporting templates:

  1. Feature currently supports only the Page template, which provides the ability to interact with users, including writing view components.
  2. Particle supports the Service template, which provides the ability to run tasks in the background, and the Data template, which provides the ability to access Data externally.

How to use Ability

Only direct inheritance can implement different template capabilities, while subclasses of different template implementations need to actively choose to override corresponding methods.

For example, visual Page templates focus on Page lifecycle changes, so overloaded methods are mainly lifecycle change callback methods.

The Service template is more concerned with connecting and disconnecting services, and the overloaded approach is different from the Page template.

To be honest, such a design is not good. It is obviously friendlier to encapsulate Ability for template classification.

Let’s expand with the visual Page template as an example.

Write a splash screen page

public class SplashScreenAbility extends Ability { @Override public void onStart(Intent intent) { super.onStart(intent);  / / visual images, behind will have when it comes to super setMainRoute (SplashScreenAbilitySlice. Class. GetName ()); }}Copy the code

You can see our overloaded onStart method.

OnStart is only a callback when the system creates the Page for the first time. The following figure shows the state transition of the Page life cycle and the corresponding callback.

The following is a brief description of the core method:

  • onStartTriggered when the system first creates a Page instance. For a Page instance, the callback is triggered only once during its life cycle and then enteredINACTIVEState. The developer must override this method and configure it here as shown by defaultAbilitySlice.
  • onActive, the Page will enterINACTIVEThe state then comes to the foreground, and the system calls this callback. Enter after thisACTIVEState, which is the state of the interaction between the application and the user.
  • onInactiveThe system calls this callback when the Page loses focus, after which the Page entersINACTIVEState.
  • onBackgroundIf the Page is no longer visible to the user, the system calls this callback to notify the developer user to release the appropriate resource, and the Page is enteredBACKGROUNDState.
  • onForeground, in theBACKGROUNDThe Page of the state still resides in memory. When it comes back to the foreground (for example, when the user navigates to the Page again), the onForeground() callback will be called to notify the developer, and the Page’s lifecycle state will returnINACTIVEState. The developer should reapply the resources released in onBackground() in this callback, and the Page’s lifecycle state returns furtherACTIVEStatus, which will be notified to the developer user via the onActive() callback.
  • OnStop, this callback is triggered when the system is about to destroy the Page, notifying the user to release system resources.

Compare the Android Activity lifecycle callback (left over right Android)

onStart() --> onCreate() onActive() --> onResume() onInactive() --> onPause() onBackground() --> onStop() onForeground()  --> onRestart() onStop() --> onDestroy()Copy the code

The life-cycle callbacks do look a lot like Activity scenarios, but there are some differences in the view authoring flow.

The SplashScreenAbilitySlice shown in the example code is actually the class that hosts the view logic.

It inherits from the AbilitySlice class and navigates to the real view interface via the supe#setMainRoute method.

So what is AbilitySlice?

AbilitySlice is officially defined as a Page unit and its life cycle depends on the Page life cycle of which it belongs.

AbilitySlice has the same life cycle state and callback of the same name as Page, and its AbilitySlice has the same life cycle change when the Page life cycle changes.

| - AbilityContext | | - Ability | | - AbilitySlice / / Page elementsCopy the code

Both inherit from AbilityContext and implement it in much the same way.

AbilitySlice has more lifecycle changes than a Page. These changes occur when multiple AbilitySlice in the same Page are navigated, but the Page lifecycle status does not change.

AbilitySlice is similar to a Fragment, except that a Page must be set to display a Page view.

Here is a simple implementation of SplashScreenAbilitySlice.

public class SplashScreenAbilitySlice extends AbilitySlice { @Override public void onStart(Intent intent) { super.onStart(intent); super.setUIContent(ResourceTable.Layout_splash_screen_layout); }}Copy the code

The above code sets up the layout by calling setUIContent.

Demo to achieve a complete flash screen logic, the effect is as follows, interested in Github to view the implementation.

For Service templates and Data templates, you can simply override the corresponding methods. This section is not described at this time, but details can be found in the HarmonyOS Developer development documentation.

Since Ability divides multiple templates, how does an app differentiate between them?

Differentiated Ability template

In Harmony, we explained that there is a config.json configuration file for each module.

The module node of this file should declare the Ability required by the application.

"abilities": [
  {
    "orientation": "portrait",
    "name": "com.effective.harmony.study.ability.page.SplashScreenAbility",
    "type": "page",
  },
  {
    "name": "com.effective.harmony.study.ability.service.ServiceAbility",
    "type": "service",
  }
]
Copy the code

Perform SplashScreenAbility as a Page template and ServiceAbility as a Service template.

This is consistent with the four component logic that androidmanifest.xml requires in Android applications.

Although the official SDK source code is not open source, but in the Framework layer should be the corresponding type of classification, and do method mapping calls in their respective template scenarios.

I’m more curious about the implementation of the Framework layer.

Unfortunately, the SDK is currently not open source and the API is not commented.

Next time we’ll talk about event distribution.

Welcome to the Android Zen account to share valuable and thoughtful technical articles with you. Can add wechat “Ming_Lyan” remarks “into the group” to join the technical exchange group, discussion of technical problems is strictly prohibited all advertising irrigation. If you have technical problems in the Android field or have doubts about your future career plan, discuss with us. Welcome to the party.