Несколько советов по архитектуре мобильного приложения, активно использующего сеть. Часть 1

Добрый день, хаброжители!
Сейчас все мобильные приложения(за очень редким исключением) используют сеть: для авторизации, получения/отправки данных и т.д.
Свой опыт на эту тему я решил собрать в статье.
Работа с сетью в стандартном приложении сводится к решению нескольких задач:
  • авторизация
  • запрос и отправка данных
  • хранение данных
  • работа с картинками

Авторизация

Все социальные сервисы имеют OAuth аутентификацию с facebook и рядом других социальных сетей.
Авторизуюясь через них вы получаете token, который отправляется вместе с id юзера на ваш сервер и от него приложение получает id сессии. Нужно учитывать, что оба ключа могут устареть в любой момент. Если потеряна сессии должна идти автоматическая ре-аутентификация на сервер. Если потерян token, то пользователю должно показываться окно авторизации, получив новый token нужно организовать запрос на сервер для получения нового id сессии.
Если любой из запросов приложения вернулся с ошибкой «сессия устарела»(или аналогичный) метод авторизации должен автоматически отработать, а потом выполнить метод на котором свалилась ошибка.

Переходы по экранам приложения

При большом количестве различных вкладок в приложении(сообщения, друзья, профили, check-ins, активности пользователей, новости, симпатии) каждый новый контролл требует подгрузки данных. Также есть фоновые запросы к серверу, которые по таймеру запрашивают данные все время работы приложения(это могут быть запросы на кол-во новых сообщений, инвайты в друзья, изменение баланса валюты внутри приложения и тд). Также контроллы необходимо оповещать об обновлениях синхронно или асинхронно, в зависимости от типа запроса.

Получение картинок с сервера


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

Хранение данных

Каталог интернет-магазина, истории переписок в чате, лента новостей. Все это устаревающие и изменяющиеся объемы данных достаточно крупного объема. Оптимально для каждого такого действия делать серверный метод. Открыли список сообщений- запросили первые 50 позиций(записей, сообщений, продуктов), асинхронно подгрузили аватарки или фото продуктов. Перешли в чат-запросили последние 50 сообщений истории с данным пользователем, при прокрутке попросили еще 50.
Это позволит снизить объем передаваемых данных и приложение будет работать быстро на edge.

Основное решение по архитектуре

Основное решение — организовать класс, управляющий запросами. Singleton класс(или набор классов) отвечающий за работу с сетью.
Его задачи:
  • Создавать очередь вызовов, автоматически упорядочивать ее в зависимости от верных/не верных ответов сервера
  • Посылать уведомления о получении данных подписанным на те или иные методы контроллам (в ios через nsnotification)
  • Посылать задания менеджеру загрузки картинок
  • Управлять фоновым поток загрузки активностей пользователя(уведомление о новые сообщения, лайке и тд)

В iOS класс реализовался на базе стандартного NSConnection.
Запросы добавляются в очередь. Будет ли это динамический массив с приоритетами или NSOperationQueue(как в iOS) решать вам. Каждый запрос в очереди имеет приоритет и если возвращается error с потерянной авторизацией при последнем запросе максимальный приоритет получает сформированный запрос на реконнет. Это позволит избежать ситуации, когда пользователь тапает по кнопке, сессия потеряна и возвращая error подключения ничего не происходит.

Пока на этом все. Во второй части планирую привести примеры кода класса подключений, организацию взаимодействия с натификациями и менеджером картинок.
Спасибо.
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 11

    –1
    Спасибо за статью! Этакий базовый «этикет» при работе с сетью.
    И еще подтвердили мой самостоятельный опыт.
      –1
      спасибо за статью! расскажите плз, по какому условию у вас устаревает кеш?
        0
        Все зависит от требований заказчика. Вот несколько вариантов:
        • Проверять папку кэш на объем каждый раз при заходе приложения, если больше определенного объема(200мб вполне хватит) то удалять все. Т.к. картинки весят не так много, эта операция будет проходить редко.
        • Можно периодически удалять файлы старше какой-то даты.
        • Можно класть в папку temp(iOS) и файлы будут сами удаляться после завершения работы приложения
          0
          а если требование, чтобы картинки обновлялись после обновления это картинки на сервере, а до этого брались из кеша, как вы посоветуете такое реализовать?
            +1
            Необходимо, чтобы на сервере, при обновлении картинки, изменялось имя файла(или вместе с url на картинку приходила бы дата добавления этого файла). Тогда все просто, старый файл потом удалиться по алгоритму, описанному выше.
              0
              спасибо!
              0
              При запросе отправлять заголовок ETag/If-None-Match или использовать MKNetworkKit который сделает это за вас.
              0
              В iOS нету готового LRU-кэша?
            0
            Толком об архитектуре ни слова. Где всякие там лайеры (сервис лайер, дата аксес лайер). Как построить связь между лайерами, какие паттерны или приемы где и как лучше использовать и тп.
              –1
              То, о чём вы говорите, не есть архитектура, а есть шаблоны программирования, которых миллион в любой книжке. Не нужно разбивать типичное iOS приложение на лэеры, это просто нецелесообразно.
              0
              >Также есть фоновые запросы к серверу, которые по таймеру запрашивают данные все время работы приложения(это могут быть запросы на кол-во новых сообщений, инвайты в друзья, изменение баланса валюты внутри приложения и тд).

              Такой подход никуда не годится, для этих целей необходимо использовать Push Notifications (GCM в android). Это позволит снизить трафик до минимума, а интерактивность повысить до максимума.

              Only users with full accounts can post comments. Log in, please.