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 він виконувався вручну, виглядало це, наприклад, так:

Взаємодія з сервісом нетривіальна, але 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, але в серії це не остання тема.

Продовження слід

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