前言
最近准备填一些以前开的坑,当然不能只填坑而没有收获,于是准备做一哈数据库缓存,左挑右选,最终选择了 ObjectBox,作者同样也是 greenDao 和 EventBus 的开发者,质量值得信赖。本文会介绍关于 ObjectBox 的基本使用和我在使用中碰到的一些问题,加上一些我在做缓存时候的思路。
引入
能力比较强的同学,直接放上官方文档:https://docs.objectbox.io/,首先在项目最外层 build.gradle 文件中加入:
1 | buildscript { |
最近准备填一些以前开的坑,当然不能只填坑而没有收获,于是准备做一哈数据库缓存,左挑右选,最终选择了 ObjectBox,作者同样也是 greenDao 和 EventBus 的开发者,质量值得信赖。本文会介绍关于 ObjectBox 的基本使用和我在使用中碰到的一些问题,加上一些我在做缓存时候的思路。
能力比较强的同学,直接放上官方文档:https://docs.objectbox.io/,首先在项目最外层 build.gradle 文件中加入:
1 | buildscript { |
近期公司的 App 版本迭代比较快,经常发新版本,但实际上就我自己来说,手机里的 App 不到不能用的时候我是不会更新的,我们前期的解决方案就是强制更新,不更新不让用,以前我们用户少的时候还能这么干,用户量上去还这么干,基本等于劝退那些不怎么愿意更新的用户。所以近期研究的技术点是 热修复 与 增量更新。热修复可以不用因为更改 Bug 而专门发布新版本,增量更新可以让用户在不得不更新的时候可以少花一些流量。热更新最近的接入测试流程都过的差不多了,比我想象的要顺利一些,不过我接入的是 Tinker,操作起来还是挺麻烦的,同事去看 Sophix 了,Sophix 是无侵入的接入,感觉打包什么的操作应该会简单很多。回归正题,本文是参考了很多文章最后经过实践得出的,因为一些文章的时间比较久远,我在实践的时候也碰到了很多问题,查资料也不太好查,最后想了想还是用 CMake 去编译,最后跑通了整个流程。
最近有一个强制更新的需求,当然对于强制更新,我的内心是拒绝的。但是有的时候的确有应用的场景,比如服务器接口由于一些考量改变了,一些协议也改变了,那么老的客户端可能就会出现闪退的情况,一般可以通过几个版本的迭代解决这个问题,但是如果几个版本后还是有一些用户停留在老版本,那么强制更新就很有必要了。当然了,这里所谓的强制更新也就是你不更新到最新版本,会让你无法使用,并提醒你更新。普通的应用只能做到这个程度了,因为你没有 root 权限是做不到静默更新的。
这里只是记录一下在实现的过程中需要注意的几个点:
当然,并不会每一个都展开写,因为有些东西真的出来挺久了,还没去看的话只能说你已经有点落后于 Android 版本了。本文也不是详细介绍如何使用 DownloadManager 的文,对这玩意感兴趣的可以去看看 api。
这里我们至少需要后台提供哪些信息呢?
这里的版本号,最好对应我们 Android 中的 versionCode,用这个来判断最直观。下文所有实现均为 Kotlin 代码!
最近碰到一个有趣的情况,在做一个功能时,考虑到从零开始开发需要花费大量的时间和精力,所以选用了一个有 UI 的库,并在这个库的基础之上进行二次开发。于是在项目中引入了这个库,当然,当时已经有大部分功能开发完成了,所以 UI 有一部分在 app 这个主模块中,而一部分则依赖这个库。Android Studio 中 app 模块是可以依赖其他引入项目的库的,而库则不可以依赖 app 模块,那这就引发了一个问题:主要功能已经在 app 中开发完毕,比如用户信息模块,而这个 UI 库的一些 UI 更新和功能也需要当前的用户信息,这该怎么办呢?
首先弄清楚这个问题的本质,这个问题的本质上是模块依赖引发的问题
,仅仅是库依赖不了 app 模块的问题,所以不要用过于复杂的方法去解决,比如通过文件读写(sp文件)或者 socket 之类的。在刚开始时我第一个想到的是用 EventBus,但是想了想觉得不合适。EventBus 是一个事件发布订阅的模型,你可以想象一下这个情况:
最近好不容易进入了学习状态,可能要进入一个高产的状态了。目前比较想要折腾 hexo,所以近期可能会集中的看一下 html + css + js。以前折腾过一些东西,前端的一些东西一直算是我的拦路虎吧。之前由于 Android 本身水平也有限,所以只能先搞定自己的本职。近期 Android 遇到的需求用之前的积累也够了,所以打算扫掉一些我前进路上的拦路虎。python 用来写一些方便的工具还是非常棒的,在扫掉前端的这些拦路虎之后,可能会再去看一下 python。当然了,一切都是在本职能很好的完成的前提下。这里也大体的制定一个目标吧:
汉诺塔问题描述:
汉诺塔:汉诺塔(又称河内塔)问题是源于印度一个古老传说的益智玩具。大梵天创造世界的时候做了三根金刚石柱子,在一根柱子上从下往上按照大小顺序摞着64片黄金圆盘。大梵天命令婆罗门把圆盘从下面开始按大小顺序重新摆放在另一根柱子上。并且规定,在小圆盘上不能放大圆盘,在三根柱子之间一次只能移动一个圆盘。
关于这个问题,简单的分析一个3层的例子,有a、b、c三根柱子,其中a柱子放着三个盘子1,2,3,c是盘子移动的目的地,b是用来辅助移动的柱子:
这两天抽空把简书的文章都迁移到了自己的博客中,这里小记一下。首先说明我这里的配置环境:
原来是利用 github + hexo 来搭建自己的博客的,后来折腾了一下 wordpress,恩,感觉的确是够折腾的,还是改回 hexo 好了。在准备改回来的时候,我转念一想,github 也就是作为一个 git 仓库,那么我能否利用自己的服务器来作为静态页面的容器呢?说干就干,试了一下果然可以。首先在服务器建立一个 git 仓库(这里省略本地和服务器环境配置的过程):
1 | # mkdir ~/blog |
之后配置钩子,在每次收到 post 后将文件更新到 nginx 的资源目录下,钩子在 git 目录的 hooks 目录下:
1 | # cd ~/blog/hexo.git/hooks |
许久没有写博客了,最近有一点做咸鱼的倾向,Android方面也碰上瓶颈挺久了。主要是目前可能没有碰上特别有挑战的需求吧,以之前的知识储备就足够了。最近游戏进度倒是喜人,黑魂3快通关了,但也不能老做一条咸鱼,还是得进步啊~看书还是得做做笔记的,不然看了没多久可能就忘了,书携带也不带方便,所以还是做一下笔记发在自己的博客上比较稳妥。
本文以及后续所有的设模式博文均为《Android源码设计模式》一书的笔记。
以下为书中原文:状态模式中的行为是由状态来决定的,不同的状态下有不同的行为。状态模式把对象的行为包装在不同的状态对象里,每一个状态对象都有一个共同的抽象状态基类。状态模式的意图是让一个对象在其内部状态改变的时候,其行为也随之改变。
介绍与定义都看了,该怎么理解呢?结合实际的例子来说,在用户登录与不登录时,一个按钮触发的点击事件是不一样的,这里登录与不登录是两种状态。那么不使用状态模式的实现是怎样的呢?