>>223574

> Кто будет хостить этот сервер?

Юзер и будет его "хостить".
Никакого централизованного сервера нет.
Почему ты думаешь про сервер именно как про удалённую машину типа VDS?

На том же самом андроид-устройстве можно спокойно запускать серверную часть.
Юзер может поставить серверную часть приложения буквально где угодно, от смартфона до пека и того самого удаленного сервера.

>Даже самый популярный дашчан при шатаниях фиксят неделями

Разумеется, ведь чтобы фиксануть дашчан, надо:
1. Разобраться со всей кучей дерьма, которая требуется, чтобы просто открыть и скомпилировать готовый андроид проект, даже ничего там не меняя.
2. Разобраться в говнокоде даши.
3. Ждать, пока даша вернётся с очередной горячей точки и смерджит пулл-реквест. А он этого делать не будет, потому что ему или похуй или ему не нравится изменение.

Допустим, я, как разработчик, вообще сдох и ничего уже фиксить не буду.
Как происходит фикс шатания в таком случае:
1. Неравнодушный юзер пишет приложение-сервер для двача буквально на любом языке программирования, на каком сможет. При этом он даже не прикасается к сложнейшему андроид-проекту, ему про андроид-разработку вообще ничего знать не требуется.
Он просто создаёт вебсервер с простой апишкой, структура которой написана на 1 странице в доках.
2. В настройках приложения прописывается адрес нового сервера.

Все. Никакой связи с автором приложения не требуется.

Сервер может иметь любой вид, лишь бы он в итоге торчал апишкой в локальной сети.
Это может быть такое же приложение для ведра, сервер на php / nodejs / python / C# / Java, образ докера, абсолютно любое дерьмо, на каком только можно написать сраный вебсервер.

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

Автоматическая рация. Увеличение пропускной полосы информации за счет структурированности и сжатия информации.

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

Пример:
Служба работы такси может работать исключительно по средствам рации, необходимости в компьютерах или мобильных приложениях отсутствует. Однако работа службы будет куда эффективнее и проще, если создать приложение для заказа такси и раздать его как водителям, так и простым клиентам. Клиентам не надо уточнять откуда их забрать и куда проехать, ведь достаточно просто выбрать точки на экране. Диспетчерам и водителям не нужно сообщать стоимость поездки, ведь стоимость будет автоматически расчитана ровно в ту секунду, когда пользователь коснется экрана, проложив маршрут. Еще за несколько касаний можно указать типичные опции вида "без музыки" или "для некурящих", в тот же момент будет перестроен список потенциальных исполнителей. Если заказ срочный, человек может парой касаний добавить бонус водителю, чтобы к нему приехали как можно быстрее. В идеальном варианте, человеческое участие диспетчера полностью исключено. А в ближайшем будущем, когда на наших улицах будут полностью автономные такси, человеческий фактор будет исключен на 100%. Если же целевая аудитория по каким-либо причинам все же не может пользоваться автоматизированной системой заказа такси, то есть возможность принятия телефонных звонков в обычном режиме, но при наличии автоматизации, диспетчер превращается в простого оператора колл-центра, что опять снижает процент ошибок, понижает порог вхождения и увеличивает количество обслуживаемых людей.

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

При экстренной ситуации, таких как масштабные пожары, наводнения или эпидемии, служба такси будет или не нужна, или сможет быть переориентирована на доставку медикаментов и продуктов питания. Люди водят машины, на которых можно перевозить лекарства - почему нет? Но сумеет ли управляющая программа продолжать предоставлять качественный сервис? Ответ: нет. В случае доставки медикаментов надо учитывать какие именно медикаменты нужно доставить, таким образом в программу как минимум должен быть интегрирован список, по которому можно делать заказы. Возможно, в программу нужно будет добавить услуги экспедитоства. Не стоит забывать, что повышенный спрос на лекарства может приводить к опустошению аптечных складов, а потому весьма вероятно будет нужна функция краудсорсинга и объявлений вида: "Ни у кого не осталось инсулина?". Подобные функции не только плохо вяжутся с основной функциональностью программы, но и могут вызывать вопросы с юридической стороны к компании, которая предоставляет подобный сервис. А следовательно, существующая информационная система терпит крах и требует возвращения к "горячим линиям", вечно уставшим диспетчерам и крайне неэффективному управлению.