暂时未有相关云产品技术能力~
一个北漂的全栈二流程序员。
如果你是新写的项目,建议直接上手V2装饰器,即便是已经存在的项目,对于新的模块,也是尽量以V2为主。
在实际的开发中,如果自带的分割线能够满足我们的需求,以自身的分割线属性为主,如果不满足,我们可以使用组件进行绘制。
关于占满剩余的空间,如果权重能够解决,还是以权重为主,因为Blank的使用必须父组件的宽高有值,否则就会不生效,当然了,在实际的开发中,还是具体问题具体分析,使用恰当的方式解决为主。
关于rcp的拦截器问题,最重要的就是会话复用的时候,如果Request对象中有需要的参数,就直接用Request中的,而不是使用session中的。
总体来说,问题倒不是很大,解决起来也不是很麻烦,所以啊,老铁们,在实际的开发中,对于一些官方文档,还是建议多看,这样可以提前避免后续的不必要麻烦。
本小结主要简单介绍了ArkTs语言的相关知识,都是一些概念性质的内容,大家作为一个了解即可
关于权限,算上本章内容已经阐述了四个章节了,从相关的概念到,权限管理的授权方式,再到申请权限,直至最后的权限工具类封装,基本上涵盖了七七八八,希望可以帮助到大家。
字符串类型是开发中非常重要的一个数据类型,除了上述的方法概述之外,还有String对象,正则等其他的用处,我们放到以后得篇章中讲述。
最后一点是,ArkTS不支持any和unknown类型,需要显式指定具体类型,否则会报异常,具体原因是,这是ArkTS的特性之一,那就是使用静态类型;如果程序采用静态类型,即所有类型在编译时都是已知的,那么开发者就能够容易理解代码中使用了哪些数据结构。同时,由于所有类型在程序实际运行前都是已知的,编译器可以提前验证代码的正确性,从而可以减少运行时的类型检查,有助于提升性能。
还是那句话,在申请权限的时候,应当严格遵循最小权限原则,结合动态申请和清晰的用户引导,避免给用户带来不好体验,同样,遵循,在使用到权限的时候再去申请,切记,过前进行申请。
在实际的应用开发中,合理选择 system_grant和user_grant是平衡功能实现与用户隐私的关键,system_grant 适用于基础功能,简化开发流程;user_grant 用于敏感操作,需重视用户体验和隐私合规。
变量是一种用于存储数据的容器,并且其存储的数据值可以在程序执行过程中被改变,变量通常有一个名字(标识符),用于在程序中引用它。
针对初学者而言,大家只需要掌握住日志打印即可,等到了鸿蒙应用开发的时候,还有一个鸿蒙原生的打印工具HiLog,到时,我们也会详细的去讲述,也会针对HiLog,封装一个通用的工具类。
关于注释,有一点需要注意,那就是,注释,不会被编译器或解释器执行,而本小节的重点并不是简单的教大家注释如何去写,而是在实际的项目中,我们能够真正的把注释投入到实际的开发中。
本文,主要简单概述了为什么要有权限管理,以及权限管理的声明原则,这些都是基本的概念内容,大家做为了解即可,重要的是怎么声明权限,在什么位置声明权限,这一点需要掌握。
在实际的开发中,如果有共用的资源,建议大家都放到AppScope目录下,对于一些应用级别的信息,比如应用的名字,还有应用的图标,虽然说在Moulde下也可以配置,但是为了更方便的管理,这里比较推荐以AppScope目录下的app.json5为主,当然了,只是推荐,实际当中,两者都可以实现,大家选择其中一种方式即可。
如果整个项目的toast样式都一样,直接在初始化中设置统一的属性即可,针对单独不一样的效果,可以单独设置。
这样的一个模版,可以简单的分为,三个部分,分别是上边的搜索框,中间的历史搜索和下边的热门搜索,搜索框,我们直接可以使用系统的组件Search,历史搜索,由于是内容不一的搜索的内容,这里使用弹性布局Flex,下边的热门搜索,条目规格一致,这里我们直接使用Grid网格组件。
具体的效果,根据业务情况而定,有两种模式,一种主动的流式输出,也就是数据以流式的形式进行返回,前端直接用组件加载即可,第二种就是刻意的流式展示,也就是在拿到数据之后,前端实现流式输出,进行打字机展示。
本文,主要简单了介绍了一下,非UI使用的情况下,wrapBuilder传递数据问题,除了以上的方式之外,还有其它的方式可以实现,在实际的开发中,还是具体问题具体分析。
在实际的开发中,需要掌握主轴与交叉轴的关系、换行规则及子元素属性,同时注意性能与兼容性问题,还有一点,Flex组件在渲染时存在二次布局过程,因此在对性能有严格要求的场景下建议使用Column、Row代替。
当然了,RelativeContainer组件还有着其它的属性,但是最重要的也就是位置的摆放,其实也就是相对于锚点组件的摆放;通过上述的案例,我们不难发现,所谓的左上右下,反着来就是对的,比如在锚点上边,我用bottom,在锚点下面,我用top,在实际的开发中,可极大节约我们的开发时间。
首先第一点,在同一个UI组件内,同一个wrapBuilder只能初始化一次,第二点就是WrappedBuilder对象的builder属性方法只能在struct内部使用。
正确的运用AOP,可以提升代码的模块化、复用性、可维护性和灵活性,同时降低了耦合度,使系统更易于扩展和维护。
@Require装饰器依赖ArkTs的类型检查,仅在编译阶段拦截类型错误和缺失参数,对于运行时才能确定的动态值,如从网络请求获取的数据,仍需在生命周期函数中进行二次校验。
@Once装饰器只能与@Param搭配使用,仅此一个组合,无其他使用方式,还有就是,必须在V2版本,也就是@ComponentV2装饰的自定义组件中,否则会报异常。
如果要实现@Monitor监听,其变量一定要被@Local、@Param、@Provider、@Consumer、@Computed装饰,未被修饰则无法被监听,还有,如果监听对象的变化,则不建议在一个类中对同一个属性进行多次@Monitor的监听,多次监听,只有最后一个定义的监听方法才会有效。
在实际的开发中,我们经常会遇到自定义组件的情况,比如通用的列表组件,选项卡组件等等,由于使用方的样式不一,子组件是动态变化的,针对这一情况,就不得不让使用方把子组件视图传递过来,如何来接收这个UI视图,这就是@BuilderParam装饰器的作用。
@Builder装饰是鸿蒙UI开发中,非常重要的一个装饰器,在实际的开发中,合理且正确的使用,能够让我们的代码更加的简洁,有两点需要注意,一是,是用私有还是全局,取决于当前的组件的复用机制,如果多个页面都使用了,建议以全局为主;二是传参的动态更新,有更新就使用引用参数传递,没有更新按值传递即可。
在结合async/await进行使用的时候,有一点需要注意,await关键字必须结合async,这两个是搭配使用的,缺一不可,同步风格在使用的时候,如何获取到错误呢,毕竟没有catch方法,其实,我们可以自己创建try/catch来捕获异常。
目前提供了两种方式实现popup弹窗,主推系统实现的方式,几乎能满足我们常见的所有场景,当然了,文章毕竟有限,尽量还是以官网为主。
对于数据量比较的小的,我们直接选择轻量级的用户首选项方式即可,而对于数据量比较大的情况下,直接可以使用数据库,而对于相对来说,比较大的数据,我们就可以使用键值型数据库方式
实现方式呢,有很多种,目前采用了比较简单的一种,如果大家采用网格Grid组件实现方式,也是可以的,但是需要考虑每行的边距以及数据,还有最后两行的格子占位问题。
金融类的软件,特别是股票基金类的应用,在查找股票的时候,都会有一个区别于正常键盘的键盘,也就是股票代码键盘,和普通键盘的区别就是,除了常见的数字之外,也有一些常见的股票代码前缀按钮,方便在查找股票的时候,更加方便的进行检索。
车牌字母键盘和一般的键盘还有很大区别的,大家可以发现,键盘上是少一个字母的,因为I字母具有混淆性,所以这个字母是不在车牌键盘内的。
在鸿蒙当中,如何实现根据指定的文本进行合成语音合成播放呢,其实也是非常的简单,因为鸿蒙当中也有textToSpeech。
前两章的内容,我们已经实现了UI还有编辑页面的所有的逻辑,这篇文章,我们着重概述下列表展示,毕竟有数据了,如何分列并且友好的展示出来,这是最重要的,毕竟每一个备忘录都需要一个指定的入口。
开发元服务,有很多的限制性因素,比如包的大小限制,相关API限制,所以,我们在实际开发的时候,具体Api能否使用,还需要去官网查看一下,目前,针对当前这个小项目,总结了几个小问题,大家在开发的过程中可以作为参考。
富文本内容编辑我们直接使用RichEditor组件即可,最重要的就是参数,value: RichEditorOptions,通过它,我们可以用来设置样式,和获取最后的富文本内容,这一点是很重要的。
UI页面绘制没什么好说的,就是组件的位置摆放,和组件的显示逻辑,有很多的属性并没有文章记录,大家可以去仓库中查看即可,文章中用到了我的一个标题栏组件,如果大家不想用,可以使用自己写的即可。
每个方法都预留了多种调用方式,比如使用callback异步回调或者使用Promise异步回调,亦或者同步执行,大家在使用的过程中,可以根据自身业务需要进行选择性调用,也分别暴露了成功和失败的方法,可以针对性的判断在执行的过程中是否执行成功。
实现拖拽,最重要的三个方法就是,打开编辑状态editMode,实现onItemDragStart和onItemDrop,设置拖拽移动动画和交换数据,如果想到开启补位动画,还需要实现supportAnimation方法。
使用了插件和路由库之后,在每个Module下都会生成一个路由配置文件,以Module名字+RouterConfig为文件命名,此路由配置文件,也会在AbilityStage中,通过routerInitConfig方法进行自动配置。
在实际的开发中,应该遵循规范,正确的使用属性动画animateTo,切莫在轮询中使用,否则就会造成本不属当前的动画进行执行,造成UI错误,还有一点需要注意,那就是直接使用animateTo可能导致实例不明确的问题,建议使用getUIContext获取UIContext实例,并使用animateTo调用绑定实例的animateTo。
无论是是使用animateTo还是animation,其实最终要改变的都是组件的可执行属性,最终的效果是一致的,animateTo是闭包内改变属性引起的界面变化,一般作用于出现消失转场,而animation则是组件通过属性接口绑定的属性变化引起的界面变化,一般使用场景为,animateTo适用对多个可动画属性配置相同动画参数的动画,需要嵌套使用动画的场景;animation适用于对多个可动画属性配置不同参数动画的场景。
如果要实现多页面之间的组件属性样式复用,建议使用AttributeModifier,如果是单页面,通用属性可以使用@Styles,组件自有属性可以使用@Extend。
在设置图片帧信息集合的时候,是不支持动态更新的,这一点大家需要知道,还有最重要的一点就是,在性能上是不如属性动画的,也就是说能用属性动画实现的,尽量使用属性动画。
从给出的文本中,按照既定的相关规则,匹配出符合的数据,其中的规则就是正则表达式,使用正则表达式,可以使得我们用简洁的代码就能实现一定复杂的逻辑,比如判断一个邮箱账号是否符合正常的邮箱账号,再比如判断一个手机号是否正常的手机号,等等,正因为有了正则,得以让文本处理起来更加的简单。
无论是Android还是iOS,在系统设置中,都有着深色和浅色两种外观模式,同样,鸿蒙系统中也存在这样的外观切换,如何让自己的应用,跟随着系统的模式进行动态切换呢?目前系统给我们提供了两种方式可以实现,一种是资源形式,一种是动态的代码形式。
画板,最重要的就是绘制,保证线条绘制的连续性,这一点很重要,还有就是beginPath方法一定要调用,否则更改颜色以及绘制就会出现不连续以及颜色设置错误问题。
发表了文章
2025-06-29
发表了文章
2025-06-29
发表了文章
2025-06-28
发表了文章
2025-06-28
发表了文章
2025-06-28
发表了文章
2025-06-28
发表了文章
2025-06-27
发表了文章
2025-06-25
发表了文章
2025-06-24
发表了文章
2025-06-23
发表了文章
2025-06-17
发表了文章
2025-06-17
发表了文章
2025-06-16
发表了文章
2025-06-15
发表了文章
2025-06-15
发表了文章
2025-06-15
发表了文章
2025-06-13
发表了文章
2025-06-13
发表了文章
2025-06-12
发表了文章
2025-06-10