Foreword
this project API>= 13
in the article "Hongmeng Development: Project Initialization and Construction of Information Project Actual Combat", there is a problem left over, that is, how to realize the independent operation of each module. In fact, three articles have been written before about the independent operation of each module of componentization, which respectively discusses the difference between running package and shared package. nodeJs script implements componentization and hvigor plug-in forms componentization. However, the time has passed for a long time, the previous method is no longer been common, because the new API update iteration is too fast, API19 has arrived unconsciously. Since this year, 6 versions have been updated. The official speed is like a rocket, and the realization cannot catch up!
Because the Api has changed and the project structure created in the new IDE has also changed imperceptibly, the plug-ins and scripts developed before cannot be used any more. There is no way but to upgrade them.
In the same order as before, we analyzed the differences between basic running packages and shared packages, and then started to use scripts or plug-ins to help us quickly switch componentized running packages, this article focuses on an overview of the manual implementation of common modules (shared packages) to run.
Run and share packages
what is a run package? What is a Shared Package? Take our information project as an example, the entry module is the running package, which we can run directly on the device and display correctly. Other modules are shared packages and cannot be run separately on the device for correct display. In a word, the module that can run independently on the device and can be displayed correctly is the running package.
One thing needs to be clear here, that is, there can only be one running package in a project. Even if we modify other modules to be runnable later, we must modify the original running package to be non-runnable.
How to change a shared package into a running package, the premise needs to compare the differences between the two, according to the differences, in order to facilitate subsequent modifications.
Difference between the two
we mainly compare the main module entry with an ordinary shared package. In the new API, the difference is not very big, and the difference is basically the same. At present, there are the following differences. Here we only analyze dynamic shared packages, and static shared packages are actually similar.
1. hvigorfile.ts is different
main module (entry, runable)
import { hapTasks } from '@ohos/hvigor-ohos-plugin';
export default {
system: hapTasks, /* Built-in plugin of Hvigor. It cannot be modified. */
plugins:[] /* Custom plugin to extend the functionality of Hvigor. */
}
normal module (shared package, not runable)
import { hspTasks } from '@ohos/hvigor-ohos-plugin';
export default {
system: hspTasks, /* Built-in plugin of Hvigor. It cannot be modified. */
plugins:[] /* Custom plugin to extend the functionality of Hvigor. */
}
the above differences are: hapTasks is used in the main module and hspTasks is used in the common module.
2. module.json5 is different
main module (entry, runable)
{
"module": {
"name": "entry",
"type": "entry",
"description": "$string:module_desc",
"mainElement": "EntryAbility",
"deviceTypes": [
"phone",
"tablet",
"2in1"
],
"deliveryWithInstall": true,
"installationFree": false,
"pages": "$profile:main_pages",
"abilities": [
{
"name": "EntryAbility",
"srcEntry": "./ets/entryability/EntryAbility.ets",
"description": "$string:EntryAbility_desc",
"icon": "$media:layered_image",
"label": "$string:EntryAbility_label",
"startWindowIcon": "$media:startIcon",
"startWindowBackground": "$color:start_window_background",
"exported": true,
"skills": [
{
"entities": [
"entity.system.home"
],
"actions": [
"action.system.home"
]
}
]
}
],
"extensionAbilities": [
{
"name": "EntryBackupAbility",
"srcEntry": "./ets/entrybackupability/EntryBackupAbility.ets",
"type": "backup",
"exported": false,
"metadata": [
{
"name": "ohos.extension.backup",
"resource": "$profile:backup_config"
}
],
}
]
}
}
normal module (shared package, not runable)
{
"module": {
"name": "home",
"type": "shared",
"description": "$string:shared_desc",
"deviceTypes": [
"phone",
"tablet",
"2in1"
],
"deliveryWithInstall": true,
"pages": "$profile:main_pages"
}
}
the difference in module.json5 is quite large, not only the difference in type type, but also the configuration attributes in a shared package are missing many attributes compared with the main module, such as abilities,extensionAbilities, etc.
3. Lack of ability
in fact, in we have seen this difference in module. Json5. There are two more in the main module.Ability, one is EntryAbility, and the other is EntryBackupAbility. Although the default class that comes with EntryBackupAbility is used for application access data backup and recovery, we delete it and it will not affect our application development.
4-Lack of Resources
shared and run packages, in in the difference between module.json5, there are also some missing resources, such as icon icon, background color, etc.
Implement Shared Package Run
for an ordinary module to run, we only need to modify it according to the above differences to achieve the separate operation effect of the component. After the change, we need to pay attention to two points: first, clear the cache, clear the previous configuration information, and second, set the startup Ability.
In addition to its own modules need to be changed, it is also necessary to modify the previous running module to a shared module, otherwise it cannot be run alone, that is, follow, shared package changed to run package, run package changed to shared package .
The main change is to exchange codes with each other to make up for resource information. For example, the changes to the shared package are as follows:
hvigorfile.ts is changed to the same as the main module:
the module.json5 is also changed to be the same as the main module and requires two abilities.
Then there is the need to copy the resource information:
Similarly, the main module is also changed according to the configuration in the shared package. After the two are changed to each other, the separate modules can run independently. For example, the home module in the information project can be changed to the home module. After clicking Run, the effect is as follows:
related Summary
the purpose of componentized running is to reduce compilation time and improve the efficiency of running tests, after all, the running time of a module is certainly much less than the running time of the entire project.
In this article, we mainly analyze the differences between running packages and shared packages, and understand the differences so that we can manually run shared packages.
Manual is only to let everyone understand the principle of switching. In actual development, manual is not recommend. In the next article, we will quickly switch between componentized modules through scripts or plug-ins to realize independent operation. Please look forward to it!
This article label: Hongmeng News Information Application
Top comments (0)