π Best Practice Case Revealed! The Developer's Hidden Treasure Handbook
Hello everyone! While browsing the HarmonyOS documentation today, I stumbled upon an amazing treasureβthe official site has quietly releaseddozens of super practical development cases, covering core scenarios like foldable screen adaptation, performance optimization, UI frameworks, and cross-device collaboration! These cases are hidden deep in the docs, but they're real "productivity tools." Let's dig in together!
π₯ Why is this a treasure?
The official "Best Practices" documentation (Path: Developer Website > Docs > Best Practices) hides some secrets:
- Full Scenario Coverage: From foldable screen hover interaction to PC cross-end collaboration, from memory optimization to animation smoothness
- Real Code Snippets: Each case comes withcore code that can be directly reused
- Pitfall Avoidance Guide: Solutions for common development issues (like crease avoidance, portrait/landscape breakage)
- Design + Code Dual Tutorials: Even UX guidelines are provided
Let's focus on a few hardcore cases belowπ
π Treasure Case Practical Analysis
Case 1: Foldable Screen Hover State Development (Video Playback Scenario)
Pain Point: Operation area covers content during foldable screen hover state
Official Solution:
- Use
**<font style="color:rgba(0, 0, 0, 0.9);background-color:rgb(252, 252, 252);">FolderStack</font>**
componentto automatically split the upper and lower screens - The crease area is dynamically avoided using
**<font style="color:rgba(0, 0, 0, 0.9);background-color:rgb(252, 252, 252);">getCurrentFoldCreaseRegion()</font>**
API
// Hover state upper and lower screen split + crease avoidance
FolderStack({ upperItems: ["videoPlayer"] }) {
// Upper screen: video player (automatically avoids crease)
Column() {
VideoPlayer()
}.id("videoPlayer")
// Lower screen: control panel
Column() {
PlaybackControls()
}
}
.onFolderStateChange((state) => {
// Automatically adjust layout when hover state changes
if (state.isHalfFolded) console.log("Entered hover mode!")
})
Key Tips:
-
<font style="color:rgba(0, 0, 0, 0.9);background-color:rgb(252, 252, 252);">upperItems</font>
specifies the upper screen component ID - The system automatically handles crease avoidance
- Real-time callback for hover state changes
π Effect Comparison: Without adaptation, the control buttons are covered by the crease; after adaptation, the control area sinks and the video moves up, resulting in a smooth experience!
Case 2: Responsive Font Adaptation (Multi-device Compatibility)
Pain Point: Text is too large/small after unfolding the foldable screen
Official Solution:Breakpoint system + rem responsive units
/* Dynamically calculate font size based on screen width */
:root {
font-size: calc(16px + 0.2 * (100vw - 320px) / 880);
}
@media (min-width: 1280px) {
/* Large screen specific styles */
.title { font-size: 1.8rem; }
}
Core Principle:
- Breakpoint Thresholds: Four screen width levels: 320px/600px/840px/1280px
- rem Dynamic Calculation: Font size smoothly scales with screen width
- Media Query Fine-tuning: Extra layout optimization for large screens
π‘ Test Data: The same text displays at 12px in folded state (width 375px) and 14.5px in unfolded state (width 840px), which matches comfortable reading standards!
Case 3: Seamless Portrait-Landscape Switching (Video Fullscreen Scenario)
Pain Point: Square screen devices (like Mate X) rotate unnecessarily during fullscreen playback
High-tech Solution:Vertical breakpoint detection + forced landscape
// Determine if it's nearly a 1:1 square screen (vertical breakpoint)
const aspectRatio = window.height / window.width
if (aspectRatio >= 0.8 && aspectRatio <= 1.2) {
// Lock to landscape orientation
window.setPreferredOrientation(Orientation.LANDSCAPE)
}
Advantages:
- Avoids users frequently rotating the device
- Keeps video content maximized
- Adapts to special ratio devices like Mate X/Pad
π οΈ More Practical Tips
- Multi-window Adaptation
// Split-screen mode listener
window.on("splitScreenChange", (mode) => {
if (mode === SplitScreenMode.SPLIT_HORIZONTAL) {
adjustLayoutForHorizontalSplit()
}
})
- Fold State Awareness
// Real-time fold state detection
display.on("foldStatusChange", (status) => {
if (status === FoldStatus.HALF_FOLDED) {
showHoverModeUI()
}
})
- One-to-many Layout Secret
/* Phone single column β Tablet dual column */
@media (width > 600px) {
.news-list {
grid-template-columns: 1fr 1fr;
}
}
π Why Should Developers Read These Cases?
- Directly Solve Business Pain Points: For example, image zoom limits in e-commerce apps, hover control bars in video apps
- Save Trial-and-error Costs: Officially validated solutions help you avoid pitfalls
- Built-in Design Guidelines: UX standards are directly integrated into the code logic
- Cross-device Coverage: One set of code is compatible with phones/foldables/tablets/PCs
β οΈ Pitfall Reminder:
Never use <font style="color:rgba(0, 0, 0, 0.4);background-color:rgb(252, 252, 252);">deviceInfo.deviceType</font>
to determine foldable screens!
The correct way is to <font style="color:rgba(0, 0, 0, 0.4);background-color:rgb(252, 252, 252);">display.on("foldDisplayModeChange")</font>
listen for screen changes!
π― Conclusion: Stop Reinventing the Wheel!
These cases hidden in the documentation are simply the "Swiss Army Knife" of HarmonyOS development. Especially the foldable screen development section, from basic layouts to hover interactions, even performance optimization parameters are tuned for you. I recommend searching the official site for "Best Practices" β "Foldable Screen Development Practice", it will save you at least 50% of development time!
Finally, a question for you: What is the most troublesome issue you've encountered when developing foldable screen apps? Let's discuss in the comments~ π
Top comments (0)