как сделать сервер для андроид приложения
Видео. Пишем полноценное клиент-сервер приложение под Android
Приветствую вас, уважаемый Developer!
Хочу поделиться с вами серией уроков, которые мы пишем на нашем канале. Цель данных уроков поделится своими знаниями в сфере Java/Android Development-а, показать как мы строим процесс разработки, и в итоге написать готовое приложение, которое будет общаться с сервером.
Внимание!
Данными уроками мы лишь показываем, то, как мы видим процесс разработки, и делимся лично своим опытом. Все что мы объясняем, является лишь нашим мнением и решением, которое может не сходится с вашим.
Чтобы сделать курс более понятным, мы решили не брать мегасложное приложение, тем самым сделав процесс более простым.
Немного подумав мы решили писать приложение которое бы напоминало нам о важных событиях, делах на текущий день, неделю, месяц или год.
Да, да, да! Мы знаем что таких приложений горы, но цель не создать мега уникальное и популярное приложение, а показать процесс его разработки.
Процесс приготовлений
Прежде чем приступить, мы продумали, что будем писать, как и даже накидали прототипы и макеты. После чего распланировали первый спринт в Youtrack. Таски иногда пополняются, но в на данный момент первый спринт выглядит так: 
Также уже в процессе было создано макет приложения, которое мы планируем написать и весь этот процесс записать на видео:
Веб-сервер на старом смартфоне Android
Бывает такое, что смартфон становится ненужным — например, на нём разбивается экран или он просто старенький, тормозит даже браузер. Что делать с таким гаджетом, не выбрасывать же его? В самом деле, американцы летали на Луну с компьютерами, у которых характеристики много хуже, чем в вашем старом смартфоне. Скорее всего, в нём 4−8 процессорных ядер, 2−4 гигабайта оперативной памяти, блок бесперебойного питания с аккумулятором. Не слабее, чем некоторые компьютеры.
Попробуем найти этому смартфону полезное применение.
Рассматриваем варианты
Первый вариант, который приходит в голову — установить на телефон Linux-окружение и какой-нибудь полезный софт, который будет работать в «фоновом режиме» на пользу домашнему хозяйству. Что это может быть?
Ясно, что телефон не сможет работать как медиасервер и обрабатывать видеопотоки, для этого у него слишком слабый процессор.
Теоретически можно подключить к нему внешний HDD (тоже остался от сломанного ноутбука, для него куплен специальный корпус-переходник с интерфейсом USB). Даже на ёмкой карте microSD он вполне может работать как файловое хранилище или сервер для бэкапов, места хватит. Правда, карты microSD вряд ли можно посоветовать как надёжное хранилище, они часто выходят из строя.
Простая синхронизация
Если поднимать на телефоне сервер для бэкапов или файловый сервер, то самый простой вариант — это установить программу Syncthing.
Syncthing выполняет непрерывную синхронизацию файлов между двумя или более компьютерами в режиме реального времени. В таком варианте синхронизации отсутствует центральный сервер, а все компьютеры участвуют в синхронизации как бы peer-to-peer. Синхронизация идёт по дате изменения файла, ещё имеется поддержка синхронизации на уровне блоков, т.е. при небольших изменениях в файле, будут синхронизированы только изменившиеся блоки, а не весь файл сразу. Трафик шифруется по TLS (transport layer security). Опять же, программа с открытым исходным кодом, что говорит в пользу надёжности и безопасности такого решения.
В любом случае для персональных компьютеров и ноутбуков в доме нужно резервное хранилище, так что это вполне подходящий вариант.
Syncthing выпускается под все распространённые операционные системы: Linux, Windows, macOS, FreeBSD, OpenBSD, NetBSD, Dragonfly BSD, Illumos, Solaris. Ну и Android, конечно. То есть можно выполнять синхронизацию файлов между всеми этими устройствами, если поставить клиент на каждое из них. Затем в программе на компьютере добавляем ID устройства — и они синхронизируются.
Syncthing на компьютере
Затем остаётся выбрать папки для синхронизации на компьютере и телефоне.
Syncthing на телефоне
Потом программа может постоянно работать в фоновом режиме. Как вариант, можно установить конкретные условия, при которых она выполняется.
Сервер для резервного копирования под Linux
Можно поставить более серьёзную программу — UrBackup. Это опенсорсный сервер для резервного копирования. Он может работать по такому же принципу, что и Syncthing — постоянно в фоновом режиме отслеживать папки, которые требуется сохранять в резервной копии, но это более серьёзное решение, которое предпочтительно при управлении бэкапами в сети из десятка компьютеров. Система кроссплатформенная и поддерживает дистрибутивы Linux, Windows и Mac OS.
Веб-интерфейс UrBackup
Чтобы заработал UrBackup, нужно установить Linux-окружение. Тут у нас есть два варианта:
Обязательное требование — рутованный смартфон (для рутования можно использовать инструмент, например, такой Magisk).
Итак, алгоритм примерно такой, судя по инструкции от Ханны Ли, которая и реализовала этот план.
Поэтому для повышения надёжности лучше использовать USB-хаб, в котором есть microUSB для выхода на телефон и стандартный USB для подключения HDD, плюс дополнительный разъём для питания.
В идеале нужно покупать хаб с адаптером Ethernet. Сервер может работать и по WiFi, но кабельное подключение надёжнее.
USB-хаб с разъёмом Ethernet и выходом microUSB
Termux
Возможно, всё это можно сделать без рутования, с использованием Linux-окружения Termux. Проверим, так ли это.
Termux — это бесплатный эмулятор консоли и Linux-окружение под Android, которое устанавливается как обычное приложение и не требует рутового доступа, включает в себя множество пакетов операционной системы Linux. В базовом формате там установлен минимум, дополнительные пакеты можно организовать при помощи диспетчера пакетов «pkg» (аналоге apt). Это самый удобный способ запустить на Android практически любые линуксовые программы. Лучше устанавливать его с F-Droid, а не из Google Play.
В нашем случае можно сразу установить apt:
Затем с его помощью установить wget, ну или использовать родную команду pkg :
Потом можно установить тот же UrBackup, другой файл-сервер или сервер резервного копирования на свой выбор.
К примеру, можем поставить веб-сервер nginx:
После этого запускаем веб-сервер:
Теперь можно скопировать в рабочую директорию nginx файлы HTML — и на телефоне будет полноценный сайт, который можно открыть для общего доступа через интернет. Тогда у нас будет собственный сервер и собственный хостинг, мы не платим никакому провайдеру, кроме сотового оператора, и можем публиковать в интернете что угодно. В принципе, сайт будет всем доступен до тех пор, пока телефон подключён к сотовой сети, на нём открыта сессия Termux, а в ней запущен nginx. Главное, чтобы сотовый оператор не блокировал этот трафик, потому что мы формально можем нарушать его условия обслуживания.
Конечно, для надёжного хостинга лучше рутануть смартфон и установить нормальный дистрибутив через Linux Deploy. Но и в Termux всё работает, как видим.
Вывод: Таким образом, даже из старого смартфона Android можно сделать адекватный, полнофункциональный многоядерный Linux-сервер на ARM-архитектуре. Если подключить внешний HDD/SDD, то он будет работать как хранилище файлов, сервер резервного копирования для домашней сети или веб-сервер, для ваших личных нужд.
НЛО прилетело и оставило здесь промокоды для читателей нашего блога:
Разработка сервера мобильных клиентов
Обратная сторона мобильных клиентов — сервер.
Введение
Не открою секрета, что разработка мобильных приложений в тренде – этому способствует стремительное техническое развитие: мобильные устройства с каждым годом улучшаются по всем характеристикам и становятся доступнее для широкого круга людей. Почти каждый, кто имеет на руках мобильный гаджет (будь то смартфон, коммуникатор или планшет) пользуется приложениями: браузером, клиентом электронной почты и мгновенных сообщений, играми, бизнес или финансовыми программами. И зачастую от пользователей скрыто то, что многие из приложений взаимодействуют с удаленным сервером: обмениваются с ним данными через Интернет.
По роду деятельности (Java разработчик серверных приложений) мне в команде приходится разрабатывать сервера для мобильных клиентов (за последние 2 года участвовал в реализации 3-х таких проектов для зарубежных компаний). Определился набор Java-технологий для решения задач такого рода, который варьируется в зависимости от требований и целесообразности (другими словами — желания), благо свобода при выборе технологий позволяет экспериментировать. Сформировавшейся точкой зрения и опытом хотел бы поделиться с сообществом.
Требования
Особенностью является то, что формируются требования и для серверного, и для клиентского приложения, которые в ряде случаев взаимосвязаны. Для начала опишу базовые требования в контексте механизма обмена данными:
• кроссплатформенность клиента: зачастую важно обеспечить поддержку разных платформ — Android, iOS, Windows Phone и пр. Редко заказчик довольствуется одним видом устройств.
• быстродействие: должна обеспечиваться достаточная для workflow скорость работы, комфортный отклик на графическом интерфейсе пользователя;
• простота: чем проще API протокола, тем меньше времени уходит на реализацию и поддержку кода, тем меньше может быть квалификация разработчика;
• эффективность: чем сложнее реализация протокола, тем больше потребляется ресурсов мобильного устройства, которые ограничены.
Дополнительные требования зависят от специфики приложения:
• масштабируемость сервера – для SaaS, социальных приложений, где в идеале ожидается большой поток посетителей, это условие обязательно. Для бизнес приложений, где есть ограничения по числу пользователей или численность прогнозируется, данное свойство не требуется;
• интерактивность: ряд приложений нужно обеспечить механизмом нотификаций – сообщить приложению (пользователю) о наступлении определенных событий, передать сообщение пользователю. Данным свойством должна обладать, например, биржевая система или автоматический диспетчер такси.
• открытое API: предполагается, что сторонние разработчики могут воспользоваться функционалом системы посредством документированного протокола. Ведь клиентом может быть как мобильное, так и внешнее серверное приложение.
• другие требования…
Команда
Состав проектной команды для разработки системы в идеале может быть следующим:
• менеджер проекта: управляет, контролирует проект, напрямую взаимодействует с заказчиком;
• разработчик серверного приложения: разрабатывает сервер бизнес логики, базу данных, сетевой протокол;
• разработчик приложения администратора: разрабатывает Web приложение, пользовательский интерфейс для настройки и управления серверным приложением;
• разработчик клиентского приложения для Android;
• разработчик клиентского приложения для iOS;
• разработчик клиентского приложения для …
• тестировщик: тестирует приложение администратора и клиентские приложения.
Внимательный читатель заметит, что в случае написания серверного приложения с графическим интерфейсом, например, на HTML5, можно сэкономить. В этом случае не требуется разработка клиентских приложений – интерфейс пользователя предоставляет браузер. Данная статья не рассматривает такой случай, идет речь о разработке ”родных” (native) приложений для мобильных устройств.
Мне доводилось работать в команде с полным составом, но будет реалистами – не всегда человеческие ресурсы и бюджет позволяет собрать такую команду. И иногда роли приходится совмещать: менеджер проекта + разработчик серверного приложения, разработчик клиентского приложения + тестировщик.
Технологии, инструменты, библиотеки
Для разработки сервера мобильных клиентов обычно использую следующий стек “свободных” технологий:
• Apache Tomcat – контейнер сервлетов;
• MySQL – СУБД;
• Subversion – система версионного контроля;
• Maven – фреймворк для автоматизации сборки проектов;
• JUnit – обеспечит эффективность автоматического тестирования приложений;
• Apache Log4j – библиотека логгирования;
• Jenkins – система непрерывной интеграции;
• Hibernate – ORM (настройки, конфигурация в properties, xml файлах и в аннотациях);
• hibernate-generic-dao – реализация DAO от Google, реализует основные методы для работы с данными базы данных, упрощает реализацию фильтрации и сортировки в методах;
• Spring – реализация аутентификации и авторизации (security), контейнер сервисов и бинов (конфигурация в xml файлах и в аннотациях), используем также при создании тестов.
В зависимости от специфики системы и требований к ней использую один из 2-ух вариантов реализации протокола обмена данными.
Когда требуются кроссплатформенность, быстродействие, простота, эффективность, масштабируемость, открытое API, то беру Jersey – реализацию Web-сервисов REST (RESTful Web services). Эта библиотека позволяет использовать сериализацию данных в формате JSON или(и) XML. Конфигурация REST ведется посредством аннотаций. Для обмена с мобильными устройствами взят формат JSON по причине того, что имеет более простую реализацию на стороне клиента (по этой причине не используем “классические” Web-сервисы), генерируется меньший объем трафика. Jersey позволяет настроиться на наиболее подходящий “вид” JSON.
В ином случае, если необходимы кроссплатформенность, высокое быстродействие, простота, эффективность, интерактивность, то беру
• Apache MINA – framework для создания сетевых приложений,
• Google protobuf – библиотека кодирования и декодирования структурированных данных. Структура данных определяется заголовочными файлами *.proto, компилятор генерирует из них Java классы (также есть возможность генерации для других языков программирования: C++, Objective-C и т. д., что обеспечивает свойство кроссплатформенности);
• java.util.concurrent – используем стандартный пакет.
Данный вариант может масшабироваться, но на это требуется закладываться на этапе проектирования на уровне архитектуры, учитывая бизнес логику.
Рассмотрим гипотетическую задачу на примере выбора технологий для реального SaaS сервиса – “Аукцион услуг “Аукнем”, который позволяет людям сформировать заказ на выполнение требуемых услуг или работ, а организациям в свою очередь оставить для них свои предложения. Берем все базовые требования по умолчанию. Ввиду того, что регистрация в этой системе свободная и бесплатная, то однозначно к ним требуется добавить масштабируемость. А что на счет интерактивности? Было бы здорово сообщать подрядчикам (исполнителям) о создании новых заказов, а заказчиков информировать о поступивших предложениях в тот же миг в приложении, а не только по электронной почте. На основания этого возьмем для реализации Apache MINA, Google protobuf. Смотрим следующее свойство — открытое API. Сервис общедоступный, потому предположим, что внешние разработчики могут проявить интерес к интеграции с ним. Постойте! Не все так просто. Протокол на базе Apache MINA достаточно сильно зависит от реализации и интеграция без знания нюансов отнюдь не прозрачна. В такой ситуации придется взвесить, какой фактор важнее и сделать выбор.
Делаем сервер из Android-телефона
Некоторое время назад мне пришла в голову интересная идея — превратить свои старые телефоны (их скопилось немало за десять лет) в серверы, в качестве альтернативы покупке Raspberry Pi.
На то было несколько причин: во-первых, у телефонов есть батарея, что для сервера практически бесплатный мини-UPS, во-вторых, внутренняя память смартфона (UFS) работает быстрее и надёжнее, чем SD-карта. В-третьих, у телефонов имеется экран, по которому можно отслеживать состояние сервера.
Ну и в-четвёртых, мне просто было жаль их выбрасывать. Консьюмеризм в наше время предписывает каждый год-два покупать новые смартфоны, производители блокируют возможности железа, которые им невыгодны, прекращают поддержку старых моделей, оставляя людей беспомощными. Миллионы смартфонов отправляются на свалку истории каждый год, хотя каждый из них это мощный компьютер.
TL;DR: в этом посте будут разобраны вопросы установки PostmarketOS на смартфон,
поднятия на нём в качестве примера Docker и веб-приложения в нём.
Сразу хочу оговориться — я понимаю, что есть типовые решения, например Termux или UserLAnd, и спектр поддерживаемых устройств у них шире. Но все они работают как надстройки над основной системой, Android, и подвержены её ограничениям, таким как агрессивное сокращение энергопотребления или перенос задач на LITTLE-ядра при выключении экрана. Будущее Termux, например, вообще неясно из-за всё более жёстких гаек безопасности в Android 11. UserLAnd, помимо этого, работает через PRoot, который при всей своей пользе ощутимо замедляет процессы с большим количеством системных вызовов. В этой статье мы разбираем именно создание сервера на железе без Android.
Часть первая. Прошивка
Проект PostmarketOS был создан именно ради этой цели — сохранение вычислительных устройств после прекращения их поддержки производителями. Список поддерживаемых устройств можно найти здесь.
Для установки требуется телефон с разблокированным загрузчиком. В качестве примера буду использовать OnePlus One из-за простоты разлочки со стороны производителя. Для каждого производителя список шагов разный, ниже привожу обобщённые действия для смартфона 2018-2021 года выпуска:
Далее авторизуем подключение на самом телефоне 
После разблокировки телефон сбросит данные снова перезагрузится в Android, перезапустите его в режим fastboot комбинацией клавиш или повторите релевантные для этого шаги 3 и 4.
Если разблокировка прошла успешно, далее можно следовать стандартной процедуре установки PmOS:
На этом этапе pmbootstrap запросит пароль и задаст довольно много вопросов о том, как сконфигурировать систему и целевое устройство. Итоговый результат будет записан в
Затем с помощью pmbootstrap install сразу же начинаем сборку образа целевой системы. После сборки её предлагается установить самому, так как механизм установки варьируется от модели к модели. Пример того, как это делается стандартно, и как вышло у меня, ниже.
После завершения процесса sideload жмём «Reboot to system». Должен пойти процесс загрузки ядра и далее самой PostmarketOS.
Часть вторая. Настройка PostmarketOS
По сути своей, PostmarketOS построена на основе дистрибутива Linux под названием Alpine. Это позволяет создать работающую систему минимального размера, что для большого количества старых устройств с ограниченной внутренней памятью критично.
Однако, есть и подводные камни. О них ниже:
Итак, после загрузки телефона с PostmarketOS нам необходимо каким-то образом с ним взаимодействовать. Если вы ставили оболочку Phosh или Plasma Mobile, скорее всего вы сможете это сделать напрямую с тачскрина телефона. Если по каким-то причинам графический интерфейс не сработал, подключайте телефон к компьютеру USB-кабелем, PostmarketOS автоматически создаст дополнительную сеть:
После чего к телефону можно будет подключиться с именем и паролем пользователя, который вы указывали при pmbootstrap install :
Если вы видите эти строчки — значит PostmarketOS установлена верно. В противном случае попробуйте посмотреть секцию Troubleshooting для вашего устройства на вики PmOS, измените конфигурацию для pmbootstrap install или спросите мейнтейнеров в IRC или Matrix чате (все три пункта ваш покорный слуга в итоге и сделал).
Настройка сети
Если не получилось настроить WiFi сеть через графическую оболочку, ниже пример как сделать это через консоль. Предварительно подключите телефон к USB-интерфейсу вашего ПК.
Серверная часть для android-приложения на Java?
Добрый день, уважаемые разработчики. Столкнулся с задачей выбора способа реализации серверной части для android-приложения. Суть: пишется небольшое приложения ради обучения. Приложение позволяет регистрироваться пользователям и редактировать информацию о книгах (книжная библиотека с CRUD функционалом). Взаимодействие будет реализовано на HTTP. В целях изучения реализации взаимодействия клиент-сервер имеется желание для сервера выбрать java, но поскольку опыта нет, интересует также Ваше мнение по этому вопросу. Возможно ли реализовать сервер именно на java с сервлетами или придётся писать на Kotlin?
1 ответ 1
Клиентом может быть любое приложение, взаимодействующее с сервером через интернет (android приложение, какой-либо сайт или десктопное приложение) Сервер никак не зависит от клиента, т.к. он лишь отвечает на запросы от клиента и т.к. протокол для всех одинаковый, то и общаться с ним могут различные приложения.
В качестве сервера можно реализовать REST или SOAP сервис. В кратце REST возвращает в качестве ответа json, а soap сервис в качестве ответа возвращает xml (знаю, что по soap можно сгенерировать код клиента на java).
Если хочется реализовать сервис на java, то можно его писать и на kotlin и на groovy, т.к. они совместимы с java (но миксовать все 3 сразу не желательно).
Теперь про клиента. На андроид можно использовать библиотеку retrofit и okhttp3 для запросов к REST сервису и библиотеку rxjava для того, чтобы данные можно было грузить в отдельном потоке не тормозя при этом UI (таким образом потом UI продолжает исполнение и как только данные загрузятся, они отобразятся).
Ниже представлен пример подключения к rest на android+kotlin