Видео. Пишем полноценное клиент-сервер приложение под Android / Хабр

Основные задачи при разработке клиент-серверных приложений

Так в чем же заключается сложность создания клиент-серверных Android-приложений, которые бы удовлетворяли всем принципам, которые были описаны ранее? Есть 2 крупные проблемы, каждую из которых на самом деле можно разбить еще на большее число проблем:

• Реализация клиент-серверного взаимодействия. Казалось бы, в чем здесь проблема? Мы все умеем выполнять запросы к серверу с использованием различных средств, обрабатывать результат и показывать его пользователю. И да, и нет. Здесь существует масса факторов. Во-первых, нужно уметь корректно обрабатывать ошибки, которые могут быть самыми разными: от отсутствия интернета и неправильных параметров в запросе, до не отвечающего сервера и ошибках в ответе. Во-вторых, в вашем приложении может быть не один запрос, а много, и вполне возможна ситуация, что вам придется комбинировать результаты этих запросов сложным образом: выполнять их параллельно, использовать результат предыдущего запроса для выполнения следующего и так далее. В-третьих, и это самое неприятное – запросы могут занимать значительное время, а пользователь часто не самый терпеливый и тихий человек – он может крутить устройство (и тогда вы потеряете текущие данные в Activity), а может и вовсе закрыть приложение, и тогда вы можете получить рассинхронизацию в данных (когда на сервере данные обновились, а приложение не знает об этом и отображает некорректную или устаревшую информацию). И все это нужно каким-то образом решать.
• Обеспечение возможности тестирования классов, содержащих бизнес-логику приложения. Это также подразумевает под собой немало внутренних проблем. Во-первых, нужно обеспечить модульность классов. Это следует из самой сути и из самого названия Unit-тестов. Чтобы обеспечить модульность, нужно разделять классы по логическим слоям для каждого экрана. То есть вместо того, чтобы писать весь код, относящийся к одному экрану, в одной активити, нужно грамотно разделить его на несколько классов, каждый из которых будет иметь свою зону ответственности. Во-вторых, если говорить о тестах с помощью JUnit, то нужно понимать, что тестируемые таким образом классы должны содержать минимальное количество зависимостей от Android-классов, так как Java и ее виртуальная машина об этих классах не знает ничего (подробнее этот момент будет описан в лекции про тестирование). В-третьих, самая сложная логика приложения почти всегда связана с работой с данными от сервера. Мы должны протестировать различные возможные ситуации, такие как ожидаемый ответ сервера, ошибка сервера и разные ответы, приводящие к разному поведению приложения. Но при выполнении теста мы не можем по своему желанию “уронить” сервер или заставить его отдать нужные нам данные. К тому же, серверные запросы выполняются долго и асинхронно, а тесты должны работать последовательно. Все эти проблемы можно решить, если подменять реализацию сервера на определенном слое, к которому будут обращаться тестируемые классы. Все это также будет рассмотрено далее.

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

Longpoll

Старый добрый longpoll появился до HTML5: он отличается от ping-pong тем, что закрытие соединения не инициируется со стороны клиента или сервера. Оно остается открытым, и в него можно отправлять данные до тех пор, пока не выйдет время жизни соединения (TTL).

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

Ping-pong

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

React-native

Еще один распространенный вариант – разработка на основе веб-технологий. Здесь лидирует React Native. Признаюсь честно, я не большой поклонник React, но постараюсь не предвзято оценить его использование. Неоспоримым преимуществом является доступность владеющих этой технологией программистов и возможность задействовать штатных веб-разработчиков для создания мобильного приложения. В основном поэтому на React Native делают в основном MVP (minimum viable product).

Если у вас есть разработчики полного цикла (full-stack), то и для серверной части вы скорее всего предпочтете использовать Node.js. React Native также неплохо поддерживает анимацию, включая анимации Lottie. К сожалению, таким же неоспоримым недостатком является очень скудная производительность приложения. Исходя из своего опыта, переписывать продукты с другим технологическим стеком приходится именно по этой причине.

Видео серия

6. Полноценное Android приложение: Урок 6. Реализуем Navigation Drawer (

в процессе

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

p.s. Если вам интересно то, что мы делаем, то мы бы хотели, чтобы вы оставили отзыв, чего вам не хватает в этой серии уроков, или что бы вы хотели увидеть в уроках.

Выбор модели кэширования

Итак. Это была непростая тема. Теперь мы попробуем подвести итоги и вывести базовые правила использования той или иной модели кэширования.

1. Все статические изображения должны обслуживаться по модели срока действия.
2. Все данные, формируемые динамически, должны кэшироваться по модели валидности.
3. Если ваш, динамически формируемый, ресурс является списком, вам следует использовать модель валидности, основанную на Last-Modified. (Например /friends). В остальных случаях следует использовать модель валидности, основанную на ETag. (Например /friends/firstname.lastname).
4. Изображения или любые другие ресурсы, которые могут быть изменены пользователем (такие как аватар) должны также кэшироваться по модели валидности с использованием ETag. Несмотря на то, что это изображения, они не постоянны как например логотип компании. Кроме того вы просто не сможете точно рассчитать срок действия таких ресурсов.

Другой способ (более простой в реализации, но немного хакерский), это использование “ошибки URL”. Когда в ответе есть URL аватара, надо сделать часть его динамичной. Так вместо представления URL как

Гибкость и расширяемость

Для обеспечения гибкости и расширяемости клиент-серверного взаимодействия мы используем при разработке RESTful API.Хороший RESTful API — тот, который можно менять легко и просто.Сервер может считаться RESTful, если он соответствует принципам REST.

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

Документирование

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

Первым шагом мы рекомендуем подумать об основных, высокоуровневых структурах данных (моделях), которыми оперирует ваше приложение. Затем подумайте над действиями, которые можно произвести над этими компонентами. Документация по foursquare API — хороший пример, который стоит изучить перед тем как начать писать свою.

Данное API имеет набор высокоуровневых объектов, таких как места, пользователи и тому подобное. Также у них есть набор действий, которые можно произвести над этими объектами. Поскольку вы знаете высокоуровневые объекты и действия над ними в вашем продукте, создание структуры вызовов API становится проще и понятней. Например, для добавления нового места логично будет вызвать метод наподобие /venues/add

Документируйте все высокоуровневые объекты. Затем документируйте запросы и ответы на них, используя эти высокоуровневые объекты вместо простых типов данных. Вместо того, чтобы писать “Этот вызов возвращает три строковых поля, первое содержит id, второе имя, а третье описание” пишите “Этот вызов возвращает структуру (модель), описывающую место”.

Игровые приложения

К первой группе можно отнести игровые приложения из-за их специфики: требований к производительности, возможностям интерактивной анимации и используемых технологий. Основное отличие игровых приложений заключается в используемых сетевых протоколах. Например, когда приложение имеет интерактивный режим (например, режим боя в реальном времени), то может использоваться протокол на основе сетевого стека UDP. В остальных случаях для связи с серверной частью используются протоколы поверх стека TCP/IP.

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

Здесь можно выделить использование движков Unity (C#), Unreal Engine и менее распространенных, таких как Cocos2dx (С ). Конечно, для некоторых игровых жанров используются и нативные языки платформы. Стоит вспомнить известную всем известную 2048, но это скорее исключение из правил.

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

Использование etag

ETag обычно рассчитывается на сервере с использованием алгоритмов хэширования. (Большинство серверных языков высокого уровня, таких как Java/C#/Scala обладают средствами хэширования объектов). Перед формированием ответа сервер должен рассчитать хэш объекта и добавить его в поле заголовка ETag.

Использование last-modified

Реализация использования Last-Modified не совсем проста. Давайте представим что в нашем API есть вызов, возвращающий список друзей.

Клиент – серверное разделение и единый интерфейс

RESTful сервер должен прятать от клиента как можно больше деталей своей реализации.Клиенту не следует знать о том, какая СУБД используется на сервере или сколько серверов в данный момент обрабатывают запросы и прочие подобные вещи.Организация правильного разделения функций важна для масштабирования, если ваш проект начнёт быстро набирать популярность.Это, пожалуй три самых важных принципа, которым нужно следовать в ходе разработки RESTful сервера.

Модель срока действия

Давайте рассмотрим распространенную конфигурацию кэширования. Если вы используете nginx, у вас наверняка есть в конфиге нечто подобное:

Нативные

Классическим вариантом является использование нативных языков и их вариаций, таких как Java, Kotlin, Objective-C и Swift. К преимуществам использования нативных языков можно отнести очень высокую скорость исполнения и относительно малый размер бинарного файла, но здесь стоит учитывать и размер ассеттов (изображений, шрифтов и т.д.).

Обычные приложения

Парадигма разделения на версии через модель

Выше мы показали как документировать ваши структуры данных (модели). Рассматривайте эту документацию как контракт между разработчиками серверной и клиентской частей. Вам не следует вносить изменения в модели без изменения версии. Это значит, что в предыдущем случае должно быть две модели №1 и №2.Поведение модели №1 остается таким же, как это было оговорено в документации.

Поддержка на стороне клиента

На самом деле под iOS, если вы используете MKNetworkKit, то он делает всю работу автоматически.

Поддержка старых версий api

До появления мобильных приложений, в эпоху Web 2.0 создание разных версий API не было проблемой. И клиент (JavaScript/AJAX front-end) и сервер разворачивались одновременно. Потребители (ваши клиенты) всегда использовали самую последнюю версию клиентского ПО для доступа к системе.

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

Вы можете развернуть API версии 2, считая что все будет отлично, однако это приведет к неработоспособности приложений под iOS, использующих старую версию. Поскольку ещё могут быть пользователи, использующие такие приложения несмотря на то, что вы выложили обновленную версию в App Store.

Процесс приготовлений

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

. Таски иногда пополняются, но в на данный момент первый спринт выглядит так:

Работа с сетью в android: трафик, безопасность и батарейка

httpClient.setKeepAliveStrategy(
  new ConnectionKeepAliveStrategy() {
    @Override
    public long getKeepAliveDuration(
                    HttpResponse response,                          		     		HttpContext context) {
      return KEEP_ALIVE_DURATION_MILLISECONDS;
    }
  });

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.FROYO) {
  System.setProperty("http.keepAlive", "false");
}

TrustManagerFactory tmf = 
      TrustManagerFactory.getInstance(algorithm);
KeyStore keyStore = KeyStore.getInstance("BKS");
InputStream in = 
      context.getResources().openRawResource(mykeystore);
keyStore.load(in, "mysecret".toCharArray());
in.close();
tmf.init(keyStore);
SSLContext sslc = SSLContext.getInstance("TLS");
sslc.init(null, tmf.getTrustManagers(),new SecureRandom());

private SSLSocketFactory createSslSocketFactory() {
  SSLSocketFactory sf = null;
  try {
    KeyStore keyStore = KeyStore.getInstance("BKS");
    InputStream in = 
    context.getResources().openRawResource(mykeystore);
    keyStore.load(in, "mysecret".toCharArray());
    in.close();
    sf = new SSLSocketFactory(keyStore);
    sf.setHostnameVerifier(STRICT_HOSTNAME_VERIFIER);
  } catch (Exception e) {
    e.printStackTrace();
  }
  return sf;
}.

private class DummyHostnameVerifier implements HostnameVerifier{
  
  @Override
  public boolean verify(String hostname, SSLSession session) {
    return true;
  }

}

private class DummyTrustManager implements X509TrustManager{

  @Override
  public void checkClientTrusted(...) throws CertificateException {
    //empty
  }

  @Override
  public void checkServerTrusted(...) throws CertificateException {
    //empty
  }
 ...
}

Сетевой стек мобильного приложения

Базовые состояния приложения:

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

Итоги

Возможно ли задействовать разработчиков клиентской части для создания бэкенда?

По очевидным причинам лидирующие позиции здесь занимают веб-разработчики и Node.js. Конечно, серверную часть делают и Flutter-разработчики. Dart позволяет писать сетевые серверные приложения, и, возможно, они удивят вас своей производительностью по сравнению с Node.js.

С точки зрения затрат и при отсутствии специализированных разработчиков в штате, идеальным решением было бы создание MVP на React-Native и серверной части на основе Node.js. Однако при отсутствии в штате веб-разработчиков лучшим решением, возможно, было бы использование Flutter в качестве основы.