暂时未有相关云产品技术能力~
一个北漂的全栈二流程序员。
最后一点是,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方法一定要调用,否则更改颜色以及绘制就会出现不连续以及颜色设置错误问题。
如果你还在使用router做为页面跳转,建议切换Navigation组件作为应用路由框架,不为别的,因为官方目前针对router已不在推荐。
目前的轮播图,仅仅对Swiper做了简单的封装,另外增加了一个线条指示器,这远远是不够的,毕竟日常的轮播图形式多种多样,指示器也是千奇百怪,后续也会在此基础之上进行不断的扩展。
主页的底部导航以及页面顶部的切换导航,无论哪个系统,哪个App,都是最常见的功能之一,虽然说在鸿蒙中有现成的组件tabs可以很快速的实现,但是在使用的时候,依然有几个潜在的问题存在,第一,当导航较少时,tabs是默认居中模式,目前无法进行居左,在有这样功能的时候,难以满足需求;第二,导航右侧需要展示按钮的时候,tabs也是无法满足的;除此之外,还有很多人都非常关心的问题,底部的指示器可以跟随页面的滑动而滑动;面对着种种问题的存在,系统的tabs改进之路仍然很艰巨。
既然是一个剪辑截取的功能,音频也好,视频也好,大同小异,无非就是轨道不一,进度不一,但拖拽的滑块都是相似的,除了常见的音视频使用之外,有双向滑动需求的场景也是可以满足的。
软键盘最主要的就是合理的进行避让,不能遮挡可输入组件,再有多个输入框的时候,需要动态的进行设置高度,这一点需要注意。
在和可滑动组件使用的时候,记得一定要和nestedScroll属性配合使用,用于解决滑动冲突,除此之外,还需要传递滑动组件的scroller属性,用于手势操作。
在列表组件使用的时候,如List、Grid、WaterFlow等,循环渲染时都会使用到ForEach或者LazyForEach,当然了,也有单独使用的场景,如下,一个很简单的列表组件使用,这种使用方式,在官方的很多案例中也多次出现,相信在实际的开发中多多少少也会存在。
在鸿蒙开发中,如何实现这一效果呢,最重要的解决两个问题,第一个问题是,如何在上一个输入框输入完之后,焦点切换至下一个输入框中,第二个问题是,如何禁止已经输入的输入框的焦点,两个问题解决完之后,其他的就很是简单了。