Командный паттерн вызова удаленных процедур (RPC) в Android

[@SabMakc]

А пробовали ли protobuf для сериализации?
Конечно, возможности несколько ограничены (в первую очередь из-за генератора классов по proto-файлам), но тем не менее позволяет организовать крос-платформенную сериализацию объектов.
Под андроидом завелось с использованием библиотеки protobuf-javame.

[@Evgenij_Popovich]

О protobuf, к сожалению, я слышу впервые. Справляется ли он автоматически с сериализацией новых типов объектов? Или каждый новый тип должен быть сконфигурирован?

[@SabMakc]

Тут как раз и кроется серьезное ограничение: каждый тип должен быть описан не на нативном языке, а в proto-файле.
По ним уже и генерируются классы на нужном языке (причем генераторы есть практически под все популярные языки).

[@Evgenij_Popovich]

Тогда это весьма неудобно, если у Вас штук 100 кастомных объектов. Есть ли тогда преимущества перед JSON? В статье я писал, что нативная сериализация выбрана потому, что с ней меньше всего возиться надо. Она работает «из коробки» для большинства собственных типов.

[@SabMakc]

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

[@SabMakc]

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

[@Evgenij_Popovich]

Спасибо, попробую почитать в свободное время. Gson, кстати, тоже, теоретически, поддерживает версионность и абстрактные типы.

[@gshock]

Во время REST-сервисов и JSON как стандарта обмена данными вы собираетесь гонять по сети бинарно-сериализованные Java-объекты? Я бы не советовал…

[@Evgenij_Popovich]

Если вы читали предисловие, то я рассматривал разные варианты, включая JSON. Также я указывал, что многие Android разработчики считают бинарную сериализацию злом. Но я не нашел причины, почему бы не использовать ее для проектов (хотя бы на начальной стадии разработки), когда есть куча кастомных объектов и необходим быстрый старт без заморочек с написанием кастомных сериализаторов и десериализаторов.

В принципе в будущем можно попытаться добавить опцию сериализации через JSON (gson) в библиотеку http-dispatch. Правда, в виду отсутствия опыта с JSON, я не знаю на какие грабли придется наткнуться.

[@Evgenij_Popovich]

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

[@gshock]

Идея паттерна очень здрава и полезна.
Но, когда я перешел на разработку под Android, то для себя осознал, что не всегда имеет смысл «переносить» сюда привычные enterprise-техники и подходы ввиду того, что приложение все-таки выполняется в очень ограниченной среде: ограниченный ресурс батарейки, ограниченны объем памяти etc. В конце концов не у каждого пользователя будет запас терпения, достаточный для ожидания пока пройдет сериализация-десериализация объектов. Я за простые решения. JSON это же просто текст и для его парсинга не нужно много усилий как может показаться сначала

[@Evgenij_Popovich]

Я недавно пытался немного почитать на тему JSON сериализации. Нашел такой пример: stackoverflow.com/questions/3629596/deserializing-an-abstract-class-in-gson/9106351#9106351. Неужели подобная сериализация/десериализация работает значительно быстрее нативной?

[@gshock]

Ну я про gson не говорил :) В Android есть встроенные классы для работы с JSON. Не обязательно использовать библиотеку, основанную на рефлексии.
Хотя в одном из проектов я применял gson и работает она довольно таки шустро

[@Evgenij_Popovich]

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

[@gshock]

Покажу кусочек кода:

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-парсинга

[@Evgenij_Popovich]

Спасибо

Это весьма похоже на то, с чем я столкнулся изучая ksoap2-android. Там также надо писать вручную сериализацию и десериализацию для каждого объекта. Это и пугало.

Представьте у вас сотня уже существующих кастомных POJO объектов из существующего Java приложения. В каждом может быть десяток и более полей. Хочется попробовать начать разрабатывать клиент под Android. Тут встает вопрос, что надо для начала написать подобную сериализацию и десериализацию хотя бы для половины объектов. Сразу опускаются руки и лень заставляет искать других решений.

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

[@gshock]

Погуглите тогда по ютубам, на одной из сессий в рамках google i/o рассказывали и показывали пример как дружить GAE с Андроидом. И там вроде как они обменивались POJO

[@Evgenij_Popovich]

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

[@gshock]

Да вроде нет, не c2dm (который кстати будет скоро выпелен и взамен предоставлен GCM)

[@gshock]

www.youtube.com/watch?v=dylFNrvZ_3U&list=PL56D792A831D0C362&index=83&feature=plpp_video
интересное с примерно 31-й минуты

[@Evgenij_Popovich]

Спасибо