Объект данных с произвольным доступом в J2ME - PullRequest
Новая
       29

Объект данных с произвольным доступом в J2ME

1 голос
/ 01 ноября 2009

Я планирую разработать небольшую утилиту J2ME для просмотра расписаний местного общественного транспорта с помощью мобильного телефона. Часть данных для них в основном представляет собой большую группу цифр, представляющих время прибытия или отъезда автобусов.

Я пытаюсь выяснить, каков наилучший способ хранения этих данных. Представление должно

  1. значительно меньше (из-за постоянных ограничений памяти мобильного телефона)
  2. помещается в один файл (для простоты обновления базы данных расписания впоследствии по HTTP) помещается в постоянное количество файлов, т. Е. (routes.dat, times.dat, ..., agencies.dat) и не (schedule_111.dat, schedule_112.dat, ...)
  3. иметь возможность произвольного доступа (несериализация всего объекта данных в память была бы слишком большой для мобильного телефона:))
  4. если есть какая-то библиотека для доступа к этому формату данных, должна присутствовать реализация Java

Другими словами, если бы вам пришлось втиснуть большую часть GTFS данных в мобильное устройство, как бы вы это сделали?

Буферы протокола Google казался хорошим кандидатом для определения данных, но не имел произвольного доступа.

Что бы вы предложили?

Ответы [ 3 ]

2 голосов
/ 09 ноября 2009

Постоянное хранилище на J2ME - сложная задача; см. этот связанный вопрос для более общего понимания: Лучшая практика для хранения больших объемов данных с J2ME

По моему опыту, постоянное хранилище J2ME имеет тенденцию работать лучше / надежнее со многими небольшими записями, а не с несколькими монолитными. Подумайте, как программа захочет получить доступ к данным, а затем попытайтесь сохранить их в этих приращениях в постоянном хранилище J2ME.

Как правило, я бы рекомендовал отключить ваш клиент-серверный протокол для загрузки обновлений из формата хранения на устройстве. Вы можете менять последнее при каждом обновлении кода, но вы почти всегда застряли с поддержкой протокола клиент-сервер, если только вы не хотите сломать старых клиентов в полевых условиях.

Наконец, я знаю, что в группе Transit Developers есть люди, которые создавали автономные приложения для транзита в J2ME, так что стоит спросить совета там.

1 голос
/ 02 ноября 2009

Я думаю, что ваша проблема - требование 2.

Обновление 10 МБ данных только потому, что где-то в середине файла изменилось 4 цифры, кажется крайне неэффективным.

Разделение данных на несколько файлов позволяет повысить степень детализации обновления, что будет стоить дополнительной сложности кода.

Графики общественного транспорта в режиме реального времени обычно изменяются по одной автобусной / железнодорожной / трамвайной линии за раз.

1 голос
/ 02 ноября 2009

Я сделал такое приложение и использовал xml-ы, созданные с помощью php. Это позволило нам иметь единого провайдера для 3 уровней представления:

  • Приложение j2me
  • сайт для мобильных телефонов
  • обычный сайт

Мы использовали xslt для конвертирования xml в html на веб-сайтах и ​​kXML - очень легкий парсер, который делает это в приложении j2me. Это хорошо работало даже на очень старых телефонах с черно-белыми экранами и небольшим объемом памяти.

Кроме того, в j2me отсутствует понятие файла. У вас есть БД, в которой вы можете хранить информацию. Это ссылка на «мобильный» сайт. http://mobi.krakow.pl/rozklady/

и вот к приложению: http://www.mobi.krakow.pl/rozklady/j2me/rjk.jar

Это по-польски, но я думаю, нетрудно понять, что это и что.

Если вы хотите, я могу предоставить вам дополнительную помощь и совет, или, если это коммерческий продукт, я думаю, мы тоже можем кое-что выяснить;)

...