HarmonyOS一杯冰咖啡 —— MVVM? 一、引言 最近看到一个项目的架构设计，刚开始看还有点懵，但仔细想了想，其实它还挺有意思的。它用了一个混合型架构，表面看像 MVVM，实际上中间加了一层

首先我们来看一下一个正常的权限请求流程 通常来说请求权限附带很多重复的模版代码，这个无疑会给我们带来很多不必要的工作。我们来看一个官方的示例（当前不感兴趣的可以直接跳过去）。 上面的示例是不是又长又臭

鸿蒙原生应用 开发项目实战：音乐播放器 介绍 本项目旨在开发一个基于鸿蒙系统的音乐播放器应用，具备如下功能： 实现本地音乐文件播放。 支持播放列表管理。 音量控制。 播放进度拖动。 自定义 Notif

客户端同学对app权限申请应该不陌生，鸿蒙系统中的权限管理有一个非常响亮帅气的名字：ATM ATM (AccessTokenManager) 是HarmonyOS上基于AccessToken构建

前言 在移动端下拉刷新和上拉加载属于高频使用的功能，目前官方提供的Refresh组件自定义效果有限，很难满足各家产品个性化定制的要求。下面我们从0到1打造一个无入侵性、可自定义扩展的下拉刷新组件

ECharts作为前端强大的图表、K线、地图等封装库可以说无比风骚。但用户和产品的需求永远是一个库满足不了的，除非产品和设计的基础是在图表库基础上进行。我们前端移动端作为产品的排面就应该让其独具特色,

前言 鸿蒙应用使用ArkTS进行开发，ArtTS是基于TS进行扩展，添加一些类型限制，TS只是给JS添加了静态类型系统，最终编译完成的JS其实是把类型去掉了的 前端JS发展这么多年积累了很多非常好用的

封装HarmonyOS网络库，支持将返回数据直接转换成指定泛型对象。简化调用方式，基于面向对象式思想封装。

在鸿蒙开发中实现自定义弹窗交互（@CustomDialog），对于解耦封装却有很大的限制。本篇介绍实战过程中的解耦对策。