Сам себе экосистема: Как я адаптировал старый смартфон под современные реалии и написал клиенты нужных мне сервисов

в 8:01, , рубрики: android, java, monobogdan_ништячки, php, timeweb_статьи, UI, Блог компании Timeweb Cloud, Веб, гаджеты, данные, мобилки, приложения, Программирование, разработка мобильных приложений, Разработка под android, ретро, сеть, смартфоны, телефоны
image

Время неумолимо бежит вперед: выходят новые гаджеты, постепенно заменяя старые, превращая их в тыкву или в лучшем случае, в «тапочек» для звонков. Сейчас смартфоны стали практически одинаковы во всем: дисплей на всю площадь передней панели, почти полное отсутствие аппаратных кнопок, беспроводная зарядка… Это всё, конечно, здорово, но ведь иногда так хочется взять в руки старый, но такой необычный в наше время QWERTY-смартфон и попытаться его использовать как основной, да и цены на них могут приятно удивить: БУ девайс можно купить за несколько сотен рублей (~5-10$). Одна проблема — клиенты приложений на версии Android 1.6-2.0 безбожно устарели и давно не работают. Но иногда желание воскресить старый девайс превыше потребительского качества и тут я пришёл к мысли… а почему бы не написать с нуля свои клиенты популярных приложений? ВК с музыкой, YouTube, трекинг посылок. Так я и сел писать необходимые в повседневной жизни приложения, с нуля, на голом API Android, без каких либо фреймворков (и даже AppCompat). Получилось ли у меня это? Узнаем в статье!

Мотивация

image

Но до сегодняшнего дня мы с вами обходили прикладной уровень моддинга устройств: т. е. написание самых обычных, повседневных программ, без которых сложно представить жизнь современного человека. Ещё во времена выхода первого Galaxy S в 2010 году, многие из нас уже сутками красноглазили в Java версии «аськи», кто-то уже сидел в ВКонтакте, хоть и большинство не заглядывали в смартфон каждые пару минут для проверки нотификаций.

К 2012 году смартфонная жизнь уже стала похожа на ту, к которой мы привыкли сейчас — соц. сети, мессенджеры, пуши, потоковое видео — многие из нас успели привязаться к такой жизни и… к конкретно тем самым девайсам!

image

2012 год давно миновал, тенденции в разработке приложений кардинально поменялись, а учитывая, что многие мои читатели не любят выбрасывать девайсы в мусорку (и правильно делают), наверняка кто-то регулярно заглядывает на полочку к своим пыльным «бывшим» гаджетам и рассматривает их с теплотой… но с сожалением понимает, что их время прошло. Или не прошло? :) Ну, тут как посмотреть. Если есть навыки и огромная мотивация, то программер может многое, в том числе и запилить все самые необходимые приложения сам!

Я давно лелеял эту идею, подумывая, как бы лучше её реализовать. Да и почти всю свою жизнь, я писал на C#, практически не «щупав» API Android и его UI фрейморк. В один день у меня очень сильно зачесались руки написать что-нибудь эдакое под него и причём сразу — весьма серьёзное!

image

Всем этим устройствам более 10 лет. Самым молодым из них является реплика Lumia 1020, которую мы тоже успели замоддить!

Так и родилась идея написать клиент YouTube. А потом и ВК. Ну и трекинг в придачу. Ну а чего б и нет, на всё про всё я выделил себе неделю: за это время я должен успеть закончить пусть и сыроватые, но вполне юзабельные клиенты для моих любимых сервисов. И я начал думать…

Планирование

image

Написание приложений под старые мобильные ОС, как и под любые другие платформы, требует планирования того, что и как будет работать с учётом ограничений целевой платформы. У меня было сразу несколько ограничений, что только раззадоривало пыл:

  • В большинстве своём, на старых версиях Android работают одноядерные чипсеты, а значит, лимитированная многопоточность. Никакой работы в UI-потоке кроме обновления интерфейса, а поскольку в первых версиях этой системы интерфейс менее отзывчив, чем в более свежих — нужно сохранять баланс между функционалом, симпатичностью и скоростью работы. Мои приложения должны оптимально работать в следующих условиях: 256мб ОЗУ, из которых свободно в среднем 30-40мб (Сбер, привет тебе с вылетами на 2гб ОЗУ), 1 ядро ~600мгц, видео-ядро уровня Mali300-Malii400. Негусто? Ну, нам сойдет.
  • Вторым ограничением стало тотальное устаревание корневых сертификатов, а как многие из нас знают, просто так их на мобильных системах не обновить. Поэтому придётся идти на хаки — делать сервер-реле, который преобразует трафик из https в http там, где нельзя просто отключить проверку верификации SSL (это как раз кейс с API VK). Решено — отдельный сервер-реле, который отправляет запрос на сервер ВК и обратно возвращает нам обычный результат в JSON.
  • Ну а третьим ограничением стал сам Android. targetSDK = 5 (Android 1.5 Cupcake), никакого AppCompat (кушает драгоценное свободное место), никаких сервисов Google (их тут нет лет 5 уже). Всё на чистом API системы, почти в тех же условиях, в каких 13-14 лет назад писались первые приложения для Android.
    image

    Если я его раздобуду когда-нибудь, то в лепешку расшибусь, но портирую на него свои приложения. Тогда я с гордостью скажу, что мои приложения работают на 100% Android устройств %)

Полный энтузиазма я сел писать код. Основную часть статьи я решил поделить на каждое приложение отдельно с конкретными объяснениями: где, что и как я делал. Хочется заранее сказать — я не особо давно пишу под Android, зато много писал под WinForms, поэтому какие-то решения могут показаться странными. А некоторые решения обусловлены версией Android. Например, нотификации в первых версиях Android не было Notification.Builder, а сам Notification был больше похож на структуру. Приложения, конечно же, мы будем писать на Java.

ВКонтакте

Первым делом я начал писать клиент ВК и сразу определился со своими хотелками, которые были весьма скромными: возможность листать диалоги, читать сообщения и отправлять их (с полной поддержкой QWERTY-клавиатур, т. е. отправка на Enter), плюс возможность слушать музыку без ограничений. На ВК бочку ни в коем случае не гоню, просто публичного API совсем нет, даже с ограничениями, хотя было бы здорово…

Мне снова хотелось почувствовать те эмоции, которые я когда-то ощущал от прослушивания музыки будучи школяром со своим первым Android-смартфоном. В 2013 году я прилетал со школы и слушал плейлист на практически таком же девайсе с идентичным железом и версией Android. Я хорошо помню, как пользовался прелестями многозадачности Android на 2G интернете (3G чипсет просто не поддерживал): одну песню слушаешь, поставил вторую качаться, пока песня доиграет — уже и вторая скачалась. :)

image

Итак, хотелки выбраны, пора начинать писать приложение. Для дебага у меня было 3 устройства: Galaxy S4 (Android 4.2 JB), китайский Galaxy S3 Mini I9300 (Android 2.2, на фото выше) и Samsung Galaxy S I9000 (Android 2.3), ну и конечно же эмулятор с 4.4 KitKat. Android Studio и сейчас умеет без проблем собирать приложения вплоть до версии Android 2.2 даже с последними Build Tools и Target SDK — главное выкинуть appcompat, androidx, и юнит тесты из build.gradle. Без каких-либо проблем он цепляет и сами устройства по adb. Даже отладчик без проблем работает.

Первым делом я начал писать активити (полноэкранная форма в терминологии Android, или «экран» приложения) с диалогами — он должен раз в n секунд подгружать данные и строить «морду» для всего этого. По сути, почти весь код клиента — это получение ответа от API ВК, разбор JSON на датасет и визуализация этого датасета на экран. Для этого я ввёл два объекта: VK, который делает асинхронные запросы на сервер, оборачивает работу с сервером-реле и парсит JSON и VKObjectProcessor (это скорее всего отрефакторится до VKDataSet чуть позже).

image

Архитектура приложения получилось довольно простой и примитивной. При старте активити авторизации проверяет данные приложения (PersistStorage) на наличие API-токена и при его отсутствии запрашивает авторизацию. Как это уже стало классическим среди различных «самопальных» клиентов, мой клиент «прикидывается» официальным приложением ВК — для этого используется связка app_id и app_secret приложения ВКонтакте для Android.

После авторизации приложение перенаправляет нас на страницу диалогов. Поскольку у нас нет ни пушей, ни лонгполлинга, метод обновления остается один — в заданные интервалы. Для этого у нас есть Handler, который раз в 3.5сек берет список диалогов с сервера, проверяет, обновились ли данные и если да — обновляет датасет, отправляя сигнал обновления интерфейса (который построен на ListView). Кроме того, у нас есть кэш аватарок — точно так же распаралелленый на несколько потоков, а загруженные на данный момент превьюшки хранятся в хэшмапе.

image

При этом сообщения реализованы схожим образом — на данный момент возможности горячей подгрузки сообщений «сверху» нет, поэтому обновляются последние 50 сообщений скопом и сразу. Шустро ли всё это работает? Вполне неплохо. Конечно, основное процессорное время уходит на разбор тяжелых JSON, но тут отчасти вина ВК — мало того, что кастрировали функционал getHistory в последних версиях API, так ещё и нет возможности возвращать только те поля, которые нужны.

image

Как же я поступил с аудиозаписями? Музыка через API — настоящая заноза для разработчиков клиентов, с которой пришлось «подолбаться». Правда, недолго — раз у нас для основных запросов уже есть сервер-реле, то почему бы не сделать ещё и для музыки? Суть обхода простая: если сгенерировать специальный API-токен, то можно свободно обращаться к методам, связанным с музыкой без необходимости притворяться официальным клиентом и «подписывать» запросы md5 ключом. Примитивный PHP-скрипт как раз и предоставляет такую возможность, позволяя получить доступ к базе музыки ВК, однако ограничение типичное — у пользователя должны быть открыты аудиозаписи:

<?php
	/*
	*	AudioRelay for MiniVK. (C) 2023 monobogdan.
	*/
	
	$token = "CENSORED";
	
	function vkRequest($request)
	{
		global $token;
		
		$curl = curl_init("https://api.vk.com/method/" . $request . "access_token=$token&v=5.131");
		curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
		return curl_exec($curl);
	}
	
	function audioGet()
	{
		$uid = $_GET["uid"];
		
		return vkRequest("audio.get?owner_id=$uid&count=100&");
	}
	
	function audioSearch()
	{
		$query = $_GET["query"];
		
		return vkRequest("audio.search?q=$query&count=100&");
	}
	
	function audioGetDetails()
	{
		$id = $_GET["id"];
		
		return vkRequest("audio.getById?audios=$id&");
	}
	
	function audioStream()
	{
		$url = $_GET["url"];
		
		$curl = curl_init(urldecode($url));
		curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
		return curl_exec($curl);
	}
	
	$actions = array();
	$actions["get"] = audioGet;
	$actions["search"] = audioSearch;
	$actions["getDetails"] = audioGetDetails;
	$actions["stream"] = audioStream;
	
	if(isset($_GET["act"]))
	{
		$act = $_GET["act"];
		
		if(isset($actions[$act]))
			exit($actions[$act]());
	}
	
	exit("INTERNAL_ERROR");

По итогу у меня получился рабочий плеер с поиском музыки и добавленными треками. Опять же — производительность остаётся отличной! Ссориться с ребятами из ВК не хочу, поэтому добавлять возможность качать треки пока не стал — но вам стоило бы быть подружелюбнее к разработчикам кастомных клиентов! :)

image

Что мы получили по итогу? Довольно простенький клиент ВК, который практически не потребляет ОЗУ и шустро работает. Да, здесь не хватает кучи различных фич — как минимум, прсомотра ленты и стены. Но ещё успеется — если проект будет интересен не только мне, то продолжим наращивать фишечки потихоньку! Уже ближе к релизу я слегка причесал клиент, добавив более «вкшный» дизайн и приделал анимированное боковое меню. Про Animation ещё кто-то помнит? :)

YouTube

С разработкой клиента YouTube были свои особенности: во-первых, в отличии от клиента ВК, видео через реле просто так не загрузишь, слишком много трафика, а во-вторых, YouTube уже не «отдаёт» видео в форматах, которые поддерживают старые устройства — в основном, это h263 до 720p. К сожалению, потоковое видео с софтовым декодированием уложит на лопатки большинство «одноядерников» тех лет.

image

Ситуация осложнялась тем, что ни VideoView, ни стандартные плееры всех смартфонов, на которых я отлаживал приложение, не умели игнорировать ошибки SSL и просто валились с ошибкой. Пришлось что-то придумывать: ведь видосики хочется смотреть на крутейшем AMOLED дисплее Galaxy S!

image

Посидел я, подумал и придумал. Для поиска по базе YouTube, получения информации и прямых ссылок на видео я решил использовать альтернативный фронтэнд YouTube, который называется Invidous API — крутая штука со своим API, которая сама распределяет пул токенов самого ютуба и отдаёт ответы в виде JSON. Форматы запросов очень простые: <url инстанса Invidous>/api/v1/метод, например «search?q=test&region=RU&hl=ru» — выдаст нам результат поиска «test» в Российском регионе. Очень удобно, да? А ещё Invidous — не какой-то отдельный сервис, а целая сеть т. н. инстансов — какой хочешь, такой и юзай! Поскольку большинство инстансов «прячется» за свежими сертификатами, пришлось идти на довольно известный костыль с отключением верификации хостнеймов у HttpUrlConnection:

public static void disableSSLCertificateChecking() {
        TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() {
            public X509Certificate[] getAcceptedIssuers() {
                return null;
            }

            @Override
            public void checkClientTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {
                // Not implemented
            }

            @Override
            public void checkServerTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {
                // Not implemented
            }
        } };

        try {
            SSLContext sc = SSLContext.getInstance("TLS");

            sc.init(null, trustAllCerts, new java.security.SecureRandom());

            HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
            HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() { @Override public boolean verify(String hostname, SSLSession session) { return true; } });
        } catch (KeyManagementException e) {
            e.printStackTrace();
        } catch (NoSuchAlgorithmException e) {
            e.printStackTrace();
        }
    }

А поскольку у нас нет возможности воспроизводить потоковое видео онлайн, то я решил его просто предварительно загружать через собственный менеджер закачек, с возможностью последующей очистки кэша. Поскольку таким устройствам 2060p качество не нужно, я выбираю 240p-360p mp4 в avc кодеке, в среднем ролики по 30 минут весят около 30-40 мегабайт. При HSDPA+, загрузка подобного видео займет около минуты-двух — не так уж и много, можно и подождать. Закинул тестовую версию в беседу любителей ретро-мобилок — люди были в восторге. ;)

image

Поскольку Invidous отчасти строится на анонимности — авторизации тут нет. Однако свою задачу посмотреть видосики он выполняет нормально — поэтому весь UI приложения я поделил на 4 вкладки: тренды, популярное, история и поиск. Подписки, как и историю можно реализовать на стороне клиента — для некоторых такой подход покажется плюсом, для кого-то — нет, однако минимальный задел для клиента уже есть — мы можем смотреть видео!

А где скачать?

Приложения и бэкэнд полностью открытые, исходный код доступен по лицензии GPLv3. Следить за статусом проекта можно на моём GitHub!
Последние версии можно скачать в релизах проекта.

Из текущих хотелось:

  • Портировать на Android 1.6. Несмотря на то, что приложение в целом имеет targetSDK = 5, на 2.1 оно работать отказывается. В Android, после 2.1, слегка поменялся бинарный формат xml разметок, из-за чего приложение на старых системах вылетает с исключением. Но это решаемо: eclipse adt в зубы, импортируем проект и вперед! ;)
  • Кроме того, я экспериментировал с попытками как можно сильнее уменьшить нагрузку как на сеть, так и на процессор путём облегчения датасетов. Если один JSON от ВК весит в среднем 30-60кб (который 1 ядерный чипсет частотой 600мгц может «долго» жевать, негативно сказываясь на UI), то примитивный KeyValue формат, который содержит только нужные поля умещается в 5-6-7кб в текстовом виде и благодаря своей примитивности (весь парсинг — два substring, один indexof и поиск ключа по хешмапе) совсем не «налегает» на процессор. Благодаря этим наработкам, я запилил и примитивный клиент ВКшечки для j2me.

    В целом, можно сделать единый формат датасетов для мессенджеров, а на бэкэнде реализовывать всё что угодно — Telegram, ВК, да хоть личные сообщения на хабре, а для платформ только делать «морды»: так можно завести современные мессенджеры и на Sailfish, и на J2ME, и на Symbian, и на WinMobile, практически без пота и крови :)

  • Полная адаптация под кнопочное управление. Сейчас с клиента можно без проблем писать сообщений с любой клавиатуры, в том числе и QWERTY. Однако основной интерфейс всё ещё не полностью адаптирован под кнопки и требует выполнения некоторых действий пальцем.

Заключение

Как по мне — получилось вполне неплохо. Да, приложения кое-где сыроваты и явно не дотягивают по функционалу до их больших версий. Но кое в чем они всё таки выигрывают: они лёгкие и быстрые, а самое главное — ещё могут продлить жизнь любимого девайса для кого-то. И я считаю — это классно! Среднее потребление ОЗУ обеими клиентами: 5-10мб. Вес APK: 30-50кб на момент выхода статьи. Вот что значит писать под голое API без модных фреймворков! ;)
Что до остального функционала — кое-что в Android продолжает неплохо работать и в наше время. Например, DLNA-стриминг в доме, E-Mail клиент или банкинг через смски. Я уверен, это покрывает 80% потребностей большинства пользователей — так разве после этого можно назвать старые смартфоны бесполезными?

Я писал эту статью с целью показать вам, что старые девайсы отнюдь не тыква, если есть щепотка энтузиазма в глазах и любовь к гаджетам, а заодно и поделиться с вами своими приложениями. Часто в комментариях мне пишут, что хотели бы пользоваться своими смартфонами и дальше, если бы не устаревающие версии Android. А вы как считаете? Жду ваше мнение в комментариях.

Автор: Богдан

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js