卡片代码生成器 json卡片代码( 四 )


// StoreConfig最常见的作用是配置数据库名字 。也可以配置存储模式、加密等高级需求 。StoreConfig config = StoreConfig.newDefaultConfig(DB_NAME_FORM_STORE);// RdbOpenCallback用于定义创建数据库、升级数据库结构版本等时机的回调 。RdbOpenCallback callback = new FormStoreOpenCallback(context);DatabaseHelper helper = new DatabaseHelper(context);// RdbStore是数据库的封装类,最终的增删改查操作都通过它来进行 。RdbStore store = helper.getRdbStore(config, CURRENT_VERSION, callback);具体的增删改查操作就不一一列举了 。
数据更新前面声明卡片一节提到了config.json中,updateEnabled、updateDuration定义了卡片的数据更新机制 。
其中updateEnabled用于指定是否通过系统来自动更新卡片数据,如果希望由应用自身触发数据更新,这个可以设置为false 。优酷卡片的场景是希望系统能够自动更新卡片数据的,所以设为了true 。
在updateEnabled设为true的情况下,updateDuration才有意义 。updateDuration用于指定更新的时间间隔 。鸿蒙系统还支持固定时间更新,通过指定scheduledUpateTime来设置更新时间 。updateDuration和scheduledUpateTime只能选择其中一种方式 。
优酷卡片选择了用updateDuration指定更新间隔 。为了避免将来使用卡片的用户多了,对服务端产生过大的压力,更新间隔被控制在4小时,这样用户在上午、下午、晚上等不同时段去看卡片时,内容都会有更新 。
但是有些情况下,优酷卡片自身的逻辑也会更新卡片数据,所以为了避免两种更新策略冲突而导致更密集的更新,或者长时间不更新,updateDuration被指定为1,即每半小时系统就会调用一次onUpdateForm() 。在onUpdateForm()中,会判断上一次实际发生更新的时间,使更新间隔保持在4小时左右 。
容错处理考虑到一些极端情况,例如用户安装优酷后,在没有网络的情况下就添加了桌面卡片 。此时卡片的数据请求是没有返回的,同时由于刚安装,也没有缓存数据,所以卡片展示不出任何数据,只有灰色的打底图作为背景 。此时如果点击卡片,也没有任何视频信息,也就无法跳转到某个特定视频的播放页,只能显示一个加载失败的提示,等用户网络恢复后,通过刷新得到有效数据 。
空白卡片点击卡片后的空白页面展望现在优酷鸿蒙版的桌面卡片已经随着鸿蒙系统的发布,正式上线了 。在鸿蒙系统的手机上,从华为应用市场安装的优酷主客就已经附带了优酷卡片的能力 。
由于这是一个全新的开发技术栈,早期发布的应用肯定会有一些改进空间 。从现在看来主要有以下一些方面:

  1. 性能
    由于数据请求和埋点用到了JS库,并且在WebView中运行,这使得运行时效率比Java要低,还要处理WebView与外界的交互,对性能有较大影响 。虽然已经有了一些措施来减少这方面的影响,但是后续还是需要继续挖掘潜力
  2. 监控
    后续还需要补足JS侧崩溃等信息收集的能力 。
  3. 线上配置能力
    优酷主客可以通过各种远程配置平台下发各种配置信息 。而鸿蒙上由于体积限制无法自带相关的库 。今后需要考虑使用其他方式实现远程配置能力 。
【卡片代码生成器 json卡片代码】最后,10月20日将上线《优酷鸿蒙开发实践》系列技术文章第二篇,为大家介绍如何实现Android/鸿蒙混合打包的流程 。感谢关注,我们下篇技术实践再见 。

推荐阅读