URLProtocol: как превратить в URL всё что угодно
Публикуем второй доклад из серии митапа VK Tech Talks | iOS, в котором разработчик Алексей Цветков-Омеличев рассказывает, как сделать URLProtocol, зачем вообще его использовать, и как его используют в приложениях «ВКонтакте»
URLProtocol в повседневной жизни используется для сайтов с протоколами http и https, однако его возможности выходят за пределы веб-навигации. Возможно, когда-нибудь вы видели magnet-ссылки для торрентов, или же tg-ссылки для открытия контента в приложении Telegram. Как заметил разработчик ВКонтакте Алексей Цветков-Омеличев, это очень удобная вещь. О том, как использовать URLProtocol для обмена данными внутри приложения и между приложениями, и что можно с ним сделать, читайте далее.
Предположим, что с помощью структуры мы описываем какую-то условную собаку, у которой есть порода. И второе свойство говорит о наличии у неё сутулости. Такая схема очень удобно ложится на URL.
Разные объекты ведут себя по-разному: есть объекты, которые выполняют какую-то важную функцию (например, обрабатывают изображения, входят в сеть), другие имеют описательный характер, которые можно уложить в URL. Что подводит к выводу, что всё вокруг нас — URL. При желании характеристику любого объекта (автомобиля, здания, животных и т. д.) можно уложить в некоторый URL.
Полтора года назад, когда разрабатывался новый раздел сообщений в приложении «ВКонтакте», использовался простой класс URLImageView, который содержал метод render. Данный метод умел следующее: ему передавали URL, он с помощью какой-то сессии выполнял запрос к серверу, к определённой картинке, загружал её, обрабатывал данные и устанавливал свойства Image, таким образом отрисовывал.
Однажды появилась задача: нужно было добавить возможность в приложение — выбирать какую-то картинку из «Галереи», накладывать на неё определённый фильтр, обрезать, поворачивать и затем передавать непосредственно в сообщения, и отправлять. URLImageView не умел это делать, но зато это мог сделать AssetService.
Неполный список того, что умеет AssetService:
Структура проекта выглядит следующим образом: есть основной проект VKClient, и у него есть две ссылки на проекты — messages и PhotoPicker. И задача заключалась в том, чтобы подружить эти два проекта и иметь возможность работать в сообщениях с AssetService.
Это решается следующим образом:
- Вываливаем AssetService, закрываем большим количеством протоколов.
- Пишем свою стерилизацию для вязкости, ведь нужно уметь сохранять этот Asset между перезапуском приложения, чтобы ещё не отправленное сообщение также показывало картинки, которые мы отправили.
- Своя реализация кэша сверху.
- Закидываем в какой-нибудь сервис или менеджер, который будет всем этим управлять и взаимодействовать с AssetService.
Такое решение не устраивало. И поэтому был создан AssetURLProtocol.
Структура проекта стала выглядеть так:
Был определен некоторый формат ссылки, который описывал требования. Выглядело это так:
Рассмотрим на примере, как реализовать свой URLProtocol. Предположим, что есть обычный список из снэпшотов карт, который нужно отобразить.
Стоит отметить, что при работе с URLProtocol часто встречаются два типа данных — URLProtocol и URLProtocolClient. Их особенность в том, что, несмотря на название, URLProtocol является классом, а URLProtocolClient — протокол. Главное не запутаться.
Для начала определим ссылку. Предположим, что она будет выглядеть так:
У неё будет схема Map, а по координатам будем получать какой-то снэпшот. Назовём протокол MapURLProtocol:
Чтобы реализовать протокол, необходимо в первую очередь унаследоваться от базового класса URLProtocol и реализовать, как минимум, четыре необходимых метода:
- Первый будет предназначен для того, чтобы можно было бы понять, что данный URLProtocol умеет обрабатывать подобного вида ссылки.
- Второй метод предназначен для того, чтобы привести запрос к некому каноничному виду.
- В методе startLoading происходит загрузка всех данных.
- Последний метода stopLoading, который вызывается, когда работа протокола по какой-то причине была завершена (отмена, выполнение с ошибкой, успешное выполнение).
Внутри метода разобьём URL на компоненты и передадим дальше, непосредственно, в метод загрузки.
В методе загрузки обращаемся, непосредственно, к MapSnapshotter, который есть в MapKit. Какими-то параметрами его проинициализируем. После завершения его работы получим данные картинки и передадим в метод завершения запроса.
Это один из самых важный этапов в работе URLProtocol. Здесь, во-первых, нужно правильно сформировать URLResponse. Также необходимо выполнить последовательно, в нашем случае, три метода, вызвать его у URLProtocolClient. URLProtocolClient — это некоторое прокси между URLProtocol и URL Loading Sisteme. Нам необходимо ему [URLProtocolClient] правильно сообщать о состояние, чтобы URL Loading Sisteme могла корректно реагировать и выполнять определённые действия. Необходимо сообщать: о получении ответа, были загружены какие-то данные, а также о том, что работа протокола завершена. Вызов этих методов может отличаться в зависимости от реализации URLProtocol.
Также необходимо корректно оповещать URLProtocolClient о том, что произошла какая-то ошибка. Именно эта ошибка пойдёт в Completion Handler.
Необходима URLSession для того, чтобы выполнять запросы.
А также уже знакомый URLImageView, у которого очень простой код: когда рендерим URL, создаём request и в сессии выполняем его; в Completion Handler берём готовую картинку и устанавливаем её в свойство image.
Предположим, что код View Controller содержит обычный UICollectionViewController с какими-то квадратными ячейками, внутри которых лежит URLImageView, а модели находится просто массив вот таких ссылок:
Но есть один нюанс — каждый раз, когда выполняется новый запрос, когда скроллим и пытаемся порендерить новый URL внутри URLProtocol, раз за разом попадаем в метод startLoading, загружаем снова через снэпшотер картинку и возвращаем её.
Что приводит к вопросу:
Процесс работы кэша можно разделить на очевидных этапа.
Первый этап — запись.
Во время конфигурации сессии можно указать URLCache, который будет использоваться для кэширования ответов на запросы. Это не единственное, что нужно.
На предыдущем слайде можно заметить, что когда завершали выполнение URLProtocol и обращались к URLProtocolClient, также была указана политика кэширования. Она нужна для того, чтобы URLProtocolClient передал её дальше в URL Loading System, а она на основании этого приняла решение: нужен ли вообще ответ на запрос или нет.
Формируется CachedURLResponse — простой объект, в который передаются непосредственно данные и response, который имеет информацию. И если у URL Loading System есть объект, который ссылается на какой-то URLCache, значит есть на него ссылка, и можно сохранить ответ на запрос с помощью метода storeCachedResponse.
CachedURLResponse — это довольно простой тип данных, это просто класс, внутри которого, помимо всего прочего, хранятся данные и информация для него, которая и есть набор необходимых данных, который необходим, чтобы определить, что нужно ли вернуть такой ответ или как-то его сохранить.
Как читается запрос на ответ если есть он в кэше?
Когда формируется URLRequest, при загрузке при рендеринге URL/URLImageView, помимо URL, также можно указать политику кэширования. По умолчанию указывается политика NSURLProtocol — CachePolicy.
Под капотом URL Loading System уже организовано, как работать с HTTP/HTTPS-запросами, нужно ли возвращать для них уже закэшированный ответ или нет.
В политике кэширования можно указать возвращение кэшированных данных, и загружаем, если их нет. В таком кейсе при создании сущности URLProtocol прямо на вход на инициализацию придёт в параметре cachedResponse, который затем будет сохранён в свойства и его можно будет обработать.
Единственное, что останется — это в методе startLoading проверить, что в этом свойстве что-то есть. Если есть, то можно сразу завершить выполнение запроса с этими данными, а если нету, то продолжаем загрузку.
Для того чтобы кэш работал, необходимо:
Но есть нюанс — при реализации URLProtocol можно столкнуться с рядом крашей.
Примеры, как решали во «ВКонтакте» проблемы при реализации URLProtocol:
Какая практическая польза от реализации URLProtocol?
В приложении «ВКонтакте» активно используют URLProtocol. Ниже приведены некоторые из них.
VKPPURLProtocol, который помогает загружать картинки из галереи, делает всю работу по их обработке и выдаёт уже готовые результаты.
Уже известный из примера MapURLProtocol. В разделе сообщений есть большое количество аттачей, это могут быть фотографии, видео, граффити, стикеры и карты, в том числе. Чтобы карты работали как картинки (также загружались, имели одинаковый кэш), был создан URLProtocol.
PollBackgroundURLProtocol используется для отрисовки красивых фонов в опросах.
AvatarURLProtocol, который позволяет в списке бесед в разделе сообщений, очень удобно указать от одной до четырёх ссылок к этому протоколу, он их обрабатывает, формирует сетку и выдаёт готовый результат.
Из недостатков URLProtocol можно отметить:
Преимуществами URLProtocol являются:
Вот и всё!
URLProtocol позволяет удобно обмениваться данными и поддерживается всеми популярными ОС, так что если вы разработчик, возможно, самое время попробовать этот способ.
Посмотреть презентацию можно тут.
Ознакомиться с полным выступлением можно в видеозаписи:
Текст: Лена Гамель, Арсений Метелев
Фото и слайды: VK Tech