Об’єкт Parcelable для передачі даних – Android

&nbsp

Хоча фреймворк Android підтримує сериализацию Java, це звичайно не кращий спосіб маршалинга стану програми Власний внутрішній протокол Android, призначений для сериализации, називається Parcelablе Він легковагий, відмінно оптимізований, а працювати з ним лише небагато чим складніше, ніж з сериализацией Це найкращий спосіб організації локальної межпроцессной комунікації Існують причини (вони будуть абсолютно очевидні, коли ми повернемося до розгляду обєктів Pareelablе в підрозділі «Класи, що підтримують сериализацию» далі), за якими ці обєкти не можна зберігати довше, ніж триває життєвий цикл програми Обєкти Pareelablе – не кращий варіант для того, щоб виконувати маршалинга стану, наприклад, в базу даних або файл

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

Щоб бути parcelable, обєкт повинен виконувати три вимоги: Про він повинен реалізовувати інтерфейс Parcelablе

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

writeToParcel

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

Метод інтерфейсу writeToParcel – це інструмент маршалинга Він викликається стосовно до обєкта, коли цей обєкт необхідно серіалізовать в Parcel Завдання інструменту маршалинга – записати всю інформацію, необхідну для відновлення стану обєкта в отриманому Parcel Як правило, під цим розуміється вираз стану обєкта за допомогою шести примітивних типів даних: byte, double, и nt, float, long і String, Нижче показаний вже розглянутий простий обєкт, але з додаванням інструменту маршалинга:

Зрозуміло, точна реалізація writeToParcel залежатиме від вмісту Серіалізуемое обєкта У даному випадку обєкт SimplePareel able має два компоненти стану, їх обидва він записує в одержуваний Parcel

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

При виборі серіалізовані уявлення обовязково слід враховувати зміни, які можуть відбутися в даних пізніше Зрозуміло, в даному прикладі буде набагато простіше уявити state як int, для отримання значення якого викликається stateordinal Однак при такому підході буде досить складно забезпечувати подальшу сумісність обєкта з більш новими версіями (forward compatibility) Припустимо, нам потрібно додати в певній точці новий стан, State IN IT, наступає раніше стану State BEGIN Таке найпростіше зміна зробить нові версії обєктів абсолютно несумісними зі старими Подібний, трохи більш слабкий аргумент виникає при використанні state toString для створення маршаліруемого представлення стану

Відображення обєкта на його подання до Parcel відбувається в рамках окремо взятого процесу сериализации Серіалізация – це не обовязково невідємний атрибут самого обєкта Цілком можливо, що конкретний обєкт буде мати абсолютно різні уявлення залежно від того, який механізм виробляє його сериализацию Щоб проілюструвати цей принцип (правда, це вже зайва міра, раз вже тип State вже визначений локально), необхідно відзначити, що карта, використовувана для маршалинга state, – це незалежний і явно визначається член класу pareelable

SimpleParcelable, як було показано вище, компілюється без помилок Він навіть може маршаліроваться в пакет даних Але на даному етапі роботи отримати його назад ми не можемо Для цього нам буде потрібно інструмент демаршалінга:

У цьому фрагменті показаний лише тільки що доданий код інструменту демаршалінга: загальнодоступне статичне поле final, яке називається CREATOR, і сприяють йому компоненти Поле є посиланням на реалізацію Parcel abl е Creator , де Т – тип parcel able-обєкта, до якого застосовується демаршалінг (в даному випадку мова йде про SimpleParcelable) Всі ці речі необхідно робити правильно Якщо CREATOR буде захищеним (protected), а не загальнодоступним (public), що не буде статичним або буде записано як Creator, фреймворк не зможе призвести демаршалінг обєкта

Реалізація Parcel abl е Creator – Це обєкт з єдиним методом createFromParcel, який виконує демаршалінг одного і тільки одного примірника з Parcel Ідіоматичний спосіб вирішення цієї завдання полягає в зчитуванні всіх компонентів стану з Parcel в тому самому порядку, в якому ця інформація записана в writeToParcel (це важливо), і в наступному виклику конструктора з демаршалізованним станом Оскільки конструктор для демаршалінга викликається з області видимості класу, даний конструктор може бути бачимо тільки для класів з того ж пакета, в якому знаходиться сам, або взагалі закритий (private)

Джерело: Android Програмування на Java для нового покоління мобільних пристроїв

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*