WWDC 2011: iCloud, по другую сторону экрана

Для пользователей iCloud – магия. Заколдованные этой магией данные достаточно ввести на одном из устройств, и они моментально появляются на всех устройствах пользователя. С точки зрения разработчика, решившего “заколдовать” свои приложения, освоение iCloud не было непреодолимо сложным – но… iCloud был очень непрост для тех, кто разрабатывал эту технологию. После её презентации скептики, усмехаясь, заявляли что весь этот iCloud можно разработать за две-три недели, не особенно перенапрягаясь. Интересно, почему до июня 2011 года никто этого не сделал?

Допустим, просто не догадались – подобные глупости могли прийти в голову ненормальной Apple и больше никому. Но почему что-то вроде iCloud появилось через несколько лет после того как очередная глупость от Apple вышла в свет и оказалась не такой уж и глупостью?

А заявления некоторых СМИ о том что Apple “изобрела облачные технологии”, к чему Apple не имела никакого отношения, не остались без ответа. Волны испепеляющей критики обрушились… на Apple.

Apple пришлось сделать официальное заявление – эти технологии существовали задолго до iCloud. Более того, iCloud не был первым случаем применения облачных технологий самой Apple.

Примеры? Электронная почта с помощью IMAP, контакты и календари с помощью CalDav, iTunes Store. В App Store и Mac App Store облачные технологии применялись при загрузке приложений на компьютеры пользователей и при их обновлениях.

iCloud разработан инженерами с опытом участия в этих проектах.

А свой iCloud за две-три недели? С него мы и начнем…

Это продолжение серии про WWDC 2011, предыдущие части здесь:
Первая часть: WWDC 2011: Apple уходит на облака…;
Вторая часть: WWDC 2011: Про убийство.

Как создать собственный сервис, аналогичный iCloud?

Как утверждали скептики, элементарно. Хорошо, отвечали им разработчики iCloud, пусть кто-нибудь попробует. Это и в самом деле несложно.

Для этого надо:

— Подобрать, установить и сконфигурировать серверы, обеспечить их бесперебойную круглосуточную работу;
— Создать протокол сервиса;
— Написать огромное количество исходных кодов для сервера и для клиентов;
— Организовать своевременную отправку, доставку и прием уведомлений (пользователям нравится, когда синхронизация случается немедленно);
— Обеспечить синхронное архивирование на случай восстановления после нештатных ситуаций;
— Обеспечить срочную и круглосуточную техническую поддержку всего этого;

И еще пара-другая разных “надо”.

Даже если не ставить перед собой глобальные задачи, и попытаться разработать сервис рассчитанный на десяток-другой клиентов, на базе стандартных протоколов и стандартных технологий, а в качестве сервера решено использовать списанный PC-бокс, купленный за пару десятков долларов, что-то вполне может получиться.

Но все равно это обойдется дороже и хлопотнее, чем применение iCloud. Тем более что он написан не худшими в мире инженерами, и “просто работает”.

А для встраивания приложения в его инфраструктуру даже не потребуется Mac. Почему на привычные для Apple не слишком умные замечания компания ответила.

Для создания сервиса уровня iCloud требуются возможности Google или Microsoft.

iCloud для прикладных разработчиков

По сравнению с созданием собственного аналога, интегрировать приложение в iCloud было несложно.

Для подключения приложения к сервису iCloud, требовалось:

— Иметь представление об «анатомии» iCloud (прочитать его описание до конца, хотя бы один раз)
— Решить, как именно приложение должно взаимодействовать с iCloud, и продумать взаимодействие с целью уменьшения трафика
— Зарегистрировать в приложении его «владения на облаках»
— Используя iCloud API, реализовать продуманное во втором пункте

Третий пункт делал размещение приложения в Mac App Store обязательным. То есть, ко всем другим заботам добавлялось соответствие требованиям приемщиков этого магазина. Хороший повод еще раз подумать.

Регистрация владений была несложной: в список прав (entitlements) добавлялся ключ или ключи для работы с хранилищами iCloud.

В наши дни процесс регистрации владений упрощен, в 2011 он выполнялся вручную, выглядело это, например, так:


com.apple.developer.ubiquity-container-identifiers
0102030405.chanadu.TheApp.ipad
0102030405.chanadu.TheApp.iphone
com.apple.developer.ubiquity-kvstore-identifier
0102030405.chanadu.TheApp.kvstore


Взаимодействие с сервисом нетривиально, но iCloud API упрощали этот процесс почти до безобразия.

В OS X управление взаимодействием встроили в класс NSDocument, добавив полдюжины новых классов которые брали на себя нетривиальные частности (разрешение конфликтов, поиск, хранение версий). Новые классы использовались еще в нескольких новшествах OS X Lion.

До пятой версии в iOS для работы с документами (например, документами MS Word или Numbers) использовался суррогатный класс – в iOS 5 появился класс UIDocument, почти полная копия “настоящего”, но учитывающий местную специфику.

Теоретически все было несложно, на практике существенно сложней, особенно в первый раз.

Краткий очерк анатомии iCloud

Пользователю (точнее, Apple ID пользователя, их можно заиметь сколько угодно, за так и без особых усилий) выделялось 5 Гигабайт облачной памяти. Увеличение квоты в первые месяцы существования iCloud было невозможно, ни за какие деньги. Платное увеличение квоты было встречено овациями – но об этом когда-нибудь потом.

Данные всех программ пользователя, размещенные в облаках, в сумме, выйти за пределы квоты не могли. Но были кое-какие подробности.

Во-первых, некоторые данные контролируемые программами Apple, размещались вне квоты.

Во-вторых, хранилища были двух типов. Одно хранило документы. Разработчик решал что и как сохранять на облаке – в наставлениях был целый раздел, обучавший его экономному ведению хозяйства. Второе хранило пары “ключ-значение”, вне квоты, но с массой других ограничений. У приложения могло быть только одно хранилище этого типа, по размеру оно не могло превышать 64 К, а пара “ключ-значение” не могла быть больше 4 К.

Зато разрешалось использовать один комплект хранилищ для нескольких программ. Apple приводила пример с вариантами Lite и Pro, которые работали с документами одного типа, и могли быть установлены на разных устройствах пользователя. От себя добавлю еще более распространенный случай: приложение существующее в вариантах для OS X и iOS – это на самом деле, как минимум, два разных приложения.

И напоследок о конфликтах: имеются в виду не конфликты между разработчиками, и даже не их конфликты с менеджерами и руководством компании. Существовала теоретическая, как казалось всем кто сталкивался с iCloud впервые, возможность внесения изменений в тот же документ одновременно с нескольких устройств. Увы, чисто практическая.

Можно было бы рассказать еще много интересных вещей про iCloud, но в серии это не последняя тема.

Продолжение следует

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

Источник