Super Bright FlashLight shows a simple demo of controlling flashlight on OpenHarmony
device.
This documentation also listed all the problems or noticeable thing during the app development.
Problems encountered during development
This part introduces the general process of the application development
- UI design and implement
- Logic and functionailities
- Check and testing
- App display and acceptance
- Add all necessary files
- Merge to applist and finish
• Provide a simple UI page with a slider. When we slide the bar to the top direction, the flashlight will goes brighter, vice versa.
• When we slide the bar, an `Off` button will pop up, click this button will reset the slider and turn off the flashlight.
-
Take the example of
Super Bright FlashLight
, we are aiming to design the app with user-friendly interface. Comunicate with UI/UX colleague and got the basic construction idea. -
After that, start to build the UI part, my idea is to construct the UI with very simple containers(Like placing columns/rows with a different color to make a general position layout)
-
Then, start to replce each component with the containers
In my case I need to place a flashlight image as background, and a
fragemented slider
to control the flashlight's brightness, so chooseStack
as the basic container.
- After basic logic constrcution we can start to write the logic part.
Note
There is some basic logic code within UI part, general it's inside the callback function of someUser-interacting Component like Button(), Slider(), TextInput() and etc.
- The
User-interacting UI component
can control the UI variables which defined inside the struct.
@Entry
@Component
struct Index{
@State isOn: boolean = false
build(){
Button('Click')
.onClick(()=>{
this.isOn = this.isOn ? true : false
})
}
}
Note
We need to define the UI state variable withinstruct
, and to update it incallback
functions.
Start fullfilling the callback function with some basic
console.info()
about the operation, then add the more concrete logic afterwords.
-
For most of other logic like
flashlight api calls
create another folder undersrc/main/ets
maybe name it asApi
-
Using
import and export
to pass the logic function between UI.
// ets/Api
// Get camera manager instance
export default function getCameraManager(context: common.BaseContext): camera.CameraManager | undefined {
let cameraManager: camera.CameraManager | undefined = undefined;
try {
cameraManager = camera.getCameraManager(context);
} catch (error) {
let err = error as BusinessError;
console.error(`The getCameraManager call failed. error code: ${err.code}`);
}
return cameraManager;
}
//Your UI page
import getCameraManager from './Api'
@Entry
@Component
struct index{
private cameraManager: camera.CameraManager = getCameraManager(getContext(this)) as camera.CameraManager
build(){
}
}
Note
In such case you can call theGetCameraManager
function from yourApi
folder.
- I use console/hilog to check the program works fine or not. Most of the UI part can be tested in
Previewer
, some functionailities can be tested inEmulator
likeApp Stages, Web component, http interaction
, and some functionailities can be tested only on real development board likeCamera, flashlight
which exists only on real device.
After connecting OpenHarmony
board, it shows no device
on Deveco Studio. But in the terminal type hdc list targets
it shows the connected device series number.
Solution: Reinstall pervious same Deveco studio version and run the sync again.
After concrete debugging and checking, it's still the device problem. So for this application I keep only simple demo with UI functionalities.
Update information
I tested the api with HarmonyOS device and it worked, so I keep these functionailities and attached to the button.
CONTENT TO BE ADDED
- Add LICENSE file
We can add the
LICENSE
via here.
CONTENT TO BE ADDED
In order to test the project on emulator we need to install Deveco Studio 5.0, since the system-image through our welink resource is HarmonyOS
device, we can't simply deploy our OpenHarmony project on it.
Therefore, we need to change a bit of OpenHarmony
project to make it working.
in build-profile.json
file, comment on the OpenHarmony
products configuration, replace it when HarmonyOS
products configuration shown as follows.
"products": [
{
"name": "default",
"signingConfig": "default",
"compatibleSdkVersion": "4.1.0(11)",
"runtimeOS": "HarmonyOS",
"buildOption": {
"strictMode": {
"caseSensitiveCheck": true,
}
}
}
],
// "products": [
// {
// "name": "default",
// "signingConfig": "default",
// "compileSdkVersion": 11,
// "compatibleSdkVersion": 11,
// "runtimeOS": "OpenHarmony",
// }
// ],
https://www.cnblogs.com/changyiqiang/p/17954322
Then after the testing is done, we want the project run under OpenHarmony
environment again.
in build-profile.json
file, uncomment the OpenHarmony
products configuration, comment the HarmonyOS
products configuration shown as follows.
// "products": [
// {
// "name": "default",
// "signingConfig": "default",
// "compatibleSdkVersion": "4.1.0(11)",
// "runtimeOS": "HarmonyOS",
// "buildOption": {
// "strictMode": {
// "caseSensitiveCheck": true,
// }
// }
// }
// ],
"products": [
{
"name": "default",
"signingConfig": "default",
"compileSdkVersion": 11,
"compatibleSdkVersion": 11,
"runtimeOS": "OpenHarmony",
}
],
Then under the route hvigor\hvigor-profile.json5
, altering
the version and dependencies back as follows
Since it's version was too high
"hvigorVersion": "3.2.4",
"dependencies": {
"@ohos/hvigor-ohos-plugin": "3.2.4"
},
After that, run the sync
operation again, the project should be working now.