Url vk: Как получить URL-адрес записи в социальных сетях?

Содержание

Как получить URL-адрес записи в социальных сетях?

Запись (публикация, твит и т.д.) в социальной сети – это сообщение, публикуемое пользователем в своём аккаунте, странице или сообществе (группе). Каждая такая запись обычно доступна на отдельной странице, которая имеет свой уникальный URL-адрес. В данной статье я хочу помочь Вам разобраться, как получить такой URL-адрес записи в социальных сетях: Google+, Facebook, Вконтакте, Twitter и Мой Мир@Mail.ru

Содержание:

URL-адрес записи в соцсетях

Социальная сеть (англ. social network) – это Интернет ресурс, предназначенный для построения, отражения и организации социальных взаимоотношений. Основой таких взаимоотношений является общение, построенное на обмене информацией, публикуемой в виде хронологически упорядоченных записей. В большинстве случаев, каждая из них имеет свой уникальный URL-адрес. О том, как его получить читайте дальше.

URL-адрес записи в Google+

Google+ – проект социальной сети компании Google.

Чтобы получить URL-адрес записи в Google+, вы можете воспользоваться функцией «Получить ссылку». Для этого найдите в ленте интересующую Вас запись и наведите на неё курсор мыши. В правом вернем углу записи, появится иконка «Действия» (стелочка вниз) – кликните её. В открывшемся контекстном меню найдите и кликните пункт «Получить ссылку».

В открывшемся окне вам будет предоставлена ссылка записи, просто скопируйте её и нажмите кнопку «Готово».

URL-адрес публикаии в Facebook

Facebook (Фейсбук) – одна из крупнейших социальных сетей в мире, основанная Марком Цукербергом и его соседями по комнате во время обучения в Гарвадском университете в 2004 году.

В социальной сети Facebook нет отдельной функции для получения URL-адрес публикации. Тем не менее, в качестве таковой вы можете использовать ссылку «временной метки» (дата публикации).

Для этого найдите в ленте интересующую Вас запись и кликните ссылку «временной метки», которая находится в верхнем левом её углу, рядом и именем автора.

Вам останется лишь скопировать полученный URL-адрес публикации из адресной строки Вашего браузера.

Примечание: у каждого типа публикации в Facebook имеется свой формат URL-адреса. Интересным здесь является динамический вариант отображения фотографии во всплывающем окне, что происходит из-за наличия параметра theater в URL-адресе публикации.

Для наглядности, я хочу предложить Вашему вниманию видео «How to Get Facebook Post Url» от howtechweb. Оно немного устарело, но суть осталась та же.

URL-адрес записи во ВКонтакте

ВКонтакте (VK.com) – крупнейшая социальная сеть в Европе, принадлежащая Mail.Ru Group. В социальной сети ВКонтакте у записей имеется два варианта URL-адреса –

статичный (на отдельной странице) и динамичный (во всплывающем окне).

Для получения статичного URL-адреса записи на отдельной странице, наведите курсор на временную метку записи и щелкните правую кнопку мыши. В открывшемся контекстном меню кликните пункт «Копировать адрес ссылки».

URL будет иметь вид: http://vk.com/wall58447324_841

Для получения динамического URL-адреса записи во всплывающем окне, кликните «временную метку» (дату публикации) записи на стене, чтобы запись открылась во всплывающем окне и скопируйте URL-адрес записи из адресной строки Вашего браузера.

Он будет иметь вид: http://vk.com/wmas.online?w=wall58447324_841

Примечание: во ВКонтакте отдельный URL-адрес имеют не только записи, но и прикреплённые к ним файлы. Например, кликнув прикреплённую к записи фотографию, оно откроется во всплывающем окне по динамической ссылке вида: http://vk.com/wmas.online?z=photo58447324_346975387%2Falbum58447324_00%2Frev – если же открыть картинку в новой вкладке браузера, мы получим статический вариант URL-адреса: http://vk.com/photo58447324_346975387 – но тоже во всплывающем окне.

Как получить ссылку на статус в Twitter?

Проще всего получить ссылку на статус в сервисе микроблогов Twitter. Для этого вы можете кликнуть временную метку или ссылку «Подробнее», которая появится, если предварительно кликнуть ссылку «развернуть».

На открывшейся странице, просто скопируйте URL-адрес статуса из адресной строки браузера и используйте её, например: twitter.com/wmas/status/402685686911754240. Нужно ли напоминать, о настройке конфиденциальности в разделе «Безопасность и конфиденциальность» твиттер аккаунта?

Как получить ссылку на запись в Мой Мир@Mail.ru?

Особенностью социальной сети Мой Мир@Mail.ru является то, что здесь не особо то и любят, когда пользователи делятся ссылками. По крайней мере, в форме статуса есть возможность прикрепить только фото, видео и музыку. Если указать ссылку, данные по ней считаны не будут. Для того чтобы поделиться ссылкой на понравившийся вам материал предлагается использовать кнопку, которая должна быть установлена на сайте, или воспользоваться формой по этому адресу: connect.mail.ru/share. К теме моей статьи это не относится, но мне показалось не лишним уточнить данный вопрос.

Теперь что касается ссылки на статус в социальной сети Мой Мир@Mail.ru. По сути, здесь, как и в предыдущих случаях, ссылка находится у временной отметки. Вы можете подвести курсор и кликнуть пункт «Копировать ссылку» из контекстного меню браузера или кликнуть ссылку и скопировать URL-адрес из адресной строки браузера, они будут идентичны, например: my.mail.ru/mail/lunux/share?shareid=AF0A000015A88003.

Настроить доступ к своему аккаунту, можно перейдя по ссылке «настройки» в верхнем правом углу страницы, выше синей полоски, рядом со ссылкой «выход».

Подведём итоги добычи ссылок на статусы в соцсетях

Как вы видите, ничего сложного в том, чтобы получить ссылку для статуса, записи, сообщения и т.д. в любой из социальных сетей нет. Просто вам нужно знать определенные нюансы каждого из онлайн сервисов и использовать подручные средства. Ну и главное:

ссылка обычно находится у временной метки. Надеюсь, что моя статья была вам полезна, и вы поделитесь ею со своими друзьями. На этом у меня всё. Спаси за внимание. Удачи!

Короткая ссылка: http://goo.gl/C7DHQK

Сократить ссылку онлайн для Facebook, VK, Instagram, Twitter ✔ PROject SEO

Процедура сокращения ссылок стала обычной для современного человека. Ведь длинный УРЛ адрес не всегда бывает привлекательным. А порой его длина может стать весомой проблемой с точки зрения продвижения ресурса в сети. Пользователи будут проходить мимо, не обращая внимания на непонятный набор букв и символов вместо цепляющего названия ссылки. К основным причинам укорачивания ссылок относятся:

необходимость проведения рекламных кампаний и частой рассылки доменов. Укороченные ссылки удобны для диктовки во время оффлайн маркетинга по телефону, либо для формирования рекламы в социальных сетях;
наличие необходимости сокрытия идентификатора партнеров. Сжатие ссылки возможно вместе с реферальным адресом;
улучшение зрительного восприятия ссылки посетителями ресурса.

Чтобы более полно ощутить важность данной процедуры, стоит подробнее рассмотреть влияние каждой из причин на результативность рекламной кампании ресурса.

Экономия длины сообщений

Данная причина уместна, когда реклама ресурса проводится на площадках в социальных сетях и прочих источниках, которые нередко ограничивают длину рекламного поста. Ярким примером является социальная сеть Твиттер, которая жестко ограничивает длину рекламных сообщений, из-за чего возникает ряд дополнительных проблем при продвижении ресурса внутри площадки. Твиттер способен самостоятельно обрезать ссылки путем использования личного интегрированного интерфейса.

Сокращение как способ предотвращения непреднамеренного сокращения УРЛ

Интернет-маркетинг предполагает частое использование особых тегов в создании УРЛ – ссылок. В результате чего они получаются порой необоснованно длинными. Теги нужны для получения дополнительной информации. Например, о том, откуда приходит основной трафик.

При копировании ссылки некоторые пользователи выделяют ее не всю, а обрезают вручную важную часть. Таким образом делая ее нерабочей или некорректной. При помощи сокращения ссылок без потери смысла такой проблемы можно будет в дальнейшем избежать.

Чтение ссылки вслух

Выше упоминалось о том, что иногда, например, в оффлайн маркетинге, необходимо продиктовать ссылку в устной форме. Например, в процессе обзвона клиентов по теплым и холодным базам. Сокращение ссылок поможет решить проблему нечитаемых символов и слишком длинного набора букв. Кроме того, есть ресурсы, позволяющие делать ссылки удобными для чтения русскоговорящим пользователям. Например, заменяя данные русскими буквами без потери смысла.

Сбор аналитики и статистики

Популярность данного вида услуги обусловлена не только лаконичностью и наглядностью полученного результата. При помощи грамотно проведенного сокращения ссылки можно получить дополнительную информацию, например, статистику посещаемости. При выборе сервисов важно обращать внимание на пункт выдачи аналитических и статистических данных в процессе работы. Поскольку не все современные ресурсы предоставляют клиентам такие услуги.

Эффективная манипуляция пользователями

Некоторые недобросовестные или мошеннические сайты намеренно сжимают ссылки с целью сокрытия важной информации и подсказок от посетителей. К примеру, метка .exe продвинутому пользователю даст точную подсказку о том, что, скорее всего, на сайте или в файле может содержаться вирус. Кроме того, такие ссылки могут тайно перенаправлять пользователей на ресурсы, вредящие психологическому здоровью. А также просто на вредоносные интернет-площадки.

В связи с последней причиной многие ресурсы стали фильтровать ссылки, поступающие на обработку. Если человек беспокоится за безопасность ссылок, можно воспользоваться ресурсами, предоставляющими услугу расшифровки данных сокращенных ссылок и адресов.

All you need is URL / Блог компании ВКонтакте / Хабр

Ежедневно пользователи ВКонтакте обмениваются 10 млрд сообщений. Они отправляют друг другу фотографии, комиксы, мемы и другие вложения. Расскажем, как в iOS-приложении мы придумали загружать картинки с помощью

URLProtocol

, и пошагово разберём, как реализовать свой.

Примерно полтора года назад в самом разгаре была разработка нового раздела сообщений в приложении VK для iOS. Это первый раздел, полностью написанный на Swift. Он разместился в отдельном модуле

vkm

(VK Messages), который ничего не знает про устройство основного приложения. Его даже можно запустить в отдельном проекте — базовая функциональность чтения и отправки сообщений при этом продолжит работать. В основное приложение контроллеры сообщений добавляются через соответствующие Container View Controller для отображения, например, списка бесед или сообщений в беседе.

Сообщения — один из самых популярных разделов мобильного приложения ВКонтакте, поэтому важно, чтобы он работал как часы. В проекте messages мы бьёмся за каждую строчку кода. Нам всегда очень нравилось, как аккуратно сообщения встроены в приложение, и мы стремимся к тому, чтобы всё так и оставалось.

Постепенно наполняя раздел новыми функциями, мы подошли к следующей задаче: нужно было сделать так, чтобы фотография, которая прикрепляется к сообщению, сначала отображалась в черновике, а после отправки — в общем списке сообщений. Мы могли бы просто добавить модуль для работы с PHImageManager, но дополнительные условия делали задачу сложнее.

При выборе снимка пользователь может его обработать: наложить фильтр, повернуть, обрезать и т. д. В приложении VK такая функциональность реализована в отдельном компоненте AssetService. Теперь нужно было научиться работать с ним из проекта сообщений.

Что ж, задача довольно простая, будем делать. Такое вот примерно решение усреднённое, потому что вариаций масса. Берём протокол, вываливаем его в messages и начинаем наполнять методами. Добавляем в AssetService, адаптируем протокол и добавляем свою реализацию КЕША! для вязкости. Потом заносим реализацию в messages, добавляем в какой-нибудь сервис или менеджер, который будет работать со всем этим, и начинаем использовать. При этом ещё приходит новый разработчик и, пока пытается разобраться во всём этом, приговаривает полушёпотом… (ну вы поняли). При этом у него на лбу аж пот выступает.

Такое решение нам было

не по вкусу

. Появляются новые сущности, о которых нужно знать компонентам сообщений при работе с изображениями из

AssetService

. Разработчику также нужно провести дополнительную работу, чтобы разобраться, как устроена эта система. Наконец, появлялась дополнительная неявная завязка на компоненты основного проекта, чего мы стараемся избегать, чтобы раздел сообщений и дальше продолжал работать как независимый модуль.

Хотелось решить задачу так, чтобы проект вообще ничего не знал о том, что за картинка выбрана, как её хранить, нужно ли её по-особенному загружать и рендерить. При этом у нас уже есть возможность загрузки обычных изображений из интернета, только они загружаются не через дополнительный сервис, а просто по URL. И, по сути, разницы между этими двумя типами изображений нет. Просто одни хранятся локально, а другие — на сервере.

Так мы пришли к очень простой идее: а что, если локальные ассеты тоже можно научиться загружать через URL? Кажется, что это одним щелчком

~~Таноса~~ пальцев решило бы все наши проблемы: не нужно ничего знать про AssetService, добавлять новые типы данных и зря увеличивать энтропию, учиться загружать новый тип изображений, заботиться о кешировании данных. Звучит как план.

Всё, что нам нужно, — URL

Мы обдумали эту идею и решили определить формат

URL

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

asset://?id=123&width=1920&height=1280

В качестве

id

будем использовать значение свойства

localIdentifier

PHObject

, а для загрузки изображений нужного размера передадим параметрами

width

height

. Также добавим ещё несколько параметров вроде

crop

filter

rotate

, которые позволят работать с информацией обработанного изображения.

Для обработки таких URL мы создадим AssetURLProtocol

class AssetURLProtocol: URLProtocol {
}

Его задача — загружать изображение через

AssetService

и возвращать обратно уже готовые к использованию данные.

Всё это позволит нам почти полностью делегировать работу URL-протоколу и URL Loading System.

Внутри сообщений можно будет оперировать самыми обычными URL, только другого формата. Также появится возможность переиспользовать уже существующий механизм по загрузке изображений, очень просто сериализовать в БД, а кеширование данных реализовать через стандартный URLCache.

Получилось ли? Если, читая эту статью, вы можете в приложении ВКонтакте прикрепить к сообщению фотографию из галереи, то да 🙂

Чтобы было понятно, как реализовать свой

URLProtocol

, предлагаю рассмотреть это на примере.

Поставим себе задачу: реализовать простое приложение со списком, в котором нужно по заданным координатам отображать список снапшотов карт. Для загрузки снапшотов будем использовать стандартный MKMapSnapshotter из MapKit, а загрузку данных реализуем через кастомный URLProtocol. Результат может выглядеть примерно так:

Сначала реализуем механизм загрузки данных по

URL

. Для отображения снапшота карты нам необходимо знать координаты точки — её широту и долготу (

latitude

longitude

). Определим формат кастомного

URL

, по которому хотим загружать информацию:

map://?latitude=59.935634&longitude=30.325935

Теперь реализуем

URLProtocol

, который будет обрабатывать такие ссылки и формировать нужный результат. Создадим класс

MapURLProtocol

, который унаследуем от базового класса

URLProtocol

. Несмотря на своё название,

URLProtocol

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

URLProtocol

представляет именно

URL

-протокол и к терминам ООП отношения не имеет. Итак,

MapURLProtocol

class MapURLProtocol: URLProtocol {
}

Теперь переопределим несколько обязательных методов, без которых

URL

-протокол работать не будет:

1.

canInit(with:)

override class func canInit(with request: URLRequest) -> Bool {
   return request.url?.scheme == "map" 
}

Метод

canInit(with:)

необходим, чтобы указать, какие типы запросов наш

URL

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

URL

которых указана схема

map

. Перед началом выполнения любого запроса

URL Loading System

проходит по всем зарегистрированным для сессии протоколам и вызывает этот метод. Первый зарегистрированный протокол, который в этом методе вернёт

true

, и будет использован для обработки запроса.

2.

canonicalRequest(for:)

override class func canonicalRequest(for request: URLRequest) -> URLRequest {
   return request 
}

Метод

canonicalRequest(for:)

предназначен для приведения запроса к каноническому виду. Документация гласит, что реализация протокола сама решает, что считать определением этого понятия. Здесь можно нормализовать схему, добавить заголовки к запросу, если это нужно, и т. д. Единственное требование к работе этого метода — на каждый входящий запрос всегда должен быть одинаковый результат, в том числе потому что этот метод используется ещё и для поиска закешированных ответов на запросы в

URLCache

3.

startLoading()

В методе

startLoading()

описывается вся логика по загрузке необходимых данных. В этом примере нужно разобрать

URL

запроса и, исходя из значений его параметров

latitude

longitude

, обратиться к

MKMapSnapshotter

и загрузить нужный снапшот карты.

override func startLoading() {
    guard let url = request.url,
        let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
        let queryItems = components.queryItems else {
            fail(with: .badURL)
            return
    }
    
    load(with: queryItems)
}

func load(with queryItems: [URLQueryItem]) {
    let snapshotter = MKMapSnapshotter(queryItems: queryItems)
    snapshotter.start(
        with: DispatchQueue.global(qos: .background),
        completionHandler: handle
    )
}

func handle(snapshot: MKMapSnapshotter.Snapshot?, error: Error?) {
    if let snapshot = snapshot,
        let data = snapshot.image.jpegData(compressionQuality: 1) {
        complete(with: data)
    } else if let error = error {
        fail(with: error)
    }
}

После получения данных необходимо корректно завершить работу протокола:

func complete(with data: Data) {
    guard let url = request.url, let client = client else {
        return
    }
    
    let response = URLResponse(
        url: url,
        mimeType: "image/jpeg",
        expectedContentLength: data.count,
        textEncodingName: nil
    )
    
    client.urlProtocol(self, didReceive: response, cacheStoragePolicy: .allowed)
    client.urlProtocol(self, didLoad: data)
    client.urlProtocolDidFinishLoading(self)
}

Прежде всего создаём объект типа

URLResponse

. Этот объект содержит важные метаданные для ответа на запрос. Затем выполняем три важных метода у объекта типа

URLProtocolClient

. Свойство

client

этого типа содержит каждая сущность

URL

-протокола. Оно выполняет роль прокси между

URL

-протоколом и всей

URL Loading System

, которая при вызове этих методов делает выводы о том, что нужно сделать с данными: закешировать, передать в

completionHandler

запроса, как-то обработать завершение работы протокола и т. д. Порядок и количество вызовов этих методов может отличаться в зависимости от реализации протокола. Например, мы можем загружать данные из сети батчами и периодически оповещать об этом

URLProtocolClient

, чтобы в интерфейсе показать прогресс загрузки данных.

При возникновении ошибки в работе протокола её также необходимо корректно обработать и оповестить об этом URLProtocolClient:

func fail(with error: Error) {
    client?.urlProtocol(self, didFailWithError: error)
}

Именно эта ошибка затем будет отправлена в

completionHandler

выполнения запроса, где её можно обработать и показать красивое сообщение пользователю.

4.

stopLoading()

Метод

stopLoading()

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

override func stopLoading() { }

На этом реализация

URL

-протокола завершена, его можно использовать в любом месте приложения. Чтобы было где применять наш протокол, добавим ещё пару вещей.

URLImageView

class URLImageView: UIImageView {
    var task: URLSessionDataTask?
    var taskId: Int?
    
    func render(url: URL) {
        assert(task == nil || task?.taskIdentifier != taskId)
        
        let request = URLRequest(url: url)
        
        task = session.dataTask(with: request, completionHandler: complete)
        taskId = task?.taskIdentifier
        
        task?.resume()
    }
    
    private func complete(data: Data?, response: URLResponse?, error: Error?) {
        if self.taskId == task?.taskIdentifier,
            let data = data,
            let image = UIImage(data: data) {
            didLoadRemote(image: image)
        }
    }
    
    func didLoadRemote(image: UIImage) {
        DispatchQueue.main.async {
            self.image = image
        }
    }
    
    func prepareForReuse() {
        task?.cancel()
        taskId = nil
        image = nil
    }
}

Это простой класс, наследник

UIImageView

, похожая реализация которого наверняка есть в любом приложении у каждого из вас. Здесь мы просто по

URL

в методе

render(url:)

загружаем картинку и записываем в свойство

image

. Удобство в том, что можно загружать абсолютно любые картинки, как по

http

httpsURL

, так и по нашим кастомным

URL

Для выполнения запросов на загрузку изображений также понадобится объект типа URLSession:

let config: URLSessionConfiguration = {
    let c = URLSessionConfiguration.ephemeral
    c.protocolClasses = [
        MapURLProtocol.self
    ]
    return c
}()

let session = URLSession(
    configuration: config,
    delegate: nil,
    delegateQueue: nil
)

Здесь особенно важна конфигурация сессии. В

URLSessionConfiguration

есть одно важное для нас свойство —

protocolClasses

. Здесь указывается список типов

URL

-протоколов, которые сессия с данной конфигурацией умеет обрабатывать. По умолчанию сессия поддерживает обработку

http

https

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

MapURLProtocol

Всё, что осталось сделать, — реализовать View Controller, который будет отображать снапшоты карт. Его исходный код можно посмотреть здесь.

Вот такой получается результат:

А что с кешированием?

Вроде всё работает хорошо — за исключением одного важного момента: когда мы скроллим список туда-сюда, на экране появляются белые пятна. Похоже, снапшоты никак не кешируются и на каждый вызов метода

render(url:)

мы заново загружаем данные через

MKMapSnapshotter

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

URL Loading System

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

URLCache

Рассмотрим этот процесс подробнее и разделим работу с кешем на два важных этапа: чтение и запись.

Чтение

Чтобы корректно считывать закешированные данные,

URL Loading System

нужно помочь получить ответы на несколько важных вопросов:

1. Какой URLCache использовать?

Конечно, есть уже готовый URLCache.shared, но URL Loading System не может всегда использовать его — ведь разработчик может захотеть создать и использовать свою сущность URLCache. Для ответа на этот вопрос в конфигурации сессии URLSessionConfiguration есть свойство urlCache. Именно оно используется как для чтения, так и для записи ответов на запросы. Укажем какой-нибудь URLCache для этих целей в нашей существующей конфигурации.

let config: URLSessionConfiguration = {
    let c = URLSessionConfiguration.ephemeral
    c.urlCache = ImageURLCache.current
    c.protocolClasses = [
        MapURLProtocol.self
    ]
    return c
}()

2. Нужно ли использовать кешированные данные или выполнять загрузку заново?

Ответ на этот вопрос зависит от запроса URLRequest, который мы собираемся выполнить. При создании запроса у нас есть возможность помимо URL указать политику кеширования в аргументе cachePolicy.

let request = URLRequest(
    url: url,
    cachePolicy: .returnCacheDataElseLoad,
    timeoutInterval: 30
)

По умолчанию используется значение

.useProtocolCachePolicy

, об этом также написано в документации. Это значит, что в таком варианте задача по поиску кешированного ответа на запрос и определению его актуальности полностью ложится на реализацию

URL

-протокола. Но есть и более простой способ. Если задать значение

.returnCacheDataElseLoad

, то при создании очередной сущности

URLProtocolURL Loading System

возьмёт часть работы на себя: запросит у

urlCache

закешированный ответ на текущий запрос с помощью метода

cachedResponse(for:)

. Если закешированные данные есть, то объект типа

CachedURLResponse

будет передан сразу при инициализации

URLProtocol

и сохранён в свойство

cachedResponse

override init(
    request: URLRequest,
    cachedResponse: CachedURLResponse?,
    client: URLProtocolClient?) {
    super.init(
        request: request,
        cachedResponse: cachedResponse,
        client: client
    )
}

CachedURLResponse

— это простой класс, который содержит данные (

Data

) и метаинформацию для них (

URLResponse

Нам остаётся только немного изменить метод startLoading и проверить внутри него значение этого свойства — и сразу завершить работу протокола с этими данными:

override func startLoading() {
    if let cachedResponse = cachedResponse {
        complete(with: cachedResponse.data)
    } else {
        guard let url = request.url,
            let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
            let queryItems = components.queryItems else {
                fail(with: .badURL)
                return
        }
        
        load(with: queryItems)
    }
}

Запись

Чтобы найти в кеше данные, их туда надо положить. Эту работу также полностью берёт на себя

URL Loading System

. Всё, что требуется от нас, — сообщить ей, что мы хотим закешировать данные при завершении работы протокола с помощью параметра политики кеширования

cacheStoragePolicy

. Это простое перечисление с такими значениями:

enum StoragePolicy {
    case allowed
    case allowedInMemoryOnly
    case notAllowed
}

Они означают, что кеширование разрешено в память и на диск, только в память или запрещено. В нашем примере указываем, что кеширование разрешено в память и на диск, потому что почему бы и нет.

client.urlProtocol(self, didReceive: response, cacheStoragePolicy: .allowed)

Вот так, выполнив несколько простых шагов, мы поддержали возможность кеширования снапшотов карт. И теперь работа приложения выглядит так:

Как видим, больше никаких белых пятен — карты загружаются один раз и затем просто переиспользуются из кеша.

Не всегда всё просто

При реализации

URL

-протокола мы столкнулись с рядом падений.

Первое было связано с внутренней реализацией взаимодействия URL Loading System с URLCache при кешировании ответов на запросы. В документации указано: несмотря на потокобезопасность URLCache, работа методов cachedResponse(for:) и storeCachedResponse(_:for:) для чтения / записи ответов на запросы может приводить к гонке состояний, поэтому в подклассах URLCache необходимо этот момент учитывать. Мы рассчитывали, что при использовании URLCache.shared эта проблема будет решена, но оказалось не так. Чтобы исправить это, мы используем отдельный кеш ImageURLCache, наследник URLCache, в котором выполняем указанные методы синхронно на отдельной очереди. В качестве приятного бонуса можем отдельно от других сущностей URLCache настроить вместительность кеша в памяти и на диске.

private static let accessQueue = DispatchQueue(
   label: "image-urlcache-access"
)

override func cachedResponse(for request: URLRequest) -> CachedURLResponse? {
   return ImageURLCache.accessQueue.sync {
      return super.cachedResponse(for: request)
   }
}

override func storeCachedResponse(_ response: CachedURLResponse, for request: URLRequest) {
   ImageURLCache.accessQueue.sync {
      super.storeCachedResponse(response, for: request)
   }
}

Другая проблема воспроизводилась только на устройствах с iOS 9. Методы начала и окончания загрузки

URL

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

startLoading

и затем код завершения загрузки выполняем непосредственно на этом потоке.

var thread: Thread!

override func startLoading() {
   guard let url = request.url,
      let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
      let queryItems = components.queryItems else {
         fail(with: .badURL)
         return
   }

   thread = Thread.current

   if let cachedResponse = cachedResponse {
      complete(with: cachedResponse)
   } else {
      load(request: request, url: url, queryItems: queryItems)
   }
}

func handle(snapshot: MKMapSnapshotter.Snapshot?, error: Error?) {
    thread.execute {
        if let snapshot = snapshot,
            let data = snapshot.image.jpegData(compressionQuality: 0.7) {
            self.complete(with: data)
        } else if let error = error {
            self.fail(with: error)
        }
    }
}

Когда может пригодиться URL-протокол?

В итоге практически каждый пользователь нашего приложения для iOS так или иначе сталкивается с элементами, работающими через

URL

-протокол. Помимо загрузки медиа из галереи, различные реализации

URL

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

Как и любое решение,

URLProtocol

имеет свои преимущества и недостатки.

Недостатки

URLProtocol

Отсутствие строгой типизации — при создании URL схема и параметры ссылки указываются вручную через строки. Если допустить опечатку, нужный параметр не будет обрабатываться. Это может усложнить отладку приложения и поиск ошибки в его работе. В приложении ВКонтакте мы используем специальные URLBuilder’ы, которые формируют конечный URL исходя из переданных параметров. Это решение не очень красивое и несколько противоречит цели не плодить дополнительные сущности, но лучшей идеи пока нет. Зато мы знаем, что если нужно создать какой-то кастомный URL, то наверняка для него есть специальный URLBuilder, который поможет не ошибиться.
Неочевидные падения — я уже описал пару сценариев, из-за которых приложение, использующее URLProtocol, может упасть. Возможно, есть и другие. Но такие проблемы, как обычно, решаются либо более вдумчивым чтением документации, либо глубоким изучением stack trace’а и нахождением корня проблемы.

Преимущества URLProtocol

Слабая связанность компонентов — часть приложения, которая инициирует нужную ей загрузку данных, может вообще не знать о том, как она организована: какие компоненты для этого используются, как устроено кеширование. Мы знаем только про определённый формат URL — и только с ним взаимодействуем.
Простота реализации — для корректной работы URL-протокола достаточно реализовать несколько простых методов и зарегистрировать протокол. После этого его можно использовать в любом месте приложения.
Удобство в использовании — приложению не нужно иметь дополнительные типы данных, которые участвуют в процессе загрузки данных, кроме самого URL-протокола. Для работы используются уже известные типы URL, URLSession, URLSessionDataTask.
Поддержка кеширования — при правильной реализации URL-протокола и конфигурации URL-сессии, а также корректном формировании запроса работа по кешированию данных ложится полностью на URL Loading System.
*Можно замокать API — это такой дополнительный пункт со звёздочкой. При желании можно сделать так, что запросы будут выполняться не к реальному API, а к какой-то собственной заглушке, реализованной через URL-протокол. В нём можно отдавать любые тестовые данные, чтобы даже без доступа к настоящему API проверить работу приложения и состояния в зависимости от ответа, написать тесты. В определённый момент нужно будет только заменить использование URL-протокола с кастомной схемой на стандартный http/https.

URL

-протокол — не панацея и подходит далеко не для всех задач. У него есть преимущества и недостатки. Но всё-таки в следующий раз, когда потребуется что-то загрузить по заданным параметрам, асинхронно выполнить операцию, а конечные данные закешировать, — просто проверьте, вдруг такой подход поможет устранить проблему. Иногда всё, что нужно для решения задачи, — это

URL

Полный исходный код проекта можно посмотреть на нашем GitHub