Как сделать сервер для андроид приложения
Расскажу, как построить на любом устройстве с Android простейший веб-сервер.
Шаг 1: Установите Tiny Web Server для Android.
Для Android доступны различные серверные программные приложения. Однако многие из них устарели и предназначены для более старых версий ОС (например, PAW Server).
Мы используем Tiny Web Server. С помощью этого приложения мы загрузим базовый файл index.html и перейдем к нему с компьютера в той же сети, чтобы проиллюстрировать использование Android в качестве веб-сервера.
Шаг 2: Настройка Tiny Web Server
Этот инструмент позволяет очень просто передавать контент с телефона и получать удаленный доступ к файлам. Например, можно просматривать содержимое памяти телефона с помощью веб-браузера компьютера, если оба устройства находятся в одной и той же сети.
Из-за этой простоты нет возможности настройки Tiny Web Server. Это означает, что вы не можете заставить его использовать файл index.html по умолчанию. Тем не менее, это незначительное неудобство.
После установки Tiny Web Server запустите приложение. На главном экране у вас есть опция Изменить путь к серверу, которая полезна, если вы хотите указать каталог для хранения ваших веб-файлов.
Вы также можете указать кодовую страницу по умолчанию (полезна, если вы не размещаете англоязычный сайт) или порт сервера.
Шаг 3: Добавить Index.html на Tiny Web Server
Чтобы использовать Tiny Web Server для обслуживания веб-страниц, вам необходимо создать файл index.html и загрузить его в нужную папку. Это делается на компьютере с помощью текстового редактора типа Notepad+++.
Скопируйте файл в предпочитаемый каталог (через USB-порт или файловый менеджер Android) на устройство в /storage/emulated/0.
Скопировав файл на Android, откройте Tiny Web Server и нажмите Запустить сервер. Перейдите в браузере на URL-адрес по умолчанию, добавив /index.html в конец страницы.
Поздравляю, вы превратили ваше Android устройство в простой веб-сервер!
Заранее спасибо! Все собранные средства будут пущены на развитие сайта. Поддержка проекта является подарком владельцу сайта.
В Google Play Market есть множество подобных программ и можно выбрать то, что подойдет именно вам. Ниже скрин самого верха с плай маркета по запросу "Web serwer".
Часть из приложений платная, или триал на некоторое время - а потом покупать, есть и абсолютно бесплатные локальные веб сервера. Так-же и функционал у них разный, от простого html+php, до поддержки практически всего набора модулей и последних версий PHP+MySQL+phpmyadmin и прочих модулей.
KSWEB сервер PHP+MySQL
Этот веб сервер содержит PHP, СУБД MySQL и msmtp для поддержки функции mail в PHP. KSWEB это инструмент для веб-программирования на платформе андроид. Он позволяет вам организовать платформу для запуска и отладки сайтов на различных CMS и скриптов. Для использования приложения не нужен ROOT, но если он есть, то можно запустить сервер на стандартном порту 80.У приложения достаточно просто и интуитивно понятный интерфейс. Приложение правда платное, после установки вам дается 5дней на использование, после чего программа потребует ввести ключ, в общем ее надо будет купить. Стоимость KSWEB PRO - $3.99. Стоимость KSWEB Standard - $2.99.
MySQL хост: localhost (or 127.0.0.1) / MySQL порт: 3306 / MySQL логин "root" с пустым паролем
Данный сервер содержит полностью готовые к работе конфигурационные файлы всех компонентов. Однако, если Вы хотите их изменить, то зайдя в настройки программы и кликнув "Внешние INI", все файлы настроек будут размещены на sdcard по адресу /mnt/sdcard/ksweb/conf/
Весит данное приложение не так много, 15,55 Мб, но после установки занимает 73,9 Мб.
В пробной версии некоторые функции недоступны, и сразу скажу что этот сервер не поддерживает модуль mod_rewrite, и .htaccess, по этому движки (CMS) требующие наличие модуля mod_rewrite полноценно запустить не получится. Хотя думаю что в платной версии можно включить сервер ingix и на нем все заработает. А так все отлично работает, БД создаются и движки корректно встают. Ниже скрин приложения.
Но мне данный сервер не понравился тем что его нельзя полноценно пощупать бесплатно и надо купить, а я не хочу покупать то, что мне вообще может не подойти. Но этот сервер очень популярный, значит достойный. .
NAMP nginx android web server
Приложение тоже платное и имеет испытательный срок 10 дней, после чего NAMP предложит вам купить его. Весит приложение после установки 47,45 Мб. Цена приложения $ 1,99. Но во время испытательного срока приложение без ограничений, и самое главное есть поддержка mo_rewrite по умолчанию. У меня получилось без проблем запустить (Wordpress, Livestreet) на этом сервере и все работало. Ниже скриншот приложения.
Приложение также включает PhpMyAdmin, phpFileManager, adminer. А так-же экспорт MySQL резервное копирование на Dropbox / экспортные резервные копии сайтов на Dropbox / Резервное копирование баз данных MySQL.
В целом мне этот сервер понравился, но и тут я не хотел платить и отправился на поиски холявы. Хотя порадовал тот факт что заработал мод-реврайт и свободно запустились нужные мне движки сайтов.
ServDroid.web - простой веб сервер
Так-же я опробовал и это маленькое приложение. На самом деле я пробовал гораздо больше, просто много удалял сразу из-за рекламы или триальных периодов. Некоторые приложения были трудны в освоении или не нравились интерфейсом. Но этот маленький ServDroid.web мне понравился своей простотой. Приложение весит всего 0,96 Мб, а после установки 3,49 Мб.По сути я так понимаю это не совсем сервер, но он локально вполне корректно отображает html страницы и переходит по ссылкам на другие страницы локального сайта. Показывает он страницы в своем окне, но так-же можно при запущенном приложении открыть свой браузер и сайты откроются в нем, нужно только адресную строку ввсети "http://localhost:8080". Ниже скриншот приложения с открытой страницей тестового сайта для примера.
Сразу скажу что кроме просмотра html страниц это приложение ничего не может. У меня не заработали даже страницы с расширением (.php). Так-же не выполняется php на html страницах ни в самом приложении, ни в браузере. В общем эта программка подойдет тем, кто например занимется только html+css, или у кого сайт на чистом html.
Вот еще який представитель подоного рода приложений для платформы андроид. Весит приложение 19.96 Мб, а после установки 69.57 Мб.
Этот локальный сервер мне понравился больше всего из опробованых, и я им пользуюсь и сейчас. Но он как и множество подобных не понимает .htaccess и почему-то тоже не работает mod_rewrite, хотя он вроде присутствует. Но мне это не мешает так-как я не использую mod_rewrite в своих сайтах, да и БД (MySQL)не использую, и движки (CMS). У меня простенькие сайты на html+php и этот сервер отлично справляется с этим, так-же прекрасно через phpmyadmin создаются MySQL если нужно.
Немного технических характеристик "Палапа веб сервер"
На этом я заканчиваю этот небольшой обзор, надеюсь информация для вас была полезна.
Описанные шаги производились на смартфоне возрастом пять лет с Android 4.4. Если твой смартфон еще старше — будь готов к тому, что гайд для него не подойдет (например, из-за отсутствия поддержки LineageOS или использованных в статье утилит). Да, жизнь жестока.
Подготовка
Для начала выполним несколько подготовительных шагов.
Чистим смартфон
Первое, что нам необходимо сделать, — это очистить аппарат от мусора. Удаляем все файлы с карты памяти (внутренней и съемной), а затем делаем сброс до заводских настроек (Настройки → Восстановление и сброс → Сброс настроек). Это нужно, чтобы избавиться от установленных приложений, которые тоже могут висеть в памяти и жрать оперативку.
Также настоятельно рекомендую установить на смартфон LineageOS, а поверх нее пакет gapps-pico. Так ты получишь смартфон с доступом к маркету, но без огромного количества блоата, который так любят предустанавливать производители и Google.
После регистрации в Google сразу отключи все виды синхронизации, перейдя в «Настройки → Аккаунты → Google». На сервере от этой синхронизации никакого прока, она будет только мешать. Функции пробуждения при получении уведомления и always on display, а также светодиодный индикатор тоже не нужны. Перейди в «Настройки → Приложения» и отключи весь софт, который возможно отключить. Email, браузер, службы Exchange — все это нам не нужно.
В результате у тебя окажется система, которая по минимуму использует оперативку и не держит в памяти ненужные приложения и службы, — голый и урезанный со всех сторон смартфон. Нелишним будет получить права root. Большинство описанных в статье серверов их не требуют, но они понадобятся, если ты захочешь иметь нормальную командную строку с набором утилит Linux и полный контроль над сервером.
SSH и BusyBox
Android построен на ядре Linux, что для нас большой плюс: Linux прекрасно оптимизирован для серверов. Однако вся остальная часть системы сильно отличается от типичных дистрибутивов Linux. Здесь нет многих стандартных для Linux команд, к Android нельзя подключиться по SSH, системы контроля сетевых служб тоже как бы нет (есть местный init, но это вещь в себе).
На роль SSH-сервера отлично подойдет SimpleSSHD. Внутри это SSH-сервер Dropbear для встраиваемых устройств, снабженный графическим интерфейсом. Устанавливаем, запускаем, переходим в настройки, отмечаем галочкой опцию Start on Boot, возвращаемся назад и нажимаем кнопку Start.
SimpleSSHD выведет на экран IP-адрес, порт по умолчанию 2222. Подключиться к нему из Linux можно так:
При подключении на экране смартфона появится одноразовый пароль, который следует указать в приглашении клиента. Это очень безопасный, но не очень удобный способ аутентификации, поэтому рекомендую использовать аутентификацию по ключам. Просто переименуй свой открытый ключ ( id_rsa.pub ) в authorized_keys и положи в каталог ssh на карте памяти.
Сразу после подключения к серверу выполни команду su , чтобы SimpleSSHD запросил права root на смартфоне. Подтверди права и не забудь поставить галочку «Больше не спрашивать» (в LineageOS) или сними галочку «Спросить снова» (SuperSU). Это нужно, чтобы в будущем ты мог в любой момент получить root без всяких запросов со стороны Android.
Bash, nano, tmux, mc
BusyBox содержит только базовый набор утилит командной строки, многие из которых к тому же имеют сильно урезанную функциональность. В BusyBox нет ни bash, ни вменяемых консольных редакторов (Vi в расчет не берем, это не Vim), ни mc и tmux, без которых многие админы не представляют себе жизни.
Если тебе все это нужно, придется установить утилиты самостоятельно. Правильный способ это сделать — скачать компилятор Linaro, исходники утилит и собрать их самому. Быстрый способ — выдрать из уже имеющегося приложения, например из Terminal IDE.
Скачиваем Terminal IDE, переименовываем пакет APK в ZIP, распаковываем, находим файл assets/system-2.0.tar.gz.mp3 , переименовываем, убирая расширение mp3, и вновь распаковываем. Внутри будет множество каталогов и файлов, из которых нас интересуют только system/bin и system/etc/terminfo . Первый содержит нужные нам утилиты; просто скопируй те, что тебе пригодятся, в отдельный каталог. Второй необходим для их корректного функционирования.
Выбранные утилиты и каталог terminfo скинь на карту памяти смартфона. Затем подключись к нему по SSH и введи следующие команды, чтобы получить возможность модификации системного каталога:
Далее скопируй все нужные утилиты в /system/xbin/ и установи на них бит исполнения (на примере bash):
Затем создай файл /sdcard/ssh/.bashrc , помести в него следующие строки:
Открой настройки SimpleSSHD на смартфоне и в опции Login Shell укажи /system/xbin/bash , останови и вновь запусти сервер. При следующем входе по SSH откроется bash и будут доступны скопированные тобой утилиты.
Чтобы добиться корректной работы Vim и mc, скопируй на карту памяти также каталоги etc/mc и etc/vim , а в файл /sdcard/ssh/.bashrc добавь строки
WARNING
Если сразу после логина вместо имени пользователя и хоста ты видишь -bash-4.2$ , запусти bash повторно. Такая ошибка возникает из-за проблем с автоматическим определением домашнего каталога.
Отключаем энергосбережение
Как и любая другая мобильная ОС, Android всеми силами старается сберечь энергию. Поэтому сразу после отключения экрана он как можно скорее переводит смартфон в режим suspend, при котором прекращается/снижается подача питания не только на экран, но и на сам процессор (аналог suspend to ram в компах).
Нам такое поведение будет только мешать, поэтому его следует отключить. Для этого активируем так называемый wakelock, который заставит систему не переходить в режим suspend:
Wakelock будет оставаться активным, пока жива система, но после перезагрузки его придется активировать снова. В прошивках, основанных на LineageOS/CyanogenMod, это можно автоматизировать. Создай файл со следующим содержимым:
И скопируй его в каталог /system/etc/init.d .
Продолжение доступно только участникам
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Евгений Зобнин
Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.
Специалисты знают, насколько порой ненадежны мобильные приложения на 1С: в любой момент могут возникнуть ошибки, из-за которых базы пользователей просто разрушатся. Одновременно мы сталкиваемся с ненадежностью самих устройств: их можно разбить, потерять, их могут украсть, а пользователи хотят сохранить свои данные. И вплоть до версии 8.3.9 мы не имели платформенного механизма сохранения бэкапа.
Поскольку раньше у пользователей не было кнопки «сохранить копию», разработчикам приложения Boss пришлось самим делать бэкапы. Как мы это сделали?
Сами данные базы мы сохраняем в виде ХML.
Таким образом, разработчики дополнительно себя страхуют. Если что-то пошло не так, и вдруг сломался механизм создания копий на Гугл-Диске или Яндекс-Диске, всегда можно сказать пользователю, что в данный момент разработчик разбирается с ошибкой, а пока он может сохранить данные альтернативным способом. И пользователи остаются довольны, потому что они могут быть спокойны за свои данные.
Обязательно нужно сделать акцент на облачные сервисы, потому что если устройство потеряется или разобьется, а пользователь сохранял копию на этом же устройстве, то данные будут утеряны.
Также мы обязательно напоминаем пользователю о необходимости создания бэкапов.
Как сохранять копии, если меняется конфигурация?
Когда мы говорим о массовом решении, о приложении, которое постоянно меняется, развивается и дорабатывается, надо учитывать поведение клиентов. Пользователь может захотеть восстановить бэкап, сохраненный в старой версии приложении, где не было каких-то реквизитов. И тогда возникает задача: прочитать данные, затем дозаполнить данные по логике обновления со старой версии приложения. Как это сделать? Помимо данных, сохранить еще и саму структуру данных, чтобы потом знать, как их читать.
Есть несколько вариантов хранения этой структуры данных, в том числе ее можно хранить в самой конфигурации. То есть при выпуске каждой новой версии, сохранять структуру метаданных предыдущей версии в макет в конфигурации.
Не стоит забывать, что в мобильном приложении конфигурация не должна разрастаться просто так, мы должны дорожить местом в ней, должны делать ее наиболее компактной. Но приложение ведь развивается, и таких макетов будет много и со временем их будет становиться всё больше.
Поэтому в случае с мобильным приложением предпочтителен другой путь - сохранять структуру метаданных непосредственно в файле с данными. На выходе у нас получается вот такой файлик, где вначале мы храним какие-то вспомогательные данные – версию конфигурации, схему конфигурации, границы последовательностей, в уже после записываем сами данные пользователей в формате XML. Причем, в разделе файла "Вспомогательные данные" можно также хранить и другие важные данные, которые по каким-то причинам не получилось записать в XML.
Как читать бэкапы?
Берем ту схему данных, которую сохранили в файл, и на ее основании строим пакет XDTO для чтения файла. Создаем аналогичный объект в базе данных, заполняем его, выполняем обработки по дозаполнению при обновлении, и сохраняем уже готовый объект в базу данных.
Ниже на картинке можно посмотреть подсказку, как красиво записать модель XDTO данных конфигураций. В компании, выпустившей приложение Boss, экспериментировали с этим, находили несколько способов, но остановились именно на таком варианте записывания схемы метаданных. Когда открывается сам файл с данными, там виден обычный структурированный XML, читабельный, в котором перечислены все метаданные приложения.
Чтобы обезопасить пользователя, нужно обязательно переспрашивать его, а нужно ли ему восстановление бэкапа. Может, он просто экспериментировал и нажимал на все подряд кнопочки в приложении:) И сейчас текущие данные у него могут потеряться. Поэтому мы всегда при выполнении потенциально "опасных" действий уточняем, а действительно ли он этого хочет, и как это должно происходить. Пользователь должен отдавать себе отчет в своих действиях.
Механизм создания бэкапов обязательно должен быть, когда мы говорим об автономном решении, когда у пользователя все данные хранятся исключительно на мобильном устройстве: пользователь может свое устройство потерять, и тогда данные потеряются. И, казалось бы, если приложение работает не автономно, а связано с центральным сервером, то у пользователя не должно быть такой проблемы, ведь в случае утери устройства он подключится к серверу, получит все свои данные с сервера заново, и все будет ок.
Однако пользователи используют бэкапы не всегда так, как мы от них ожидаем:) Они очень часто используют их для того, чтобы просто «откатить» данные назад. Это правда очень странное поведение, но пользователям мобильных приложений лень разбираться, где они могли допустить ошибку при вводе данных, и они просто откатывают данные назад и заново заводят данные за текущий день. Проанализировав статистику работы с приложением Boss, мы осознали, что это нормальная практика и такое поведение пользователей встречается чаще, чем мы могли предположить.
И если у вас используется синхронизация с другими устройствами, то вы должны это обработать. Здесь есть несколько путей решения:
- разорвать связь с сервером, уточняя, что данные на нем останутся такими, как были, а копия восстановится только на устройстве пользователя;
- лучше для пользователя - дать ему восстановить копию сразу на всех устройствах, предварительно прописав такие механизмы.
Тут есть еще один момент. До сих пор мы бэкапы сохраняли сами, контролировали весь процесс, прямо в коде отлавливали действия пользователя, когда он нажимал кнопку «сохранить копию». Все это можно потом обработать. В платформе 8.3.9 появилась возможность сохранять бэкапы именно средствами платформы. И пользователь делает это без нашего ведома. Если используется синхронизация с центральной базой, то нужно обязательно обработать такой сценарий. Мы должны как-то на своем сервере узнать, что пользователь восстановил ранее сохраненную копию и должны выдать ему какое-то решение. Мы не можем себе позволить, чтобы данные рассинхронизировались.
Когда мы говорим про частное решение на мобильной платформе, то у нас, как правило, есть заказчик, который, например, хочет использовать мобильную платформу для своих торговых агентов, и чтобы они обменивались данными с центральной базой. Здесь все просто: одна база данных, несколько устройств, вы поднимаете сервер, настраиваете связь с ним. Так что проблема обмена между устройствами решается легко.
Но если мы говорим о массовом приложении, где много баз данных, у каждой из которых очень много пользователей, ситуация усложняется. Пользователи скачали приложение с маркета, и они хотят синхронизироваться друг с другом. Например, муж скачал приложение для учета личных финансов, и теперь хочет, чтобы жена тоже подключилась, и они вместе работали в одном приложении. Пользователей много, приложение развивается, растет, и появляется необходимость в большом-пребольшом количестве баз данных. Как это все организовать? Пользователи же не будут персонально обращаться к разработчикам, чтобы те создали для них отдельную базу и включили возможность синхронизации. Они хотят нажать на кнопочку, и чтобы все сразу же заработало. В тот же момент.
Как поступить? Тут на помощь приходит механизм разделения данных. Он позволяет организовать единую базу данных, где есть одна общая конфигурация, но при этом в рамках одной общей базы хранится неограниченно много баз пользователей.
Самое приятное, что можно динамически, программно, без нашего участия добавлять пользователей. Реально пользователи просто нажимают на кнопочку «зарегистрироваться на сервере», и все само происходит: ему создается персональная база на сервере, и он может тут же начинать работать в ней.
Как это сделать? Первое и самое просто решение – написать свою серверную базу с этим механизмом. Когда наша компания начинала делать приложение Boss и обмены в нем, в первой версии мы так и сделали: написали серверную базу с механизмом разделения данных. Все работало, тем более что ничего сложного не было – разделителем баз является общий реквизит.
Но потом мы поняли, что изобретаем велосипед:) На самом деле есть уже готовое решение, причем в нем уже учтены моменты, о которых мы еще даже не думали. Это 1С:Фреш.
Здесь продуманна масштабируемость сервиса: что делать, когда будет очень много данных и баз, как расти с этим всем. Здесь есть момент о создании резервных копий областей данных: то есть мы не просто делаем бэкап одной общей базы данных, мы делаем копии конкретного пользователя. Причем, механизм там такой, что копии делаются только тогда, когда они реально нужны. Если пользователь не заходил неделю в базу, то мы не делаем ему копии, потому что там ничего не изменилось. Еще одна фишка Фреш – в сервисе реализован механизм для снижения нагрузки на сервер, а это очень важно, когда у вас много баз.
В целом Фреш для нас – что-то новое и интересное. Потихоньку мы пытаемся разобраться в нем, но в большинстве своем мы просто довольны его работой.
Передача данных. Как реализовать ее для обмена между устройствами
Итак, наша цель – реализовать обмен в режиме реального времени. То есть мы стараемся не делать так, чтобы пользователю пришлось зайти куда-то, нажать на какую-то кнопку, думать о том, насколько актуальные у него данные, должен ли он проводить актуализацию…У пользователей данные всегда должны быть актуальны. Они так привыкли, работая в мессенджерах – один данные отправил, другой их тут же получил. Все происходит моментально. То же самое касается приложений, касающихся бизнеса: один продавец оформил продажу, другой должен тут же увидеть актуальную ситуацию, никаких действий при этом не совершая.
Мы задумались, как этот процесс можно ускорить.
Важный момент использования PUSH – не раздражаем пользователей.
Еще один нюанс обмена – это работа через веб. Нам нужно использовать асинхронность максимально. Вы не можете работать как обычно – написали код – вызвали функцию – подождали, пока она выполнится – получили ответ – и все ок. Если вы работаете через веб, вы все равно столкнетесь с определенными ограничениями, например, с нестабильным интернетом, срабатываением таймаутов при выполнении длительных операций. Поэтому надо заранее продумывать архитектуру.
Посмотрим на примере регистрации устройства, что происходит в приложении, когда пользователь хочет зарегистрироваться. Он ведет учет какое-то время, он ввел достаточно много данных, но потом он хочет, чтобы продавец тоже работал с этой базой. Пользователь нажимает на кнопку «зарегистрироваться». Вначале все было очень просто: взяли его данные, записали на сервере, и, пожалуйста, можно работать и подключать пользователей. Но потом мы столкнулись с ситуацией, когда у некоторых пользователей базы данных на устройстве к моменту регистрации уже сильно разростались. И эта схема уже не работала, т.к. пока шла запись всей базы на сервере, срабатывал таймаут соединения или просто обрывался интернет. Поэтому мы заменили один синхронный вызов на множество коротких. Сейчас данные делятся, а не передаются все за один раз. Мы не ждем ни в коем случае, пока сервер будет обрабатывать и записывать данные. Отправили данные, получили ответ, что данные получены, закрыли соединение. Периодически надо опрашивать сервер, что там и как происходит, а тем временем на сервере работает фоновое задание, которое записывает полученные данные. Таким образом, получается много вызовов сервера, но у нас есть гарантия того, что все пройдет хорошо. И ни таймауты, ни нестабильность интернета не помешают произвести выгрузку всех данных на сервер.
Обмен между устройствами с разными версиями приложения
Поскольку мы говорим о массовом приложении, которое выпускается в маркеты, надо учитывать некоторые особенности процесса обновлений и обмена данными.
Если вы выпустили приложение для одного предприятия и решили его обновить, то обычно вы просто даете команду, чтобы все сотрудники дружно установили новое приложение. С пользователями, которые скачали приложение из маркета, так сделать нельзя. Вы вообще не можете им указывать, что им делать. К примеру, они работают в приложении и не хотят обновлять его ни сейчас, ни вообще никогда. У них не стоит автообновление, поэтому совершенно обычная ситуация, когда к центральной базе подключено несколько устройств, и все они с разными версиями. Еще одна причина такого явления – время публикации в маркетах: оно разное для iOS и Android. Мы часто внедряем ключевые штуки, например, исправляем критические ошибки, и не хотим ждать, пока iOS проверяет две недели новую версию, мы хотим хотя бы только для Android, но выпустить обновление прямо сейчас.
Мы не имеем права командовать пользователями. Если они хотят, то обновляются, а если нет – то ничего не делают. На картинке видно соотношение установок приложения Boss по версиям в GooglePlay, а также статистика с нашего сервера - реальное соотношение версий приложения, которые установлены на устройствах, обменивавшихся с сервером данными в течение последней недели. Вот такой набор, с которым надо работать. Это разные версии и разные метаданные. И нам надо организовать нормальный обмен при этом:)
Перед разработчиками стоят следующие задачи:
- Надо, чтобы все это работало. Пользователи не должны чувствовать дискомфорта от того, что они забыли обновиться. Они вообще не должны этого замечать. Обновились – стало лучше, ну и хорошо.
- Мы должны обеспечить сохранность данных. Например, у одного пользователя появился справочник и новый реквизит, а у другого еще нет. При этом если пользователь, у которого новых реквизитов нет, изменит у себя на устройстве что-то, то на других устройствах данные не должны пропасть.
- Надо обеспечить актуализацию данных, когда мы переходим на новую версию. Когда пользователь решит, что он готов обновиться, у него автоматически должны появиться все новые сведения, которых у него не было только потому, что у него была старая версия.
Как мы это сделали?
2. Для записи и чтения объектов мы используем тот же механизм, который используется для бэкапов, то есть сохраняем версию метаданных. В данном случае мы работаем с сервером, и мы можем позволить себе прямо в конфигурацию добавлять все, что угодно, поэтому просто в виде макетов добавляем в конфигурацию схемы метаданных по мере развития приложения.
Как мониторить массовые ошибки при обмене и на сервере
Во-первых, надо контролировать доступность самого сервера. С серверами такое бывает – они падают. Мы не выдумывали ничего особенного для мониторинга, а просто нашли бота в телеграмме, который кричит, если что-то не так. Он каждую минуту проверяет работоспособность сервера, и если вдруг сервер недоступен, начинает кричать, админы это видят и поднимают сервер.
Также мы собираем лог ошибок из журнала регистрации. Тоже ничего сверхъестественного – просто каждые три часа собираем лог ошибок, отправляем их на почту, периодически их просматриваем. Это помогает видеть частые проблемы и какие-то исключительные ситуации. Не сложно просматривать почту, отслеживать и быстро исправлять ошибки. Но это позволяет оперативно выявлять и решать проблемы, которые могут разрастаться с ростом баз данных.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER. Больше статей можно прочитать здесь.
В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.
Читайте также: