Стартовый стой

В .Net приложение начинает функционировать с класса Programm, в iOS – с запуска объекта делегатного класса, в Android – с запуска объекта класса App. Их (стартовых классов) назначение – принять и передать вызовы системы приложению, а также, осуществить первоначальную конфигурацию GUI приложения. Все алгоритмы и механизмы, которые не относятся к старту приложения, или получения сообщений от системы должны быть вынесены в отдельные классы. Сразу после завершения первоначальной конфигурации управление должно быть передано классу, который осуществляет остальные операции настройки приложения: авторизацию, реконфигурирование интерфейса в зависимости от условий, первоначальную загрузку данных, получения необходимых токенов и так далее. Типичной ошибкой разработчиков является размещение большого количества кода в стартовых классах приложений. Оно и понятно – практически все примеры внешних фреймворков для простоты понимания именно здесь располагают свой код.

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

Сетевой слой

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

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

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

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

Socket – наиболее низкоуровневый подход, включающий в себя синхронные и асинхронные запросы, и имеющий возможность работать как с TCP, так и с UDP подключениями.

WebSocket – подход, опирающийся на использование заголовков поверх TCP.

WCF – наверное самый совершенный механизм, но имеющий столь серьезный минус, который перевешивает все плюсы. Подход изобретенный в недрах Microsoft опирается на создании прокси-класса, который опосредует взаимоотношение между логикой приложения, и удаленным севером. Работает «на ура» в том случае, если удается сгенерировать прокси класс на основе WSDL схем.

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

REST опирается на использование GET, POST, PUT, HEAD, PATCH и DELETE запросов.

Подавляющее большинство приложений ограничивает систему команд двумя типами, GET и POST, хотя, достаточно только одного – POST.

GET запрос передается в виде строки, которую Вы используете в браузере, а параметры для запроса передаются разделенные знаками ‘&’. POST запрос так же использует «браузерную строку» но, параметры скрывает внутри невидимого тела сообщения.

Слой API

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

Слой сетевого кэширования

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

Для его работы необходимо сообщить ОС о том, что требуется кэширование, вызвав соответствующий метод.

Слой валидации данных

Формат получаемых данных из сети в большей степени зависит от разработчиков сервера. Приложение физически не может контролировать использование изначально заданного формата. Для сложно-структурированных данных, коррекция ошибок сравнима по сложности с разработкой самого приложения. Наличие ошибок, в свою очередь, чревато падением приложения. Использование механизма валидации данных существенно снижает угрозу некорректного поведения. Слой валидации состоит из схем JSON для большинства запросов к серверу, и класса, который осуществляет проверку полученных данных на соответствие загруженной схемы. Если полученный пакет не соответствует схеме, он отклоняется приложением. Вызывающий код получит уведомление об ошибке. Аналогичное уведомление будет записано в лог консоли. Кроме того, может быть вызвана команда сервера для передачи на сторону сервера отчета, о возникшей ошибке. Главное, предусмотреть выход из рекурсии, если команда отправки такого сообщения тоже вызывает какую-нибудь ошибку (4xx или 5xx).

Имеет смысл на сервер отправлять следующие данные:

Для какого аккаунта произошла ошибка.

Какая команда вызвала ошибку.

Какие данные были переданы серверу.

Какой ответ был получен от сервера.

Время UTC*

Статус код команды. Для ошибок валидации он всегда 200.

Схема, которой не удовлетворяет ответ сервера.

Предполагается, что схемы JSON запросов предоставляют серверные разработчики после реализации новых команд API.