祝贺团队。我几年前曾参与这个项目一段时间。确实，我将最初的“将整个index.xml读入Java内存中使用一个巨大的DB类”改为了第一个“从XML流式传输条目到数据库，并使用ContentProviders”，因为当时这看起来像是“Android的正确做法”。我还参与了从XML到JSON元数据的迁移。当时我们需要更新元数据格式以支持元数据的国际化和图像的包含。看到Torsten和其他人正在用现代的Kotlin + Room实现来替换我那些过时的ContentProvider代码，这让我感到非常欣慰。如果你们中的任何人在阅读这段话，请接受我最深切的同情，因为你们不得不抽出那段代码并重新构建——这绝不是我愿意做的事情！更棒的是，所有这些代码都存在于库中，其他客户端如果愿意的话可以采用，而不需要重新发明轮子。…
源讨论用于更快更小更新的新F-Droid仓库格式原帖 139 条评论 · 导入时统计把你的经验，加入这段讨论。
谢谢你所做的一切！Android生态系统非常具有敌意，对于一个外来者来说，很难理解你多年来不可避免面对的公开和私下的斗争。
完整原文天啊，时间过得真快。上次我简短地和你说话（FSM活动）时，你还在开发Fdroid。
完整原文使用ContentProviders相比直接访问数据库有什么（或曾经有什么）好处呢？它们在在应用之间交换数据时似乎很有用，但我无法理解它们在应用内部（未导出的情况下）的作用。 是不是因为它们是使用CursorLoader所必需的，这样你就可以轻松地在后台加载东西，而无需创建自定义的Loader实现？它们基本上只是相当不方便的数据库抽象？
完整原文嘿 @pserwylo，很高兴收到你的消息，我特别感谢你在这里发来的背景信息。我想强调你提到的一个观点，即贡献者的时间比人们想象的要少得多。如果说有什么的话，F-Droid 客户端在 2016 年的用户体验设计过程证明是一个非常高效的练习，它最终形成了一个仍然可以正常工作的用户体验。此外，我们还成功预测了底部导航栏的流行度会上升，而当时推荐的侧滑菜单会逐渐过时。 当然，你随时可以再次做出贡献！困难的部分在于应用商店是大型且复杂的应用，完全实现后很难参与其中。如果我们有人想找一个地方贡献，我们会标记一些带有“first-timer”https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... 和“help-wanted”https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... 的问题。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。