ivanessence

Сокет - это абстракция операционной системы, некая структура данных ядра, которая не зависит от языка программирования. Вы можете написать сервер на одном языке, а клиент написать на другом языке. Программа-"сервер" создает слушающий сокет (listen), программа-клиент, написанная на другом ЯП, подключается (connect) к серверу.

getLocationOnScreen() всё таки решил задачу. Проблема была в методе осуществления анимации. RotateAnimation был использован как первый попавшийся вариант, что и сыграло злую шутку. Этот способ не зря считается устаревшим. Он изменяет положение view только визуально, но физически координаты не менялись.

Кому интересно, реализовывалась простая игра типа "Колесо фортуны", где поиск выпавшего результата производится через поиск наивысшего TextView, расположенного на "колесе". Реализация довольно костыльная и простенькая, но она такой и задумывалась.

Вопрос снят. Оказывается, он по GPRS синхронизирует время.
https://pikabu.ru/story/tele2_ili_telefon_irbis_sf...
При этом официально заявлено отсутствие выхода в интернет.

Указать название класса в AndroidManifest
class MyApplication extends Application

<application    
        android:name=".MyApplication"
        .....>
...
</application>

Изучайте методы, которые давно отработаны для показа данных в различных картографических фреймворках для web.
Подходов несколько. Например, разбивать запрашиваемые данные на фрагменты одинакового (в проекции окна приложения) размера. Это позволяет не запрашивать те, которые у вас уже загружены. Можно запрашивать область больше вашего viewport-а (и комбинировать это с предыдущим методом). И делать новые запросы только тогда, когда величина scroll-а от точки предыдущего запроса превышает какое-то значение. Например, пользователь открыл карту, приложение запросило данные на покрытие viewport-а плюс 50% его ширины с каждой стороны. Пока пользователь не сдвинет карту дальше 25% ширины viewport-а от начальной точки, новых запросов не делать. Также можно озаботиться тем, чтобы сервер не пересчитывал всё каждый раз, а именно - сделать prerender для разных масштабных слоев. И использовать кэширование на стороне сервера. Или вообще превратить ваши маркеры в статичный (или закэшированный, условно статичный) растровый слой, а с сервером общаться только когда пользователь в маркер ткнёт, чтобы о нем информацию получить.

понятие велосипеда - очень разное. и задачи/необходимости тоже разные.

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

другими словами: если задачи типовые - используйте типовые решения, если задачи не типовые - от велосипедов (в хорошем смысле этого слова) не уйти.

Android Studio, скорее всего.

Android Studio.