Просто использовать некий буфер надо (если отрубило, при следующем включении чтобы продолжить писать файл с нужного места или скинуть всё буфера в файл и открыть новый), но gpx самое лучшее. Ибо kml тот же xml, а plt убожество. А больше популярных форматов особо и нет, всё извращенские.
А вот буфер может быть хоть txt [lat,lot,time] с построчным переносом.
Попробовал, работает. Пока не уверен, но что-то очень большой расход трафика.
Параметр передачи данных - раз в секунду. Параллельно был запущен Progorod. Когда катался только с ним, расход был порядка 100кб, сегодня - >400кб.
Завтра попробую только с OsMo-клиентом проехаться.
fokin33, просьба - при сборке программы прописывать Default Company 
и версию софта.
Есть подозрения, что софтина не вполне корректно отвечает на запросы статуса окна. Я пользуюсь Spb Pocket Plus, http://spb.com/pocketpc-software/pocketplus/ При использования функционала Alt-Tab (см. 45 секунду ролика) очень долго выводится список при запущеном OsMoMobile.
Насчет траффика вполне возможно если раз в секунду отправлять выйдет много, у меня подключен “Безлимит для мобильный телефонов” поэтому даже не заморачиваюсь по этому поводу. Отправка то идет http запросом, а он досточно длинный.
В ПРОГОРОДЕ скорее всего используется бинарный протокол.
Версию и компанию пропишу ))
Насчет статуса окна программы не знаю, у меня список программ выводится быстро (похожая фишка от HTC).
Почитаю, подумаю.
Траффик он есть “прилично”, ибо постоянная отправка, за ночь активного использования 10 мб можно выжрать, если передача с минимальным интервалом.
Тут ужё встаёт вопрос о том, а надо ли вам такую бешаную частоту или хватит раз в 3-5 сек. Ну и батарейка заодно по-спокойней будет расходоваться.
Бинарный протокол со стороны сервера мне почти помогли сделать, вопрос лишь в том что, клиентов под него нет 
А вообще хочу сделать выбор бинарный/http в дальнейшем. Но опять же прежде всего я делаю упор на клиенты, будут клиенты - сервер не проблема.
upd: Правда бинарник больше имеет смысл для внедрения в программы-навигаторы, так как API подразумевает обратное взаимодействие “сервер → клиент”, например в случае программы навигатора - возможно указать конечную точку маршрута и проложить маршрут удалённо, также сообщения на экран навигатора с сервера, показ специальных точек, временных и постоянных занятых сервером и т.п.
а сделать как у я.навигатора - гзипоавный xml?
и еще идея - возможность отправки на сервер сообщения, которое бы высвечивалось возле маркера. понятно что это только для отдельного клиента работает, в османде оно лишнее будет, а так для групповых мероприятий может быть полезно.
Но там как я понимаю передаётся так трек, а не каждая точка, в каждой точке если так делать только быстрей батарейка будет садится от процессора. Да и сжимать особо нечего тут, ну и xml излишен, максимальная простота.
Я просто думаю, что может нужно сделать как ранее планировалось в клиенте выбор того что посылаем, например мне не нужен HDOP, кому-то высота и скорость объекта, ибо пешком например от неё толку нет, ну как-то так. По мелочи, но если отрубить высоту-скорость-hdop это почти 30% данных. Правда большое место тут занимает сам процесс http запроса, заголовки и всякая требуха, данные в начале тестов весили меньше, чем все http заголовки.
На эту тему есть даже документ: http://code.google.com/p/osmand/wiki/LiveTrackingCallback это то что первоначально планировалось в османде, да и если будет, будет неплохо.
Cd_spb
А кстати на HP - получается передавать координаты в “спящем” состоянии ?
Мысль появилась. Этот функционал переложить на веб-монитор, аля чатик внутри канала. Выводить надпись рядом с маркером очень не просто, тем более на маленьком экране это хз как будет выглядет вообще, тесты с подписями к маркерам пока не утешительные.
А чатик занимающий 25% экрана снизу и там и видно месаги и можно написать. А ещё (жаль экраны в основном маленькие) сделать бы под полем ввода какие нить 3-4-5 кнопочек с шаблонными сообщениями, задаваемыми настройками канала, например в случае дорожного канала “я сломался”, “заблудился”, “следуй за мной”, “будь внимателен”. В случае с игрой - ну сам придумаешь 
м?
Не буду спорить с этим утверждением, но замечу, что на большом экране [абстрактное] приложение, задизайненное под маленький, выглядит чудовищно. И юзабилити чудовищное.
Just my 2 cents.
Попробую завтра проверить. Если не забуду.
Достаточно взглянуть на то как оно сделано: http://leaflet.cloudmade.com/examples/mobile-example.html
full-resizeble
fokin33, кстати, может сделать простейший подсчёт трафика за сессию? Не сохранять его никуда, просто показывать на экранчике, чтобы представлять свои расходы примерно.
Я попробую со стороны сервера сделать, но не очень представляю как посчитать КБ запроса, пришедшего на сервер, вместе с заголовками, но подумаю…
Итак. Отчет по использованию OsMoMobile, клиента под WM. http://ifolder.ru/29808655
Аппаратура:
- КПК HP 214, WM 6.1 оригинальная
- GPS-логгер QStarz BT-1000X, подключён по блютузу.
- Телефон Nokia 3720c, подключён по блютузу.
Настройки:
- Период отправки - 5 сек.
- Допустимый HDOP - 3
- Разница - 1
- Принудительный период - 60 сек.
По статистике на странице http://esya.ru/om/ - 147 точек отправлено.
“10.04.2012 08:05 → 10.04.2012 08:21 (147)”
Получено - 74КБ
Отправлено - 42КБ
Почему отправлено МЕНЬШЕ чем получено?
На полпути выключил питание КПК аппаратной кнопкой, сбор и передача данных продолжилась. На трех четвертях пути прошёл какой-то глюк - нет данных на графике и есть только в самом конце.
Резюме - всё нормально. Но нужно разобраться с объемом данных.
Хм… неужели заголовки перевешивают. Хотя по-моему это могут быть данные каких-нибудь прокси и т.п. я трафик же измерял со своего телефона 3G internet managerom, приём раз в 5 меньше чем передача. Не могло что-нибудь например синхронизироваться? Какая-нибудь почта проверяться?
Не должно быть ничего.
Гадать так можно сколько угодно, единственное технологически верное решение - это на ПК поднять точку доступа (wifi, bt) и каким-нибудь commview смотреть всё на этом интерфейсе. Что не исключает, конечно, что какой-то конкретный proxy по дороге накидает в http header всякого дерьма, типа via, warning
Я тут проанализировал, оказалось информации полезной байт 40 туда и обратно, а сервер в ответах выдавал 370. Немного удалось обрезать заголовки до 325 байт, но это конечно ахтунг. Вот сейчас написал на форум специализированный, авось подскажут. Ведь по сути нужен или минимум заголовков обязательных, или вообще их отрезать напрочь, но пока это не так просто.
Правда это тесты с браузера, а он передаёт cookie авторизации, но всё равно жирненько.
Если у вас хостинг не очень урезанный, можно попробовать написать свой сервер со своим протоколом и держать его на каком-то другом открытом порту. экономия - нету хттп-заголовков, можно держать постоянное соединение и обмениваться только той информацией, что надо. минус - придется это все писать 