это… как бы для джавы не лучше ли с точки зрения быстродействия обрабатывать JSON? его же дешевле в массивы загонять.

Anubis написал(а):
Кстати предложения по поводу улучшения XML API (серверной стороны) принимаются? я считаю тут есть что совершенствовать…

Принимаются.

Anubis написал(а):
у меня проблемка с сериализацией массивов с актёрами, странами, режиссёрами и жанрами.
проблема конкретно вот в чём:
Я использую Simple Framework для сериализации в XML. Этот фреймворк не умеет инициализировать массивы если ему не скормить размер массива.

Вот уж не думал, что есть такая проблема и уж тем более с такими проблемами по производительности.

ElDrako написал(а):
это… как бы для джавы не лучше ли с точки зрения быстродействия обрабатывать JSON? его же дешевле в массивы загонять.

Я думал об этом но с наскока не нашел ничего стоящего. сегодня ещё посмотрю. потому что XML уж очень долго сериализуется. Как-то в java с этим дела печально обстоят.

admin написал(а):
Вот уж не думал, что есть такая проблема и уж тем более с такими проблемами по производительности.

альтернатив для сериализации из XML почти нет в java. на всех закаулках интернета кричат что simple framework это самое то для андроида. Хотя ваш XML в 50 кб у меня вчера на телефоне сериализовывался по 5 секунд.

admin написал(а):
Принимаются.

Я предлагаю пока:
1) результаты того что возвращает Movie.New сделать попроще. 50кб даже с вашим gzip =>25кб это многовато для мобильных устройств чтобы приложение было отзывчивым. Сам объект предлагаю урезать, на сколько урезать - надо серьёзно подумать.
2) было бы круто повесить какойнить id в атрибуты movie а также дописать метод Movie.ById который вернёт развернутые данные по фильму.
Это первое что приходит в голову.

Эй джависты, отзовитесь. давайте работать вместе потому что я на джаву после .net смотрю как на что-то архаичное, неудобное и калечное =)

Добавлено через 1 минуту

---

3) Ограничить количество или както контролировать количество объектов возвращаемых с Movie.New

Anubis написал(а):
результаты того что возвращает Movie.New сделать попроще. 50кб даже с вашим gzip =>25кб это многовато для мобильных устройств

только убрать описание. но сама суть новых фильмов в быстром просмотре инфы и оценке надо/не надо. А без описания этого не сделать.

вывод - там мало что можно выкинуть.

Anubis написал(а):
было бы круто повесить какойнить id в атрибуты movie а также дописать метод Movie.ById который вернёт развернутые данные по фильму.

зачем?
можно определить общее количество узлов ветви.
можно получить номер узла.
можно выбрать узел по его номеру.

Anubis написал(а):
3) Ограничить количество или както контролировать количество объектов возвращаемых с Movie.New

в смысле в запрос к апи Movie.New дабавить параметр количества элементов в ответе?
может быть полезно.
только всё равно нужно сначала определять общее количество отданного, а не надеяться на свой запрос, т.к. в ответе их может быть меньше.

Добавлено через 3 минуты

---

по json же попробуйте это - http://code.google.com/p/google-gson/

Anubis написал(а):
я на джаву после .net смотрю как на что-то архаичное, неудобное и калечное =)

Вот к чему приводит увлечение .NET:

Ницше написал(а):
Кто сражается с чудовищами, тому следует остерегаться, чтобы самому при этом не стать чудовищем. И если ты долго смотришь в бездну, то бездна тоже смотрит в тебя.

А если серьёзно, говорят, что теперь Jackson умеет и JSON, и XML, и, при этом, рвет всех по производительности:

http://jackson-users.ning.com/profiles/blogs/experimental-support-for

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

P.S. См. сравнения производительности:

https://github.com/eishay/jvm-serializers/wiki

См. Jackson:

http://jackson.codehaus.org/
https://github.com/FasterXML/jackson-xml-databind/wiki

А можно в апи в Account.Updatelist кроме параметра format(xml, json) добавить параметр new(1 - непрочтенные, 0 - прочтенные)? Вроде это реализовать просто, а места для маневров добавит значительно. Можно реализовать маленькое кэширование, доставать только новые - меньше тягать из инета, меньший объем для парсинга.

amid86 написал(а):
меньший объем для парсинга

По-моему глубокому убеждению, тема парсинга надумана. Я парсил XML на SoC с 200 МГц MIPS процессорами и 16 Мб RAM, не верю, чтобы надо ждать 5 секунд, чтобы распарсить каких-то несчастных 50 Кб на монструзоных устройствах под ARM / Freescale.

nimda, тема парсинга - возможно.
а вот тема объёма - нет. раз в 10-15мин грузить по 50кб на жпрс/эдже будет многовато.
актуально для абонентов теле2.