Добрый день, читатели!
Сейчас все мобильные приложения(за очень редким исключением) используют сеть: для авторизации, получения/отправки данных и т.д.
Свой опыт на эту тему я решил собрать в статье.
Работа с сетью в стандартном приложении сводится к решению нескольких задач:
- авторизация
- запрос и отправка данных
- хранение данных
- работа с картинками
Авторизация
Все социальные сервисы имеют OAuth аутентификацию с facebook и рядом других социальных сетей.
Авторизуюясь через них вы получаете token, который отправляется вместе с id юзера на ваш сервер и от него приложение получает id сессии. Нужно учитывать, что оба ключа могут устареть в любой момент. Если потеряна сессии должна идти автоматическая ре-аутентификация на сервер. Если потерян token, то пользователю должно показываться окно авторизации, получив новый token нужно организовать запрос на сервер для получения нового id сессии.
Если любой из запросов приложения вернулся с ошибкой «сессия устарела»(или аналогичный) метод авторизации должен автоматически отработать, а потом выполнить метод на котором свалилась ошибка.
Переходы по экранам приложения
При большом количестве различных вкладок в приложении(сообщения, друзья, профили, check-ins, активности пользователей, новости, симпатии) каждый новый контролл требует подгрузки данных. Также есть фоновые запросы к серверу, которые по таймеру запрашивают данные все время работы приложения(это могут быть запросы на кол-во новых сообщений, инвайты в друзья, изменение баланса валюты внутри приложения и тд). Также контроллы необходимо оповещать об обновлениях синхронно или асинхронно, в зависимости от типа запроса.
Получение картинок с сервера
Как видно картинка может быть использована одна и та же. Если сервер присылает url только на изображение большого разрешения, то необходимо его, после загрузки, кэшировать, ужимать, делать круглым или округлять углы. Все, что потребуется для дизайна приложения.
Сохраняем оригинал локально и при запросе картинок ищем среди кэшированных файлов. Если оригинал есть, но разрешение нужно меньше или другой формы: уменьшаем картинку и результат сохраняем с названием вида имя_файла_разрешение если есть — показываем, нет грузим.
Хранение данных
Каталог интернет-магазина, истории переписок в чате, лента новостей. Все это устаревающие и изменяющиеся объемы данных достаточно крупного объема. Оптимально для каждого такого действия делать серверный метод. Открыли список сообщений- запросили первые 50 позиций(записей, сообщений, продуктов), асинхронно подгрузили аватарки или фото продуктов. Перешли в чат-запросили последние 50 сообщений истории с данным пользователем, при прокрутке попросили еще 50.
Это позволит снизить объем передаваемых данных и приложение будет работать быстро на edge.
Основное решение по архитектуре
Основное решение — организовать класс, управляющий запросами. Singleton класс(или набор классов) отвечающий за работу с сетью.
Его задачи:
- Создавать очередь вызовов, автоматически упорядочивать ее в зависимости от верных/не верных ответов сервера
- Посылать уведомления о получении данных подписанным на те или иные методы контроллам (в ios через nsnotification)
- Посылать задания менеджеру загрузки картинок
- Управлять фоновым поток загрузки активностей пользователя(уведомление о новые сообщения, лайке и тд)
В iOS класс реализовался на базе стандартного NSConnection.
Запросы добавляются в очередь. Будет ли это динамический массив с приоритетами или NSOperationQueue(как в iOS) решать вам. Каждый запрос в очереди имеет приоритет и если возвращается error с потерянной авторизацией при последнем запросе максимальный приоритет получает сформированный запрос на реконнет. Это позволит избежать ситуации, когда пользователь тапает по кнопке, сессия потеряна и возвращая error подключения ничего не происходит.
Пока на этом все. Во второй части планирую привести примеры кода класса подключений, организацию взаимодействия с натификациями и менеджером картинок.
Спасибо.
Автор: AndreyPanov
