Domestic operating system hongmeng code finally open source, IDE is also open. I can’t wait to install the IDE and taste it.
This article will describe my own development experience in terms of hongmeng OS introduction, IDE introduction, installation and operation, project composition, APP basic components, and APP executable files.
HarmonyOS background
Microkernel-based cross-platform distributed operating system, latest 2.0. No longer on powerpoint, the source code and IDE are exposed.
I’ll list the official information.
-
The official introduction of Hongmon OS
-
Gitee home page for Hung Mon OS
-
Kernel source address
-
Huawei Developer Forum
IDE DevEco Studio
The IDE developed for Hongmon OS is called DevEco Studio and is based on the IntelliJ IDEA Community open source version. The interface and development process are basically the same as Android Studio and easy to use.
-
HUAWEI DevEco Studio
-
Official document
DevEco Studio up and running
After downloading the EXE, double-click it to see the configuration page.
Select another installation directory or the default option, and go to the startup page.
After about 10 minutes, you will be prompted to download the SDK. Select “Accept” to continue.
After the download is successful, you will enter the Create Project screen. Select “Create Hongmon OS Project” to continue.
Next, you need to choose the type of hardware device to run. Currently, three types of devices are supported: TV, watch and wearable device. You can see the preset layout of the screen, as well as the development language, currently supports JS and JAVA two development languages. We select the “TV” device, empty screen +JAVA development mode, and continue.
Of course, we need to set the project name, package name and location information, so we continue with the name “HMApp”.
After configuration, you will enter the IDE main interface and automatically download Gradle and other dependency packages.
After gradle is downloaded and configured, we install the Hongmon OS emulator. There is no local emulator for the time being. We can only use the remote emulator, which requires downloading the Resources module and logging in to the website.
Clicking Tools->HVD Manager will automatically download the Resources module when it opens the emulator device list.
It should be mentioned here that downloading the Resources module is very easy to encounter the following failures, which many developers have encountered.
There are many solutions, none that are particularly sound. For example, restart the computer, restart the IDE, reinstall the IDE, delete the IDE cache directory, try huawei developer account 10 minutes after successful registration, and so on. After all, a few tries will eventually succeed.
After the download succeeds, you need to log in to the Huawei developer account to start the remote emulator. The IDE will launch the default browser authentication account itself. After the login is successful, you need to “Allow”, and a message is displayed indicating that the login is successful.
After this we return to the IDE and will see the “Login Success” prompt at the bottom. We can then start the emulator from the HVD Manager list.
We then run our code and see that we have successfully deployed to the remote emulator.
Hongmeng APP project composition
Let’s take a look at the hongmeng APP project composition and compare it to Android Studio.
Through careful comparison, it is found that the structure is roughly similar, and there are detailed differences in the main code logic module.
- DevEco changed the configuration manifest format from XML to JSON, which may be more efficient to parse.
- The resource files are classified into the Media directory for storing media resources, the Element directory for storing character content, and the RawFile directory for storing default resources. Compared to Android’s native resource directory classification more concise. Just resource file size adaptation, version adaptation, international adaptation need how to distinguish?
- The implementation classes of several major components in the source file have been changed. The names look similar to each other.
Hongmeng API design and comparison with ANDROID
Official API description
To understand the difference between the basic APP components and Android, we need to look at the source code implementation. I have posted a summary of the class diagram of the Hongmon OS APP component.
The class diagrams for Android’s native Applications, activities, and services are also attached.
The Ability, AbilitySlice, and AbilityPackage components are inherited from the same parent class, AbilityContext. And Context is not like Android, it’s an interface.
To summarize the differences in the specific method apis, the initial impression is this (see the larger version better).
As you can see, most of the apis are similar, except for the nuances in the names, which indicate that the components are designed in much the same way. But we’ve also seen some apis on Hongmon OS that don’t exist on Android.
-
For example, Ability provides stopAbility() to stopAbility, setSwipeToDismiss() to enable or disable sideswipe, and setMainRoute() to the main entry of the route to specify which AbilitySlide instance was started first.
-
AbilitySlice, for example, provides startAbility(), stopAbility(), and getAbility() for starting, stopping, and getting instances of Ability, as well as setUIContent() for setting UI views.
AbilitySlice can directly display views, and Android services can not directly display views, you need to rely on Windows Manager to add Windows.
AbilitySlice is not the same as Android Service, it is only a supplement to the Ability UI display, a part of it, more like Fragment. The comparison dimension in the above table is not accurate. Therefore, AbilitySlice and Service cannot be directly compared.
We also found a detail that both Ability and AbilitySlice provide onOrientationChanged(), which listens for screen direction changes, in addition to onConfigurationUpdated(). Why screen orientation changes should be treated separately is more subtle.
What this table doesn’t show is that Both Ability and AbilitySlice provide connectAbility(Intent Intent, IAbilityConnection conn) and disconnectAbility(IAbilityConnection conn) are unbound and unbound. But only Ability provides onConnect(Intent Intent) and onDisconnect(Intent Intent) to handle binding and unbinding callbacks.
It is known that AbilitySlice can also participate in binding components, but only its attached Ability can handle binding and unbinding callbacks. This is completely different from Android, where activities unbind and unbind services using bindService() and unbindService(). Services provide onBind() and onUnbind() to handle binding and unbinding requests.
The paper
On Android, activities and services are two different concepts. Activities provide the UI for interacting with users, while services provide the execution of background tasks. Activities can start and stop services, as well as bind, remotely schedule and unbind services. Their implementation classes are also separate.
Hongmeng OS, on the other hand, integrates activities and services as abstract “capabilities” managed by the implementation class Ability. When you need to show UI interactions, it’s an activity; It’s a service if you need to perform background tasks. Of course, because of Ability, the service has the convenience of directly presenting the UI when it needs to interact.
It is important to point out that while it is a good idea to integrate front desk activities with back office services, many concepts can be confused and lead to lifecycle management chaos. It is also easy to make mistakes during development. This is especially true for Android developers who are used to the concept of activities and services.
What is the executable program of Hongmeng APP?
Hongmon OS compilers the application in hap format, which stands for Harmony Application Package? And APK is also a compressed package, renamed after decompression, as shown in figure. There is an APK file with the same name…
And Android APK content DIFF.
We then decompress the APK file and general APK comparison, the structure and name are exactly the same.
HAP file built-in APK file is of course compatible with Android system, to facilitate the construction of system ecology. How exactly compatible? I suppose there are two possibilities.
- The underlying hongmon OS is still like Android, temporarily parsing and installing APK files via PMS and PackageInstaller. So the APK file is built-in, and the external JSON is just additional configuration and complement.
- Hongmon OS completely has its own HAP format parsing and installation process. The built-in APK in HAP is designed to make it easy for HAP to install and run on Android OS. This makes it easier for Hongmeng developers to develop apps that run directly on Android devices without changing the code. For example, when HMS App Gallery distributes HAP format to the phone, it can automatically extract APK to the phone, and then execute the same process as APK.
This is only my guess, welcome to discuss ~
From the perspective of IDE installation and usage, there are still many areas that need to be optimized. For example, you need to log in every time you start HVD, for example, the logs of running your APP are not coming out, for example, there is no local emulator, and so on.
Rome wasn’t built in a day, we need to stay positive to try and give feedback and give huawei developers some time. That’s how we can keep moving forward.
wish
Hongmeng OS’s IDE, component design, and executable composition are both similar and different to Android. This kind of way can not only take advantage of the ecological construction, but also establish their own style, but there is a stubborn.
It is impossible to judge which is better than the other; it is up to time and the user.
At the moment I just want to wish Hongmeng OS better and better!