Главная » Разработка для Android » Объект Parcelable для передачи данных – Android

0

 

Хотя фреймворк Android поддерживает сериализацию Java, это обычно не лучший способ маршалинга состояния программы. Собственный внутренний протокол Android, предназначенный для сериализации, называется Parcelablе. Он легковесен, отлично оптимизирован, а работать с ним лишь немногим сложнее, чем с сериализацией. Это наилучший способ организации локальной межпроцессной коммуникации. Существуют причины (они будут совершенно очевидны, когда мы вернемся к рассмотрению объектов Pareelablе в подразделе «Классы, поддерживающие сериализацию» далее), по которым эти объекты нельзя хранить дольше, чем длится жизненный цикл приложения. Объекты Pareelablе – не лучший вариант для того, чтобы выполнять маршалинг состояния, например, в базу данных или файл.

Ниже показан очень простой объект, содержащий состояние. Рассмотрим, как сделать его parcelablе:

Чтобы быть parcelable, объект должен выполнять три требования: О он должен реализовывать интерфейс Parcelablе;

у него должен быть инструмент маршалинга, реализация метода интерфейса

writeToParcel;

у него должен быть инструмент демаршалинга, переменная publіс static fіnal с именем CREATOR, содержащая ссылку на реализацию Parcelablе. Creator.

Метод интерфейса writeToParcel – это инструмент маршалинга. Он вызывается применительно к объекту, когда этот объект необходимо сериализовать в Parcel. Задача инструмента маршалинга – записать всю информацию, необходимую для восстановления состояния объекта в получившемся Parcel. Как правило, под этим понимается выражение состояния объекта при помощи шести примитивных типов данных: byte, double, і n’t, float, long и String, Ниже показан уже рассмотренный простой объект, но с добавлением инструмента маршалинга:

Разумеется, точная реализация writeToParcel будет зависеть от содержимого сериализуемого объекта. В данном случае объект SimplePareel able имеет два компонента состояния, их оба он записывает в получаемый Parcel.

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

При выборе сериализованного представления обязательно следует учитывать изменения, которые могут произойти в данных позднее. Разумеется, в данном примере будет гораздо проще представить state как int, для получения значения которого вызывается state.ordinal. Однако при таком подходе будет достаточно сложно обеспечивать последующую совместимость объекта с более новыми версиями (forward compatibility). Предположим, нам требуется добавить в определенной точке новое состояние, State. IN IT, наступающее раньше состояния State. BEGIN. Такое простейшее изменение сделает новые версии объектов совершенно несовместимыми со старыми. Подобный, немного более слабый аргумент возникает при использовании state. toString для создания маршалируемого представления состояния.

Отображение объекта на его представления в Parcel происходит в рамках отдельно взятого процесса сериализации. Сериализация – это не обязательно неотъемлемый атрибут самого объекта. Вполне возможно, что конкретный объект будет иметь абсолютно разные представления в зависимости от того, какой механизм производит его сериализацию. Чтобы проиллюстрировать этот принцип (правда, это уже излишняя мера, раз уж тип State уже определен локально), необходимо отметить, что карта, используемая для маршалинга state, – это независимый и явно определяемый член класса pareelable.

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

В данном фрагменте показан лишь только что добавленный код инструмента демаршалинга: общедоступное статичное поле final, которое называется CREATOR, и содействующие ему компоненты. Поле является ссылкой на реализацию Parcel abl е. Creator<T>, где Т – тип parcel able-объекта, к которому применяется демаршалинг (в данном случае речь идет о SimpleParcelable). Все эти вещи необходимо делать правильно! Если CREATOR будет защищенным (protected), а не общедоступным (public), не будет статичным или будет записано как Creator, фреймворк не сможет произвести демаршалинг объекта.

Реализация Parcel abl е. Creator<T> – это объект с единственным методом createFromParcel, который выполняет демаршалинг одного и только одного экземпляра из Parcel. Идиоматический способ решения этой задачи заключается в считывании всех компонентов состояния из Parcel в том самом порядке, в каком эта информация записана в writeToParcel (это важно), и в последующем вызове конструктора с демаршализованным состоянием. Поскольку конструктор для демаршалинга вызывается из области видимости класса, данный конструктор может быть видим только для классов из того же пакета, в котором находится сам, или вообще закрыт (private).

Источник: Android. Программирование на Java для нового поколения мобильных устройств

По теме:

  • Комментарии