Android开发中ORM框架的主要竞争者是SQLDelight。 这个库比Room还要老,但是据我了解,在过去的一年左右的时间里,它已经被重写了很多。 不幸的是,它现在只针对Kotlin。 另一方面,SQLDelight支持Kotlin跨平台。 因此,随着Kotlin使用率的增加,我预计SQLDelight的使用率也会随之增加。
顺便说一下,AndroidX中有对原生SQLite的使用说明,我还不知道该怎么使用。但是如果您想在应用中使用原生SQLite,那么你或许需要去认真的研究下这个主题。
此外还有许多针对Android的非关系型的数据库,例如Realm,Parse,Firebase,ObjectBox等(其中有些仍在使用SQLite)。如果我没记错的话,它们中的大多数(甚至全部)都具有自动数据同步功能。 一段时间以来,这些解决方案比较流行,但据我所知,它们已经不复存在了。但是我并不会马上认为非关系型的数据库不再重要了。
去年,我编写了一个非常复杂的集成了Parse Server的Android应用。 我使用了Android版本的的Parse SDK,体验都非常好。如果您的公司已经雇用了许多后端开发人员,或者您需要实现许多服务器端逻辑,这可能不是最佳解决方案,但是对于仅在后端执行CRUD操作的初创企业和个人来说,这可能会是一种好的选择。
但是我必须提醒的一点是:如果您要采用数据库即服务的解决方案(例如Firebase),那么请务必了解其长期的成本和影响。
关于外部存储的开发,这里有许多有“意思”的事情。
如果您应用的target sdk版本等于或者大于29,那么你的应用将无法再正常访问手机外部存储上的文件,除了少数几种明显的情况。 相反,您需要使用SAF框架(据说),该框架允许用户进行更精细的访问管理。不幸的是,SAF的工作方式与之前完全不同,因此某些应用程序可能需要进行重大重构。
Google希望从Android 10开始对所有的应用程序都实行这一要求,但它引起了开发者社区的强烈抗议,于是他们决定推迟此功能。 因此,即使您的应用设置target sdk版本为 29,它仍可以在“旧版”模式下工作。 但是,无论目标API级别是多少,下一版的Android系统都将对所有应用的存储访问范围做更加严格的限制。
到目前为止,我还没有使用SAF框架,但是从我在互联网上阅读的许多讨论中看来,这可能是一项艰巨的任务。因此,如果您的应用程序还在以“旧版”模式使用外部存储,那么最好立即开始进行重构和测试。
几周前,AndroidX系列中添加了一个新框架。 它的commit message是这么说的:
New library meant to replace SharedPreferences. The name is not final, this is just for implementation review and to support the design doc (feel free to request the design doc privately)[…]
目前我们无需担心,但从长远来看,似乎SharedPreferences会被重写,我们需要使用这种新的方法。
SharedPreferences和这个新框架之间的主要区别在于,默认情况下后者是异步的。 换句话说,您需要实现一个回调以获取特定键的值,该回调将在以后的某个时间收到通知。
如果您对这种异步通知的机制感到好奇,则可以阅读StackOverflow上的这个答案。 Reddit用户Tolriq在这里分享了他们遇到此bug的概率。 在他们的应用中,这个bug会影响1 / 10,000 / SESSIONS_PER_USER_PER_MONTH的用户。 对于一般的应用程序,这可能微不足道。但是在需要高可靠性的情况下,这可能会引起严重的后果。 例如,在装有Android Auto的汽车中,应用程序挂起和随后的崩溃会分散驾驶员的注意力,这可能会导致非常不幸的后果。
在依赖注入方面,最大的变化就是Dagger-Android的弃用。 这里我想解释两点: 首先,我说的弃用并不是指“正式”弃用,因为它尚未正式弃用。 其次,Dagger-Android并不是整个Dagger2框架,而只是相对较新的功能。 我在这个主题上写了一篇非常详尽的文章,所以我在这里不再重复。
至于其他依赖注入框架,我不认为它们是Dagger的真正竞争者。 例如,Koin也许不错,但我认为它不会吸引很多人。 实际上,我相信它仅由于两个主要原因而得到了初步采用。 第一个是Dagger的糟糕文档,Koin在这方面要比Dagger领先N光年。 第二个原因是Koin是用Kotlin编写的,它借着kotlin发