Comments 21
А пробовали ли protobuf для сериализации?
Конечно, возможности несколько ограничены (в первую очередь из-за генератора классов по proto-файлам), но тем не менее позволяет организовать крос-платформенную сериализацию объектов.
Под андроидом завелось с использованием библиотеки protobuf-javame.
Конечно, возможности несколько ограничены (в первую очередь из-за генератора классов по proto-файлам), но тем не менее позволяет организовать крос-платформенную сериализацию объектов.
Под андроидом завелось с использованием библиотеки protobuf-javame.
0
О protobuf, к сожалению, я слышу впервые. Справляется ли он автоматически с сериализацией новых типов объектов? Или каждый новый тип должен быть сконфигурирован?
0
Тут как раз и кроется серьезное ограничение: каждый тип должен быть описан не на нативном языке, а в proto-файле.
По ним уже и генерируются классы на нужном языке (причем генераторы есть практически под все популярные языки).
По ним уже и генерируются классы на нужном языке (причем генераторы есть практически под все популярные языки).
0
Тогда это весьма неудобно, если у Вас штук 100 кастомных объектов. Есть ли тогда преимущества перед JSON? В статье я писал, что нативная сериализация выбрана потому, что с ней меньше всего возиться надо. Она работает «из коробки» для большинства собственных типов.
0
Библиотека умеет и JSON генерировать, но бинарный формат меньший объем занимает.
Преимущество скорее именно в кроссплатформенности. Описав один раз proto-файл, под все платформы можно сгененрировать свои файлы. Конечно, по функциям это скорее простые структуры, хотя тут от генератора больше зависит (видел генераторы, которые позволяют в сгенерированные файлы добавлять функционал, не боясь последующей перегенерации).
Преимущество скорее именно в кроссплатформенности. Описав один раз proto-файл, под все платформы можно сгененрировать свои файлы. Конечно, по функциям это скорее простые структуры, хотя тут от генератора больше зависит (видел генераторы, которые позволяют в сгенерированные файлы добавлять функционал, не боясь последующей перегенерации).
0
Во время REST-сервисов и JSON как стандарта обмена данными вы собираетесь гонять по сети бинарно-сериализованные Java-объекты? Я бы не советовал…
+1
Если вы читали предисловие, то я рассматривал разные варианты, включая JSON. Также я указывал, что многие Android разработчики считают бинарную сериализацию злом. Но я не нашел причины, почему бы не использовать ее для проектов (хотя бы на начальной стадии разработки), когда есть куча кастомных объектов и необходим быстрый старт без заморочек с написанием кастомных сериализаторов и десериализаторов.
В принципе в будущем можно попытаться добавить опцию сериализации через JSON (gson) в библиотеку http-dispatch. Правда, в виду отсутствия опыта с JSON, я не знаю на какие грабли придется наткнуться.
В принципе в будущем можно попытаться добавить опцию сериализации через JSON (gson) в библиотеку http-dispatch. Правда, в виду отсутствия опыта с JSON, я не знаю на какие грабли придется наткнуться.
0
Кстати, сейчас только глянул, Вы автор того самого топика о коммандном паттерне в GWT. Как Вы оцениваете саму идею использовать схожий паттерн в разработке под Android?
0
Идея паттерна очень здрава и полезна.
Но, когда я перешел на разработку под Android, то для себя осознал, что не всегда имеет смысл «переносить» сюда привычные enterprise-техники и подходы ввиду того, что приложение все-таки выполняется в очень ограниченной среде: ограниченный ресурс батарейки, ограниченны объем памяти etc. В конце концов не у каждого пользователя будет запас терпения, достаточный для ожидания пока пройдет сериализация-десериализация объектов. Я за простые решения. JSON это же просто текст и для его парсинга не нужно много усилий как может показаться сначала
Но, когда я перешел на разработку под Android, то для себя осознал, что не всегда имеет смысл «переносить» сюда привычные enterprise-техники и подходы ввиду того, что приложение все-таки выполняется в очень ограниченной среде: ограниченный ресурс батарейки, ограниченны объем памяти etc. В конце концов не у каждого пользователя будет запас терпения, достаточный для ожидания пока пройдет сериализация-десериализация объектов. Я за простые решения. JSON это же просто текст и для его парсинга не нужно много усилий как может показаться сначала
0
Я недавно пытался немного почитать на тему JSON сериализации. Нашел такой пример: stackoverflow.com/questions/3629596/deserializing-an-abstract-class-in-gson/9106351#9106351. Неужели подобная сериализация/десериализация работает значительно быстрее нативной?
0
Ну я про gson не говорил :) В Android есть встроенные классы для работы с JSON. Не обязательно использовать библиотеку, основанную на рефлексии.
Хотя в одном из проектов я применял gson и работает она довольно таки шустро
Хотя в одном из проектов я применял gson и работает она довольно таки шустро
0
Просто хочется достигнуть какого-то баланса между скоростью работы приложения и удобством и скоростью разработки. Писать сериализаторы и десериализаторы может быть довольно утомительно. И хотелось бы работать с привычными объектами как на сервере так и на клиенте, а не ассоциативными массивами. Поделитесь впечатлениями на сколько это рутинно работать с JSON?
0
Покажу кусочек кода:
Как видно то здесь больше parcel-необходимого кода, чем json-парсинга
public class Album implements JsonExtractable, Parcelable {
public int id;
public String name;
public int photosCount;
public boolean isCurrent;
public boolean isCanDeleted;
public boolean isEnabled;
public Album() {}
private Album(Parcel parcel) {
id = parcel.readInt();
name = parcel.readString();
photosCount = parcel.readInt();
isCurrent = parcel.readInt() == 1;
isCanDeleted = parcel.readInt() == 1;
isEnabled = parcel.readInt() == 1;
}
public String getNameWithCount(String photosSuffix) {
return name + " (" + photosCount + " " + photosSuffix + ")";
}
@Override
public void fromJson(JSONObject json) throws JSONException {
id = json.optInt("id", 0);
name = json.optString("name");
photosCount = json.optInt("photosCount", 0);
isCurrent = json.optBoolean("current");
isCanDeleted = json.optBoolean("canDeleted");
isEnabled = json.optBoolean("enabled");
}
@Override public String toString() { return name; }
public static final Creator<Album> CREATOR = new Parcelable.Creator<Album>() {
@Override
public Album createFromParcel(Parcel parcel) {
return new Album(parcel);
}
@Override
public Album[] newArray(int size) {
return new Album[size];
}
};
@Override public int describeContents() { return 0;}
@Override
public void writeToParcel(Parcel parcel, int flags) {
parcel.writeInt(id);
parcel.writeString(name);
parcel.writeInt(photosCount);
parcel.writeInt(isCurrent ? 1 : 0);
parcel.writeInt(isCanDeleted ? 1 : 0);
parcel.writeInt(isEnabled ? 1 : 0);
}
}
Как видно то здесь больше parcel-необходимого кода, чем json-парсинга
0
Спасибо
Это весьма похоже на то, с чем я столкнулся изучая ksoap2-android. Там также надо писать вручную сериализацию и десериализацию для каждого объекта. Это и пугало.
Представьте у вас сотня уже существующих кастомных POJO объектов из существующего Java приложения. В каждом может быть десяток и более полей. Хочется попробовать начать разрабатывать клиент под Android. Тут встает вопрос, что надо для начала написать подобную сериализацию и десериализацию хотя бы для половины объектов. Сразу опускаются руки и лень заставляет искать других решений.
Я уверен, что JSON сериализация хорошее решение. Но почему бы не заняться этим «узким местом» позже? В начале же для тестовых нужд использовать нативную сериализацию.
Это весьма похоже на то, с чем я столкнулся изучая ksoap2-android. Там также надо писать вручную сериализацию и десериализацию для каждого объекта. Это и пугало.
Представьте у вас сотня уже существующих кастомных POJO объектов из существующего Java приложения. В каждом может быть десяток и более полей. Хочется попробовать начать разрабатывать клиент под Android. Тут встает вопрос, что надо для начала написать подобную сериализацию и десериализацию хотя бы для половины объектов. Сразу опускаются руки и лень заставляет искать других решений.
Я уверен, что JSON сериализация хорошее решение. Но почему бы не заняться этим «узким местом» позже? В начале же для тестовых нужд использовать нативную сериализацию.
0
Погуглите тогда по ютубам, на одной из сессий в рамках google i/o рассказывали и показывали пример как дружить GAE с Андроидом. И там вроде как они обменивались POJO
0
Вероятно имеется в виду сервис C2DM. Где-то читал, что для взаимодействия в реальном времени он не очень подходит, т.к. такие переданные объекты могут и через сутки прийти.
0
Да вроде нет, не c2dm (который кстати будет скоро выпелен и взамен предоставлен GCM)
0
www.youtube.com/watch?v=dylFNrvZ_3U&list=PL56D792A831D0C362&index=83&feature=plpp_video
интересное с примерно 31-й минуты
интересное с примерно 31-й минуты
0
Sign up to leave a comment.
Командный паттерн вызова удаленных процедур (RPC) в Android