关于在我的 Android 应用程序中实现静态多对一查找的建议
我需要在我的 Android 应用程序中执行多对一查找。我存储了许多电话区号以及它们映射到的州。例如,516、518、914 都映射到纽约,213、408、949 都是 CA 等。
我的应用程序很少需要查找此信息 - 在其生命周期中只有几次。
最好的存储方式是什么?我可以将其作为数组存储在 XML 资源文件中,或者存储在 prefs.xml 中。我还可以将其作为静态数组(或集)合并到应用程序中。终于我可以使用数据库了。
我的目标是减少 APK 大小的膨胀,因为这些数据很少使用。第二个目标是保持其可管理性,并避免在数据更改时触及代码。
I need to perform a many-to-one lookup in my Android app. I store a number of phone area codes, and the states they map to. For example, 516, 518, 914 all map to New York, 213, 408, 949 are all CA etc.
My app needs to lookup this information only rarely - a few times in its lifetime.
What is the best way to store it? I could store it in an XML resource file as an Array, or in prefs.xml. I could also incorporate it as a static array (or Set) in the application. Finally I could use a DB.
My goal is to reduce the bloat on the APK size, since this data is so infrequently used. Secondary goal is to keep this manageable, and avoid touching code when data changes.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
“最好”是相对的。我建议将映射保留在 xml 字符串数组资源中(是否有“地图”资源?),因为它更容易更新。我认为尺寸不会有那么大的问题(不过,不要引用我的话)。如果大小很关键,我要么在应用程序外部创建一个 Sqlite DB,然后将其放入资产文件夹中,可能会进行 gzip 压缩。您还可以定义自己的文本文件格式并执行相同的操作。
"Best" is relative. I'd suggest keeping the mapping in xml string array resources (is there a 'map' resource?) because it will be easier to update. I don't think the size will be that big of a deal (don't quote me on that, though). If size was critical, I'd either create a Sqlite DB outside of the app, and put it in the assets folder, possibly gzipped. You could also define your own text file format and do the same thing.
就增加 APK 大小而言,此映射的大小应该不是一个大问题。在我看来,
XML
资源是实现此目的的最佳方法。在我看来,这是解决此类问题的最简单、最原始的方法(应该始终是首选方法)。The size of this mapping should not be a big problem in terms of increasing the APK size.
XML
resource seems to me the best way to go about doing this. In my opinion, that is the simplest and native way(should always be preffered) of solving these kind of problems.