peacemakerv

1) как вы разговариваете с клиентами о серверной части, объясняя, что им нужно будет заниматься ею периодически оплачивая ?

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

Чаще оставляю на своих серверах. Хорошая доплата за ничего-не-делание. Ведь оплату беру больше, чем стоит хостинг для меня. И продлевают годами и годами. Хороший дополнительный заработок.

2) как вы оформляете и передаете права доступа к консолям серверной части ? К примеру, на базе сервисов Firebase.

Иногда никак не оформляю, всё на доверии.
Иногда аккаунт сразу создан на имя клиента.

при этом совсем не имея понятия

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

Хочется же максимально бесконфликтного общения, и не разжевывать каждому клиенту что и как, и каких копеек это будет ежемесячно стоить, тем более, что это разжевывание в большинстве случаев оканчивается ничем. Т.к. или малопонятно, или "дорого" заказчику.

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

просишь у заказчика gmail-экаунт с паролем, на который регаешь проект

Для этого не нужно брать у него пароль.
Делаю и себя и его администратором проекта.
Ну а оплату - разумеется с его аккаунта.

Сделать вменяемую мобильную верстку и использовать webview.

Настоятельно рекомендую, все, что гуляет через интернет, заворачивать через http (в т.ч. websocket), само собой лучше с шифрованием (https), меньше будет гемороя, так как провайдеры (россия), а чаще мобильные, старательно тормозят или даже блокируют остальной трафик (например почти полностью убит p2p, даже webrtc испоьлзовать нужна магия).

Вернее сказать, тот трафик, которые DPI у провайдера не понимает, может быть сильно ограничен или даже сломан (лезут кривыми руками куда не следуют), поэтому не изобретайте паровоза.

На базе http берите либо готовые фреймворки и сериализаторы либо изобретайте свое. Популярные направления, использовать json, xml а если бинарный то Protobuf (вообще универсальная вещь). Для любого из указанных примеров в java есть библиотеки.

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

Сталкивался со стендами, использующих Android устройства в качестве КВУ (контроллеров верхнего уровня).

1. Стенд - большой железный ящик с кучей аппаратуры внутри.
2. Снаружи закреплен обычный планшет с уходящим внутрь usb кабельком.
3. Изнутри хаб с питанием. Питание постоянное от встроенного родного з/у, всегда воткнутого в сеть.
4. К хабу подключены usb устройства, к которым обращается приложение для стенда (используется библиотека с гита).
В т.ч. подключены устройства RS-485/RS-232.
5. Для управления автоматикой используется отечественное программируемое реле ПР-200 (недорогое, простое, универсальное). Оно берет на себя в т.ч. защитные низкоуровневые задачи, обработку органов управления с панели стенда и т.д.
6. Охлаждения дополнительного планшет не требует. Он снаружи - горячий, выключи, обдуй и т.д. Но так как он прикручен к железному корпусу (считай радиатор) - не проблема.
7. В принципе можно использовать планшет полноценно - камера/передача данных и т.п. при наличии удобного подключения (гибкое и длинное).
8. Стенды автономные, но вставленная симка, подключенный wi-fi - решают вопрос простой телеметрии и сбора статистики.
9. Можно подключить принтер/ монитор/мышку/клавиатуру.

Специализированные встраиваемые устройства:
1. Или очень дороги (но встроенными интерфейсами RS485/232 и т.п.)
2. Или дешевы и хрен работают (привет с али с устарелой осью и отсутствующей документацией)

Готовые устройства потребительские:
1. Или подороже покрасивше, но нежные. Все будет работать из коробки, в т.ч. OTG с питанием и т.п.
2. Или подешевле обрезиненные с кривоватым ПО но с известными спецификациями и внятным описание на 4pda/xda. Но могут в силу дешевизны иметь кривоватую реализацию OTG (ограничения кол-ва устройств и т.п.).

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

Yandex.Wordstat не подойдёт для допсловаря? Но он выдаёт только контекстно близкие слова, а не полный список.

Шифруйте отдаваемый контент через RSA между сервером и приложением. (SSL/не SSL - это мы сейчас не рассматриваем!)

1. Формируйте УНИКАЛЬНЫЙ! контент/трафик для каждого пользователя и расшифровывайте доставленный контент исключительно в памяти приложения, непосредственно перед моментом отображения на экране!

2. Используйте платёжные данные при шифровании данных на сервере.
3. Меняйте ключ при каждом запросе на основе номера пакета текущей сессии, времени, случайного числа и т.д.
4. Отдавайте контент порциями с разным шифрованием - prefetch/segmentation.
5. Обновляйте протокол внутреннего шифрования хотя бы раз в 1-2 месяца.

Нет 100%-ой защиты на клиенте, которая не позволила бы сохранять контент.
За то - можно это усложнить до нереальных трудозатрат.

https://www.google.com.ua/search?q=linux+proxy+for...

https://stackoverflow.com/questions/614795/simulat...

На самом деле проблема с медленными соединениями не в самой скорости, а в дропах пакетов

Packet loss

Random packet loss is specified in the 'tc' command in percent. The smallest possible non-zero value is:
2−32 = 0.0000000232%

sudo tc qdisc change dev eth0 root netem loss 0.1%

Через вэбвью и платёжный шлюз любого банка. На API 16 и выше особых проблем быть не должно.
С PayPal проще, у них есть SDK.
Просто помните, через внешние сервисы можно платить только за реальные товары. Иначе забанят.

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

написание мобильного приложения, как и любого другого программного продукта, начинается с блок-схемы (зачеркнуто) технического задания!

Для загрузки apk нужно подписать его тем же ключом, значит тебе должны скинуть ключ, пароль к нему + возможно ещё пароль от хранилища.

P.S. Загрузить apk с другой подписью нельзя по причине того, что на Android попросту невозможно накатить обновление - возникнет конфликт подписей (разве что у всех пользователей отключена проверка подписи, но для этого нужны root права)

Про Android NDK вам уже сказали. Замечу, что можно написать андроид-приложение полностью на С++, без джавы вообще. Сложно, но можно.
Java не интерпретируется. Байткод выполняется в виртуальной машине, это да, но это не интерпретация.
Дальше, существуют такие вещи как JIT(just in time) и AOT(ahead of time) компиляции.
Первая компилирует байткод в нативный код, прямо на лету, во время выполнения приложения. При этом JIT-компилятор может оптимизировать программу, опираясь на рантайм-анализ.
Вторая компилирует байткод в нативный код перед выполнением, прямо при установке, если говорить про андроид. Тут учитывается конкретная архитектура устройства.
Так что вам бы сначала изучить какие-то базовые вещи, чем гнаться за быстродействием.

1. Посмотрите стоимость андроид устройств и apple устройств. Подумайте, сколько денег есть у тех и других пользователей.
2. Посмотрите на количество приложений в гуглмаркете и в Appstore, а именно конкурентные предложения, бесплатные конкурентные приложения, подумайте.