перевод формата сериализации и передачи объектов на JSON

[GoogleCodeExporter]

Использование формата JSON для сериализации 
объектов и передачи их по сети с одной 
стороны помогло бы решить некоторые 
внутренние проблемы системы и с другой 
стороны - использование стандартов всегда 
лучше, чем их неиспользование.

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

Подробное обсуждение в этой ветке (топик 
называется "Группа J2ME"):

http://groups.google.com/group/innofivt2010/browse_thread/thread/466d2c46e8e82b6
d/13f55bdabb0d1250#13f55bdabb0d1250

Одно из основых сообщений с полезными 
ссылками:

2010/10/23 Александр Околедов <alexander.okole...@gmail.com>

> >Следующий шаг - уменьшение количества 
запросов с 4х до 1го. Для этого
> >наиболее подходящий на данный момент 
вариант - возвращение массива
> >разнотипных объектов в ответ на один 
запрос. Релизовать его на самом деле
> не
> >сложнее, чем засунуть в Schedule текстовые 
поля из разных таблиц, так что
> >думаю мы даже сможем успеть с этим до 
конца семестра, но всему свое время
> -
> >в первую очередь нужно реализовать 
методы getEntry(ID[]) - тем более, что
> >они понадобятся в любом случае.

> А как будет устроен этот разнотипный 
массив? Как мы узнаем, к какому
> классу принадлежит текущий элемент? Он же 
в виде запакованной
> строки...

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

Во-вторых, т.к. формат передаваемых 
объектов у нас начинает развиваться,
будет разумно не продолжать развивать свой 
велосипед, а перейти на
что-нибудь более стандартное, 
предназначенное для этих же целей - ранее 
уже
упоминал формат JSON - он легковесный, 
во-многом похож на наш текущий
самодельный формат, но только более 
фичастый и стандартизированный. Также
есть поддержка массивов. Прямой поддержки 
типизированных сложных объектов в
исходном стандарте нет, но это решается 
дополнительными простыми
надстройками типа введения служебного 
поля "javaClass" (пример есть здесь:
http://oss.metaparadigm.com/jsonrpc-1.0/manual.html).

И, кстати говоря, в нем же есть прозрачная 
поддежка вложенных объектов (см
пример в википедии: http://en.wikipedia.org/wiki/JSON), так 
что можно будет
рассмотреть вариант передачи например 
полного объекта "Lecture" со всеми его
полями (а не только именем) прямо внутри 
возвращаемого объекта "Schedule" и
при этом не дополнять исходный 
java-интерфейс Schedule лишними полями (минус
такого подхода по сравнению с передачей 
плоских массивов - дублирование
информации - если в один день будет две 
лекции, то ответ на запрос передаст
две одинаковых копии объекта; плюс - мы 
сможем не вводить дополнительные
сервисы с "удобными" вызовами на стороне 
сервера - все можно будет
заимплементить в рамках существующих 
сервисов-таблиц).

Плюс есть готовые библиотеки для его 
парсинга:

- Для обычной Java полный список здесь: 
http://www.json.org/ (мне на первый
взгляд наиболее импонируют 
http://code.google.com/p/json-simple/ и
http://code.google.com/p/jsonmarshaller/)
- Для JavaME библиотека есть здесь:
https://meapplicationdevelopers.dev.java.net/mobileajax.html

> Давайте сразу делать этот вариант! У меня 
уже сейчас 4 запроса(хотя
> вру, возможно 6, потому что я загружаю 
дополнительные таблицы, не
> участвующие в отображении, но можно 
свести к 4, закомментировав пару
> строчек) - это будет лишний труд, время 
загрузки не уменьшится.

Текущее время загрузки это не уменьшит, но 
зато решит потенциальную проблему
роста расписания, которая сейчас себя не 
проявляет, но совершенно четко
вылезет после того, как на сервере будет 
заполнено полное расписание на все
группы. Мобильное приложение в текущем 
виде будет вытягивать все данные
(getAll), а после изменений - только 
действительно нужные (get(ID[])).

Это действительно серьезная бага, которую 
мы сейчас можем и должны решить
"малой кровью" без серьезных изменений в 
наработанной инфраструктуре - метод
get(ID[]) в текущую архитектуру сервисов 
вписывается идеально - так что
лишним трудом их добавление называть никак 
нельзя.

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

Если выбирать из двух возможностей: "все 
работает реактивно с одним
запросом, но не ясно, будет ли все это 
выполнено во время" и "все работает
без багов чуть медленнее с 4мя запросами, но 
будет выполнено
гарантированно", я выбираю однозначно 2й 
вариант, особенно с учетом того, за
какое время у нас делаются даже более 
простые изменения - такой выбор
основан не на любви к медленным 
неоптимальным решениям, а на правилах
управления проектами, следуя которым нужно 
уметь расставлять правильные
приоритеты и реалистично оценивать 
возможности команды.

И еще раз повторю, что совершенно не 
возражаю, если вы форсированными
усилиями решите побыстрому сразу все 
задачи - добавите методы get(ID[]),
перейдете на JSON и сведете количество 
обращений к серверу до 1го - буду
только рад.

> 4 запроса это 8 секунд на один день. это 
НЕРЕАЛЬНО, разве можно давать
> людям программу, которой нужно тормозить 
целую минуту, чтобы
> просмотреть расписание на всю неделю?

Не понимаю, откуда взялась минута - у нас 
сейчас главный экран с расписанием
отображает список лекций как раз только на 
один день. Это значит, что
главный экран всегда будет грузиться ровно 
8 секунд (4 запроса) вне
зависимости от того, сколько в этот день 
назначено лекций. Т.е. я запускаю
приложение, жду 8 секунд и получаю перед 
глазами нужное мне расписание -
больше я не жду ничего. 8 секунд для 
интернет-приложения - вполне приемлемое
значение (веб-страница все равно может 
грузиться дольше), хотя лично у меня
на андроиде страница с расписанием сейчас 
грузится гораздо быстрее (при этом
насколько я понимаю, они у себя оптимизаций 
по количеству запросов не
делали). На JavaME список лекций на день 
грузится также достаточно быстро,
хотя запускаю на эмуляторе, поэтому 
оценить реальное положение дел не могу. 

Original issue reported on code.google.com by bender...@gmail.com on 4 Nov 2010 at 1:31

[GoogleCodeExporter]

Мне кажется, что JSON предпочтительнее, чем 
самодельные форматы... И чем раньше это 
случится сейчас - тем больше вообще 
вероятность, что это случится... А в плане 
расширения функциональности и усложнения 
архитекруры стандартизация - просто 
необходимая вещь.

Если менеджмент проекта одобрил бы 
выделение времени на переход к новому 
формату, это было бы более чем правильно. 
Тем более, что сейчас идет речь о изменении 
вида запросов для объединения их в один.

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

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

Целесообразно это или нет, но я бы 
предложил группе API в первую очередь 
реализовать полную поддержку JSON, а уж после 
этого группам приложений браться за эту 
работу.

Реализация перехода довольно проста:
Если в запросе приходит параметр format=JSON, то 
ответ передается в виде JSON в случае 
отсутствия параметра или наличия 
параметра format=XML (или format=old), передается 
старый формат, дабы осуществлять поддержку 
остальных приложений на время перехода.

Если сделать поддержку JSON для уже 
реализованных методов и поддерживать его 
наличие для новых методов, то тогда группам 
приложений будет очень просто переходить, 
на новый формат, не опасаясь того, что с 
этим возникнут трудности и вообще, 
остановка работы.

Если же это делать после релиза, придется, 
тьфу-тьфу-тьфу, в новых версиях продукта 
тянуть за собой поддержку старого формата 
на API-сервисе... То есть не только разделять 
версии продукта, так еще и оставлять 
поддержку упаковки в старый формат...Или же 
безоговорочно предлагать пользователю 
скачать новую версию продукта, а это с 
точки зрения маркетинга не очень хорошо.

В общем - это уже дело времени и решения 
начальства. Свое мнение я высказал. Спасибо.

Original comment by anton.go...@gmail.com on 4 Nov 2010 at 7:18

• Added labels: Type-Other
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

>В плане "любви к искусству и полезного 
опыта" - переход на новую спецификацию - 
дело >трудное и вряд ли за него возьмутся 
группы мобильных приложений, пока для 
этого не >будет все готово со стороны API.

Со стороны API у нас по идее для этого уже все 
готово - нужно только заменить содержимое 
методов toStringData() и setData(String n, String d) - чтобы 
они начали работать с новым фоматом. Всвязи 
с этим я думаю нам нужно остановиться на 
решении передавать связанные объекты не 
массивом, а в виде вложенных структур JSON 
(пример есть в википедии ссылкой выше) - 
тогда API вообще не изменится - изменится 
только реализация методов. Но естественно 
все должно быть сначала реализовано на 
стороне сервера и уже потом на мобильных 
клиентах.

Кстати, в API я бы сделал небольшой 
рефокторинг - перенес бы методы setData(String n, 
String d) и toStringData() из структур Schedule в 
интерфейсы ScheduleTable. Во-первых это позволит 
иметь их разные реализации на разных 
платформах (на андроиде будет 
использоваться своя библиотека JSON, на JME - 
своя). Плюс это необходимо сделать еще 
потому, что для получения информации о 
вложенных объектах потребует обращение к 
соседним таблицам - например из таблицы 
ScheduleTable нужно будет получать информацию из 
LecturesTable - иметь этот код внутри объектов 
Schedule/Lecture будет не очень правильно.

>Реализация перехода довольно проста:
>Если в запросе приходит параметр format=JSON, то 
ответ передается в виде JSON в >случае 
отсутствия параметра или наличия 
параметра format=XML (или format=old), >передается 
старый формат, дабы осуществлять поддержку 
остальных приложений на время >перехода.

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

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

>Или же безоговорочно предлагать 
пользователю скачать новую версию 
продукта, а это с точки зрения маркетинга 
не очень хорошо.

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

Original comment by bender...@gmail.com on 5 Nov 2010 at 3:41