J2ME 中的随机访问数据对象
我计划开发一个小型 J2ME 实用程序，用于使用移动电话查看当地公共交通时刻表。这些数据部分主要是一大堆数字，代表公交车到达或离开的时间。
我试图弄清楚存储这些数据的最佳方式是什么。该表示形式需要
- 相当小（由于移动电话的持久存储限制）
适合单个文件（以便随后通过 HTTP 更新时间表数据库）适合恒定数量的文件，即（routes.dat、times.dat、...、agencies.dat），以及不 (schedule_111.dat,schedule_112.dat, ...)- 具有随机访问能力（将整个数据对象反序列化到内存中对于手机来说太过分了： ))
- 如果有一些库可以访问该数据格式，则应该存在 Java 实现
换句话说，如果您必须压缩 GTFS 之类的数据传输到移动设备中，您会如何执行此操作？
Google Protocol Buffers 似乎是定义数据的不错选择，但它没有随机访问权限。
你有什么建议？
I'm planning to develop a small J2ME utility for viewing local public transport schedules using a mobile phone. The data part for those is mostly a big bunch of numbers representing the times when the buses arrive or leave.
What I'm trying to figure out is what is the best way to store that data. The representation needs to
- be considerably small (because of persistent storage limitations of a mobile phone)
fit into a single file (for the ease of updating the schedule database afterwards over HTTP)fit into a constant number of files, i.e. (routes.dat,times.dat, ...,agencies.dat), and not (schedule_111.dat,schedule_112.dat, ...)- have a random access ability (unserializing the whole data object into memory would be just too much for a mobile phone :))
- if there's some library for accessing that data format, a Java implementation should be present
In other words, if you had to squeeze a big part of GTFS-like data into a mobile device, how would you do that?
Google Protocol Buffers seemed like a good candidate for defining data but it didn't have random access.
What would you suggest?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
J2ME 上的持久存储是一件棘手的事情；请参阅此相关问题了解更一般的背景： 使用 J2ME 存储大量数据的最佳实践
根据我的经验，J2ME 持久存储往往在处理许多小记录而不是一些单一记录时效果最好/最可靠。考虑程序将如何访问数据，然后尝试将其以这些增量存储在 J2ME 持久存储中。
我通常建议解耦客户端-服务器协议，以便从设备上的存储格式下载更新。您可以在每次代码更新时更改后者，但您几乎永远只能支持客户端-服务器协议，除非您想在现场打破旧客户端。
最后，我知道交通开发者群组中有些人已经构建了离线交通J2ME 中的应用程序，因此值得在那里寻求提示。
Persistent storage on J2ME is a tricky business; see this related question for more general background: Best practice for storing large amounts of data with J2ME
In my experience, J2ME persistent storage tends to work best/most reliably with many small records rather than a few monolithic ones. Think about how the program is going to want to access the data, then try to store it in those increments in the J2ME persistent store.
I'd generally recommend decoupling your client-server protocol for downloading updates from the on-device storage format. You can change the latter with every code update, but you're pretty much stuck supporting a client-server protocol forever, unless you want to break older clients out in the field.
Finally, I know there are some people on the Transit Developers group who have built offline transit apps in J2ME, so it's worth asking for tips there.
我制作了这样的应用程序，并使用了 php 生成的 xml-s。这使我们能够拥有 3 个表示层的单一提供程序，它们是：
我们使用 xslt 在网站上将 xml 转换为 html，并使用 kXML - 非常轻的拉式解析器在 j2me 应用程序上执行此操作。即使在带有黑白屏幕和少量内存的非常旧的手机上，这种方法也能很好地工作。
除了j2me之外，没有文件的概念。您拥有可以存储信息的数据库。
这是“移动”网站的链接。
http://mobi.krakow.pl/rozklady/
以及应用程序：
http://www.mobi.krakow.pl/rozklady/j2me/rjk。 jar
这是波兰语，但我认为不难弄清楚这是什么、那是什么。
如果您愿意，我可以为您提供更多帮助和建议，或者如果这是一个商业产品，那么我认为我们也可以找到一些办法；）
I made app like this and I used xml-s generated with php. This enabled us to have a single provider for 3 presentation layers which were:
We used xslt to convert xml to html on websites and kXML - very light pull parser to do it on j2me app. This worked well even on very old phones with b/w screens and small amounts of memory.
Besides on j2me there is no concept of file. You have the db in which you can store information.
This is a link to "mobile" website.
http://mobi.krakow.pl/rozklady/
and here to the app:
http://www.mobi.krakow.pl/rozklady/j2me/rjk.jar
This is in polish, but I think it's not hard to figure out what's this and that.
If you want, I can provide you with more help and advice or if this is a commercial product then I think we can figure out something too ;)
我认为你的问题是要求2。
仅仅因为文件中间某处的4位数字发生了变化而更新10MB的数据似乎效率很低。
将数据拆分为多个文件可以实现更好的更新粒度，这非常值得增加代码复杂性。
实时公共交通时刻表通常一次修改一条公交车/火车/电车线路。
I think your issue is requirement 2.
Updating 10MB of data just because 4 digits changed somewhere in the middle of the file seems highly inefficient.
Spliting the data into several files allows for a better update granularity that will be well worth the added code complexity.
Real-time public transport schedules are usually modified one bus/train/tram line at a time.