Проект экосистемы сберкнижки
Существует три главных части к жизненному циклу передачи: создание, управление и освобождение. Сберкнижка обрабатывает середину; это позволяет пользователям просмотреть и управлять своими передачами и обеспечивает экранную интеграцию блокировки. Вы ответственны за два конца: создание передач и выплата передач.
Вы создаете и распределяете передачи
Вы ответственны за распределение передач в Ваших пользователей. Почта и Safari понимают, как работать с передачами — на iOS, они устанавливают передачи непосредственно, и на OS X они устанавливают передачи через iCloud — таким образом, можно использовать их для добавления передач. Ваше приложение может также установить передачи с помощью платформы Набора Передачи.
Передачи представлены и управляемы приложением сберкнижки
Вы управляете визуальным появлением путем указания стиля передачи, обеспечения изображений и выбирания текстового форматирования и цветов. Передачи содержат текст, изображения и штрихкод. Приложение Сберкнижки обрабатывает подробные данные расположения и представления передачи на экране для Вас, и это предоставляет интерфейс пользователю, чтобы управлять и удалить передачи.
Ваше приложение может взаимодействовать с передачами Используя набор передачи
Платформа Набора Передачи обеспечивает интерфейс Objective-C для приложений для взаимодействия с передачами в библиотеке Passbook. Сопутствующие приложения не должны копировать функциональность приложения Сберкнижки, скорее они должны обогатить пользовательский опыт путем выполнения вещей, которые Сберкнижка не может сделать, такие как разрешение пользователю попросить различное место на рейсе и затем обновлении передачи. Даже если пользователю не устанавливали Ваше приложение, передачи должны быть полезным использованием.
Ваше приложение может только взаимодействовать с передачами, идентификатор типа передачи которых соответствует права приложения — или передает Вас создаваемый или некоторое подмножество тех передач.
Ваш сервер может обновить передачи
Обновление передач является совместным усилием между Вашим сервером и Сберкнижкой. Когда информация о передаче изменяется, Ваш сервер отправляет уведомление нажатия устройству пользователя. Устройство связывается с Вашим сервером для обнаружения то, что изменилось и получить последнюю версию передач.
Передачи обновляются путем обеспечения последней версии передачи, не путем обеспечения списка того, что изменилось. Что-либо в передаче может быть обновлено за исключением идентификатора типа передачи и порядкового номера. Однако только определенные виды изменений фактически целесообразны пользователю. Обновление билета на поезд для отражения задержанного отбытия или магазинной карточки для показа текущего баланса держит передачу в курсе и не вызвало бы беспорядок. Замена купона для свободного порядка хлебных палочек с купоном для бесплатного напитка, вероятно, смутит пользователя — с точки зрения пользователя, один купон исчез, и другой купон был неожиданно добавлен. В этом случае необходимо создать новую передачу для купона напитка.
Вы ответственны за освобождение передачи
Политики относительно того, когда передачи допустимы или сколько раз они могут быть выплачены, являются Вашей ответственностью. Аналогично, эффекты выплаты передачи, такие как обновление баланса в Ваших записях ваше дело. Следующие разделы описывают несколько вариантов использования для передач и объясняют, как Вы могли бы реализовать их. Эти варианты использования иллюстрируют интересные идеи и подходы; они не предназначены, чтобы быть полностью работавшими решениями.
Передача для купона с одним разовым Использованием
Предположим, что Вы хотите выделить купон для 10 процентов от этого, может только использоваться один раз. Вы включаете уникальное число на каждом купоне от 1 до 500, и Вы пишете номера 1 - 500 на листке бумаги рядом с кассовым аппаратом. Когда кассиры вызывают купон, они консультируются с бумагой и вычеркивают число того купона.
Это работает над очень мелким масштабом и иллюстрирует принцип центральных доверяемых полномочий. Вы не управляете тем, что Ваши клиенты делают с их передачами или устройствами (или даже с их бумажными купонами), таким образом, Вы не можете использовать это в качестве начальной точки для доверчивой информации. Вместо этого Вы доверяете своей базе данных и используете передачу в качестве быстрого способа искать определенную запись. Данные в самой передаче являются просто снимком некоторого определенного состояния базы данных.
Выполнение его с передачами подобно: передача включает уникальный идентификатор в свой штрихкод, и Ваш сервер отслеживает, которых передачи все еще допустимы. При освобождении Вы сканируете штрихкод и консультируетесь с Вашим сервером, чтобы определить, допустима ли передача.
Не пытайтесь заставить одно разовое использование пройти только мимо предоставления передачи в единое устройство. Пользователи с многократными устройствами на iOS хотят Вашу передачу на всех их устройствах, и iCloud синхронизирует их передачи через устройства для них. Если Вы посылаете свою передачу по электронной почте Вашим пользователям, они могут переслать электронную почту и ее передачу. Ваша система сканирования и освобождения ответственна за проведение политики как “эта передача, только допустимо один раз”.
Не пытайтесь истечь или аннулировать передачу путем продвижения обновления. Обновления, как гарантируют, не будут поставлены: пользователь может не иметь сетевого соединения или, возможно, отключил обновления для передачи. Вместо этого обновите свою базу данных, чтобы указать, что передача недопустима, и консультируйтесь со своей базой данных, когда выплачена передача. Кроме того, Ваше приложение не должно удалять истекшие передачи без согласия пользователя.
Передача для магазинной карточки с балансом
Предположим, что Вам принадлежит кафе, и Ваши клиенты обычно платят переносами карты баланс, такой как подарочная карта или магазинная карточка. Подобный передаче с одним разовым использованием, Вам нужны данные, и она должна прибыть из защищенного источника. В этом случае необходимо было знать, была ли передача все еще допустима; в этом случае Вы хотите знать текущий баланс передачи.
Реализация подобна. Каждая передача имеет уникальный идентификатор в штрихкоде, сканирующемся при продаже. Прежде, чем совершить продажу, Вы консультируетесь со своим сервером, чтобы записать транзакцию и обновить баланс. Как только это сделано, кассир совершает продажу.
Вы могли проявить несколько подходов, чтобы проверить, что лицо, представляющее передачу, является фактически владельцем счета. Универсальная карта может включать изображение миниатюр, таким образом, Вы могли поместить изображение владельца счета на передачу. Для большей безопасности Вы могли сохранить изображение владельца счета в своей базе данных и вывести на экран его на экране кассира вместо того, чтобы доверять передаче. Другие подходы также возможны, таковы как выяснение удостоверения личности с фотографией.
В некоторый момент после продажи, Ваш сервер продвигает обновление к передаче с новым балансом. Это позволяет Вашим пользователям легко проверить свой баланс, поскольку он вывел на экран прямо на передаче. Это обновление может быть обработано различным сервером, реализующим веб-сервис API.
Передача для сезонного членства
Предположим, что Вы работаете на музей, поддерживающий Сберкнижку для ее годовых членств. Вы хотите позволить своим элементам использовать ту же передачу в течение всего года со случайными обновлениями для сохранения информации о вещественных доказательствах перемещения текущей.
Идеально, передаче нужен уникальный идентификатор в штрихкоде, который можно отсканировать во входе музея, чтобы проверить с сервером, что членство все еще допустимо. Однако это - ситуация, где возможно установить доверительные отношения, не консультируясь с Вашим сервером. (Например, если Ваши сканеры не имеют сетевого соединения.) В дополнение к уникальному идентификатору в штрихкоде, Вы теперь включаете год, что передача допустима, сопровождается криптографической подписью ID и год. Подпись позволяет Вам проверить, что содержание штрихкода прибыло из Вашего сервера и поэтому защищено.
Этот подход не позволил бы Вам реализовать купон с одним разовым использованием без доступа к сети в сканере; это - по существу неразрешимая проблема. Это работает здесь, потому что штрихкод содержит неизменный факт — год, что членство допустимо — и это - единственные данные, должен был определить, допустима ли передача все еще. Сканирование прохода в музей не изменяет состояния. Напротив, сканирование купона с одним разовым использованием действительно изменяет состояние: это аннулирует купон. Без доступа к сети в сканере нет никакого способа получить последнее состояние мира прежде, чем отсканировать или сообщить другим изменения состояния после сканирования.