сервер для мобильных приложений
Факторы, которые следует учитывать при выборе лучшей серверной части мобильного приложения в 2021 году
Сделайте свое мобильное приложение более безопасным и управляемым с помощью лучшей серверной части.
Интернет-реклама через мобильные приложения становится все более популярной среди предприятий. Согласно отчетам Statista, доход от мобильных приложений к 2020 году достигнет 189 миллиардов долларов. Большая часть этого дохода будет получена за счет рекламы в приложениях, а также от продаж в маркетах, таких как Apple App Store, Google Play.
В связи с ростом использования мобильных приложений владельцы бизнеса направляют значительные средства на управление серверной частью мобильных устройств. Использует ли ваше бизнес-приложение такие функции, как аналитика использования, расширенная безопасность, связь между пользователями, push-уведомления и обработка рекламы?
Вам понадобится серверная часть для управления хранением данных, безопасностью и бизнес-логикой. Одним из важнейших аспектов управления серверной частью мобильного приложения является то, как и где его разместить.
Как выбрать серверную часть для мобильного приложения
Давайте разберемся в этом подробнее —
Односерверный хостинг
Разработка мобильных приложений и Бэкэнд-хостинг на одном сервере — это самая простая установка для предприятий, которые не ожидают быстрого масштабирования. Если один сервер настроен правильно, размещен на надежном сервере и регулярно выполняется резервное копирование, это отличный и экономичный подход к внутреннему хостингу мобильных приложений. Как сообщает HostInspection, единственным недостатком односерверного хостинга является то, что если один сервер, на который опирается ваше приложение, выходит из строя, вы испытываете серьезные функциональные сбои, которые могут причинить неудобства пользователям и потенциально повлиять на вашу деловую репутацию.
Существуют серверы хостинга, которые предоставляют вам простые способы масштабирования вашего сервера по мере увеличения количества пользователей. Примерами являются DigitalOcean и IBM SoftLayer. Для таких серверов важно убедиться, что экземпляр сервера имеет быстрое сетевое подключение, гарантированные ресурсы и хорошие инструменты для управления нагрузкой.
Мультирегиональный хостинг
Для предприятий, ориентированных на клиентов на разных континентах, расположение серверной части мобильного приложения влияет на общее впечатление от приложения. Это влияет на пропускную способность сети и задержку в сети между клиентом и сервером. Существуют и другие соображения, которые следует учитывать в региональных правилах размещения данных. Например, предприятия, работающие в России и ЕС, должны размещать серверную часть своего приложения в ЕС, если на серверной части приложения есть какие-либо личные данные.
Assets Hosting
Ваше приложение полагается на множество загружаемых ресурсов, таких как изображения, видео, шрифты и т.д.?
Рассмотрите возможность использования сети доставки контента (CDN).
CDN — это группа серверов, распределенных в разных географических областях и работающих вместе для быстрой доставки интернет-контента. CDN позволяет быстро передавать такие ресурсы, как HTML-страницы, таблицы стилей, файлы javascript, видео и изображения для загрузки интернет-контента. Большинство провайдеров серверного хостинга мобильных приложений имеют простой вариант (такой простой, как один щелчок) для облегчения обмена файлами непосредственно в CDN.
MBaaS
MBaaS — один из самых простых вариантов размещения серверной части вашего мобильного приложения. Это позволяет разработчикам приложений быстро создавать решения, использующие новейшие функции мобильных устройств.
Поставщики MBaaS используют модель как услугу, в которой вы потребляете услугу в качестве поставщика для управления своей серверной частью.
Если вы выбрали вариант MBaaS, вам необходимо придерживаться следующего контрольного списка:
Вывод
Поставщики серверного хостинга для мобильных приложений значительно различаются, когда дело доходит до их предложений. Вы можете найти большие различия в задержках во внутренней сети двух ведущих облачных провайдеров. Если не ожидается, что ваше бизнес-приложение в ближайшем будущем получит тысячи пользователей, выберите вариант MBaaS или настройте один сервер. MBaaS отлично работает, когда время выхода на рынок является главным приоритетом.
Разработка сервера мобильных клиентов
Обратная сторона мобильных клиентов — сервер.
Введение
Не открою секрета, что разработка мобильных приложений в тренде – этому способствует стремительное техническое развитие: мобильные устройства с каждым годом улучшаются по всем характеристикам и становятся доступнее для широкого круга людей. Почти каждый, кто имеет на руках мобильный гаджет (будь то смартфон, коммуникатор или планшет) пользуется приложениями: браузером, клиентом электронной почты и мгновенных сообщений, играми, бизнес или финансовыми программами. И зачастую от пользователей скрыто то, что многие из приложений взаимодействуют с удаленным сервером: обмениваются с ним данными через Интернет.
По роду деятельности (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 достаточно сильно зависит от реализации и интеграция без знания нюансов отнюдь не прозрачна. В такой ситуации придется взвесить, какой фактор важнее и сделать выбор.
ASP.NET Core: Создание серверных служб для мобильных приложений
Представляем вторую часть из серии статей, посвящённых разработке на ASP.NET Core. В этом обучающем материале вы узнаете, как создавать серверные службы с помощью ASP.NET Core MVC для поддержки мобильных приложений.
Второй цикл статей по ASP.NET Core
Первый цикл статей можно найти здесь.
Образец мобильного приложения
Мобильные приложения могут без труда обмениваться данными с серверными службами ASP.NET Core. Здесь можно скачать образец кода серверных служб.
В данном материале в качестве клиента используется приложение Xamarin Forms ToDoRest. Оно включает отдельные клиенты для устройств под Android, iOS и Windows. По ссылке выше вы найдёте руководство, которое поможет создать приложение (и установить необходимые бесплатные инструменты Xamarin), а также сможете скачать образец решения Xamarin. В него входит проект двух служб ASP.NET веб-API, на замену которым приходит приложение ASP.NET Core из этой статьи (со стороны клиента изменения не понадобятся).
Функции
Приложение ToDoRest поддерживает составление списков, добавление, удаление и обновление элементов To-Do. Каждый элемент наделён своим идентификатором, названием, примечаниями и свойством, которое указывает, выполнен ли элемент.
В основном представлении элементов, как показано выше, имеется название каждого элемента, а наличие флажка указывает, был ли он выполнен.
Коснитесь значка +, чтобы открыть диалоговое окно для добавления элементов:
Коснитесь элемента в главном списке, чтобы открыть диалоговое окно для редактирования названия, примечания и статуса выполнения, либо чтобы удалить элемент:
Создание проекта ASP.NET Core
Создайте новое веб-приложение ASP.NET Core в Visual Studio. Выберите шаблон веб-API и отключите аутентификацию. Присвойте проекту имя ToDoApi.
Примечание: обязательно запустите приложение напрямую, а не через IIS Express, который по умолчанию игнорирует не локальные запросы. Выполните dotnet run из командной строки либо выберите название приложения из раскрывающегося меню Debug Target на панели инструментов Visual Studio.
Добавьте класс модели для представления элементов To-Do. Отметьте обязательные поля с помощью атрибута [Required] :
В этом примере при реализации используется частная коллекция элементов:
Настройте реализацию в Startup.cs:
Теперь можно перейти к созданию ToDoItemsController.
Создание контроллера
Для работы контроллера необходим параметр IToDoRepository; запросите экземпляр этого типа через конструктор контроллера. В среде выполнения этот экземпляр будет предоставлен благодаря поддержке платформы для внедрения зависимости.
Этот API поддерживает четыре команды HTTP для операций создания, чтения, обновления и удаления (CRUD) в источнике данных. Самая простая операция — Read (чтение), она соответствует запросу HTTP Get.
Чтение элементов
Метод List выдает код ответа 200 OK и список всех элементов ToDo, сериализованных как JSON.
Вы можете протестировать новый метод API с помощью ряда инструментов, например Postman, как показано ниже:
Создание элементов
Внутри метода проверяется, правильно ли составлен элемент и существовал ли он ранее в хранилище данных; если ошибок нет, он добавляется с помощью репозитория. ModelState.IsValid выполняет проверку модели; это следует сделать в каждом методе API, который принимает вводимые пользователем данные.
В образце используется перечисление кодов ошибок, передаваемых в мобильный клиент.
В ответе метод выдает только что созданный элемент.
Обновление элементов
Чтобы протестировать Postman, измените команду на PUT и добавьте ID обновляемой записи в URL. Укажите данные обновляемого объекта в теле запроса.
При успешном выполнении метод выдает ответ NoContent (204), обеспечивая тем самым согласованность с существующим API.
Удаление элементов
Помните, что при тестировании функции удаления в тело запроса добавлять ничего не нужно.
Посоветуйте сервер для Android-приложения
Собираюсь писать android-приложение. В котором буду использовать сервер. Почитал в интернете про различные сервера, ну так и не пришел к выводу что лучше и на чем писать (смотрел в сторону JSON-сервера ) Посоветуйте сервер, логика приложения в том что у каждого пользователя есть свой id. По отобранным критериям он будет получать данные с сервера, и может ставить рейтинг полученным данным(статье), и оценка идет на сервер. Какой вы могли бы порекомендовать для данного функционала?
2 ответа 2
Обычно «сервер» пишут самостоятельно на удобном для разработчика языке. Так как ваше android-приложение с высокой степенью вероятности написано на Java, то и серверный функционал можно написать на Java. Пишите логику на Servlet API или Spring MVC и разворачиваете в каком-нибудь web-контейнере, типа Tomcat или Jetty. Но если вам нужен способ получать из БД данные в формате JSON с минимальными телодвижениями, то посмотрите на PostgREST.
Если писать свой сервер нет желания/времени/знаний то можно использовать какой нибудь SaaS сервис. Например, Google предлагает Firebase, который достаточно просто интегрируется в Android приложение (также есть поддержка iOS). Он предоставляет много фишек сразу из коробки, например, реалтайм синхронизацию данных на сервере и устройстве.
Конечно, функционал его ограничен и его не расширить по своему желанию, как это можно сделать с самописным сервером, но под описанную в вопросе задачу он вполне подойдёт.
Похожие
Подписаться на ленту
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.11.5.40661
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Простой клиент-сервер на Android (интернет-мессенджер)
Важно. Все написанное ниже не представляет собой какой либо ценности для профессионалов, но может служит полезным примером для начинающих Android разработчиков! В коде старался все действия комментировать и логировать.
Поехали. Многие мобильные приложения (и не только) используют архитектуру клиент-сервер. Общая схема, думаю, понятна.
Уделим внимание каждому элементу и отметим:
Клиент, установленный на устройстве А, посылает сообщение для клиента, установленного на устройстве Б. И наоборот. Сервер играет роль связующего звена между устройством А и Б… С, Д… и т.д. Также он играет роль «накопителя» сообщений, для их восстановления, на случай удаления на одном из клиентских устройств.
Для хранения сообщений используем SQL БД как на сервере, так и на устройствах-клиентах (в принципе, вся работа клиентов интернет-мессенджеров и сводится к постоянной синхронизации локальной и удаленной БД с сообщениями). Дополнительно, наш интернет-чат будет уметь стартовать вместе с запуском устройства и работать в фоне. Взаимодействие будет происходить путем HTTP запросов и JSON ответов.
Более логично, если синхронизация происходит через порт/сокет, это с одной стороны упрощает задачу (не нужно циклично слать HTTP запросы на проверку новых сообщений, достаточно проверять состояние прослушиваемого сокета), но с другой стороны, это усложняет создание серверной части приложения.
Делаем сервер
Для реализации «сервера», нам нужно зарегистрироваться на любом хостинге, который дает возможность работы с SQL и PHP.
Создаем пустую SQL БД, в ней создаем таблицу.
Структура запросов к api:
Клиентская часть
Теперь структура Android приложения:
В фоне работает FoneService.java, который, в отдельном потоке, каждые 15 секунд делает запрос на сервер. Если ответ сервера содержит новые сообщения, FoneService.java записывает их в локальную БД и отправляет сообщение ChatActivity.java о необходимости обновить ListView, с сообщениями. ChatActivity.java (если она в этот момент открыта) получает сообщение и обновляет содержимое ListView из локальной БД.
Отправка нового сообщения из ChatActivity.java происходит сразу на сервер, минуя FoneService.java. При этом наше сообщение НЕ записывается в локальную БД! Там оно появится только после получения его назад в виде ответа сервера. Такую реализацию я использовал в связи с важным нюансом работы любого интернет-чата — обязательной группировкой сообщений по времени. Если не использовать группировку по времени, будет нарушена последовательность сообщений. Учитывая, что клиентские приложения просто физически не могут быть синхронизированы с точностью до миллисекунд, а возможно будут работать даже в разных часовых поясах, логичнее всего будет использовать время сервера. Так мы и делаем.
Создавая новое сообщение, мы передаем запросом на сервер: имя автора сообщения, имя получателя сообщения, текст сообщения. Получая эту запись назад, в виде ответа сервера, мы получаем то, что отправляли + четвертый параметр: время получения сообщения сервером.