Как бесплатно расшифровать аудиофайл и перевести его в текст на телефоне
Картинка для привлечения внимания
В современных телефонах памяти становится всё больше даже в бюджетных моделях, а значит возможно хранить больше данных.
Помню, лет 15 назад, когда ставили специальные приложения на смартфоны для записи телефонных разговоров была проблема в том, что записи занимали слишком много места и их приходилось регулярно удалять.
Сегодня такой проблемы нет, но есть другая - тяжело слушать длинный разговор. Это занимает много времени, качество голоса может быть не очень хорошим.
Вот было бы здорово перевести аудио в текст и спокойно найти ключевые слова и моменты беседы, чтобы не слушать зря 20, а то и 40 минут беседы.
И такой способ есть.
Сейчас я покажу, как с телефона или ПК, получить бесплатно до 100 минут расшифрованной речи из аудио в виде текста.
Как распознать аудио бесплатно
Для тех, кто не любит видео, пишу текстовую инструкцию:
Запустите браузер, введите в адресной строке: vk.com/voice-tech
Откроется сервис по распознаванию речи от VK, необходимо авторизоваться, чтобы получить доступ.
После авторизации (уверен, у вас есть VK аккаунт) появится кнопка "Выбрать файл".
Загружаете любой аудиофайл и ждёте несколько секунд, после чего сервис предлагает прочитать текст, либо сохранить его на смартфон или ПК в виде текстового файла.
Вот и всё, у вас на руках беседа, или песня, или что-то иное в виде текста, теперь с ней можно работать.
Если по необычайному стечению обстоятельств вам стало любопытно, есть ли ещё подобные лайфхаки для смартфонов Xiaomi - добро пожаловать на MetaMi.
Сам себе экосистема. Часть 4: как я реализовал клиент Telegram на Android-смартфоне 14-летней давности?
С момента выхода первой части статьи из рубрики «сам себе экосистема» прошёл уже практически год! За это время, мы успели с вами реализовать клиенты VK и YouTube, которые работают на Android 2.2+, а также на Windows Phone 8, написать небольшую 2D-игру с нуля весом менее 1Мб, которая работает практически везде и довести существующее приложение до ума, дабы оно работало даже на смартфоне с дисплеем 240x320! Но на дворе 2024 год, люди стремительно переходят из соц. сетей в продвинутые мессенджеры и уже сложно себе представить современного человека, который не пользовался бы «телегой» или даже «вайбером» в качестве основного средства общения. Поэтому я решил реализовать клиент Telegram на смартфоне 14-летней давности на базе официальной реализации MTProto от команды Telegram — TDLib. Сегодня мы с вами: узнаем новые причины мотивации вернуть в строй смартфоны прошлых лет, напишем на C# реле-сервер, который обрабатывает пакеты MTProto и кодирует их в простой текстовый формат датасетов, который можно моментально обработать даже при нестабильном GPRS-соединении на 21-летнем Siemens C60, а также узнаем о разработке миниатюрных Android-приложений на базе «голого» API-системы, которые не тянут за собой никаких зависимостей, в том числе и AppCompat/androidx. Интересно? Тогда жду вас под катом!
❯ Содержание
❯ Но зачем всё это?
На дворе уже стукнул 2024 год, современные смартфоны предлагают какие-то немыслимые мощности относительно тех, которые когда-то были в первых Android-девайсах. Сейчас за сотню баксов можно купить смартфон с хорошей 1080p IPS-матрицей, 4Гб ОЗУ и 8-ядерным шустрым чипсетом, который вполне способен плавно тянуть даже стремительно «жиреющие» на ресурсы клиенты социальных сетей, банков и прочие необходимые в повседневной жизни приложения.
И казалось бы: всё хорошо, покупай себе редмик раз в год или айфон раз в несколько лет и наслаждайся всеми прелестями работы современных приложений…
Для многих людей смартфон — это лишь инструмент, повседневный компаньон, который помогает облегчить выполнение каких-то задач. Им совершенно не важно, как он выглядит, как ощущается в руках, какой у него дисплей и железо «под капотом», лишь бы работал да и нормально. Но есть и другая категория людей, для которых телефоны, смартфоны и любые портативные гаджеты — это не просто утилитарный девайс, а настоящее инженерное произведение искусства, с которого буквально сдувают пылинки и стараются до последнего пользоваться ими как повседневными устройствами. Хотите пример? Смотрите ниже:
Фактически, среди современных смартфонов по сути и нет представителей такого нынче вымершего форм-фактора, как сайдслайдеры с физической QWERTY-клавиатурой, боковые раскладушки с двумя дисплеями и даже из QWERTY-моноблоков есть только смартфоны от Unihertz. Даже среди моноблоков с тачскринами нет никакого разнообразия, лишь без-рамочные одинаковые девайсы за исключением устройств от Sony.
Galaxy S Plus
Раньше меня часто спрашивали, мол, да как ты вообще можешь пользоваться смартфоном 10-летней давности, на котором давно нет официальных клиентов популярных сервисов и только недавно, с развитием блога, мне перестали задавать этот вопрос, поняв, что это бесполезно — ведь это дело принципа и порыва энтузиазма! Смотрите сами: у нас уже есть простенькие, но вполне рабочие клиенты ВК, YouTube, сейчас я допиливаю клиент «Сбера» на СМСках, реализую карты OpenStreetMap (правда пока без адекватной навигации), а в будущем планирую написать приложение для мониторинга погоды и трекинга посылок. Кроме того, в рамках этой статьи мы реализуем с вами клиент Telegram: так чем же это не функционал современного смартфона?
Но хорошо, с функционалом разобрались, однако для многих читателей слова «старый смартфон» это прямые синонимы «тормозной смартфон», мол «фуу, да как можно пользоваться этим тормозным кирпичом, он же лагает в последней версии моей ВКшечки!». Но давайте поставим вопрос ребром: может, это не столько девайсы немощные, сколько сами приложения, с кодовой базой, которая тянется более 10 лет, откровенно жиреют, обрастают костылями и хаками после далеко не одного поколения программистов, которые над ними работали? :) Один, вот, предпочитал пользоваться чистым AppCompat'ом, другой решил притащить зависимость, которая, например, оптимизирует виртуализацию ListView, третий решил заменить всю сериализацию Json со встроенных классов в Android на что-то стороннее и реализовал это костылями и вот так, по чуть-чуть изначально оптимальный и шустрый код превращается в неповоротливое УГ, которое не рефакторили кучу лет.
На видео Galaxy Pocket Neo — очень дешёвый Android-смартфон из 2011 года с 1-ядерным чипсетом на ~800МГц и 256Мб ОЗУ. При этом всём, Android софтварно рисует все анимации на процессоре, без участия GPU.
А значит у стареньких девайсов всё равно есть шанс быть полезными и стать полноценными повседневными смартфонами даже спустя более чем десять лет после выхода! И в сегодняшнем материале, я вам расскажу об особенностях разработки самопального клиента Telegram с собственным прокси-сервером, которое концептуально допускает реализацию даже на кнопочном Siemens C60 2003 года. Как? Читаем ниже!
❯ Принцип работы
В отличии от ВК (который разрабатывали те же самые люди, что и Telegram), API которого построено на базе REST-запросов и концепции Longpolling'а для моментального получения событий с сервера, Telegram построен на базе собственного протокола под названием MTProto, который может работать поверх любого «транспорта» (протокола нижнего уровня) — TCP, HTTP, WebSocket и т.п. Сам по себе MTProto в современном виде, разработка прожженного математика Николая Дурова и его команды — протокол относительно сложный для реализации «на коленке» и в первую очередь требует довольно серьезного понимания принципов работы современной криптографии, да и документирован он всё ещё не особо хорошо. Кроме того, у MTProto весьма интересный бинарный формат пакетов, эдакий велосипед Protobuf. В долгосрочной перспективе поддерживать свой велосипед MTProto может быть весьма проблематично, учитывая не самую лучшую документацию.
Но городить велосипед и не нужно, поскольку у команды Telegram есть официальная реализация MTProto — библиотека TDLib, которая инкапсулирует в себе не только детали реализации протокола, но и сетевой ввод/вывод и выбор транспорта, хранение базы данных сообщений и авторизации, автоматическую загрузку фото и видео, конвертация объектов из бинарного формата MTProto в JSON и полная многопоточность и частичная потоко-безопасность. С одной стороны это плюс — уже готовое решение для реализации клиента на новой поддерживаемой платформе, где есть OpenSSL (можно статически слинковать), zlib (линкуется статически), сокеты и файловый ввод/вывод, а также довольно неплохой механизм JSON-based API, которое позволяет использовать библиотеку в любом языке, который поддерживает вызов C-функций, а с другой и минус — библиотека довольно много весит, в одиночку прибавляя ~20Мб веса приложения для каждой архитектуры, у неё течёт память и у нее странный механизм получения данных с сервера (например, нельзя ответить на сообщение, зная его ID, если сообщение предварительно не загружено, при том что на сервере весь ответ — это просто ID, на какое сообщение прилетел ответ).
Понятное дело, что на стареньком смартфоне использовать оригинальный TDLib будет проблематичным — даже если собрать либы современным NDK и запилить JNI-интерфейс, библиотека «жрёт» много ОЗУ (20-100Мб «вхолостую», в зависимости от числа диалогов и частоты прилетающих событий, плюс со временем течет до 1-2Гб, если не использовать базу данных сообщений. Скорее всего, это косяк в реализации пулов, объекты из которых выгружаются при сбросе в базу, но не выгружаются при высоком потреблении ОЗУ) и уж тем-более TDLib не запустить на любимых кнопочных Java-сонериках! Поэтому я решил написать прокси-сервер, который отправляет команды, слушает ивенты TDLib и предоставляет REST-like API для клиентских программ, которые просто вызывают какой-либо метод, а в ответ получают простой и короткий строковой датасет только с необходимыми полями, весом до 10Кб (что позволяет его быстро загрузить даже с GPRS-интернетом), который можно быстро распарсить даже на преусловутом Siemens C60!
К сожалению, поскольку TDLib прожорлив, я не смогу захостить на своём сервере инстансы для читателей, которые хотят поюзать приложение, поэтому вам придется ставить и запускать сервер на своём VDS/компьютере с белым IP/роутере, если под него есть .NET Core :)
Клиентом же будет выступать Android-смартфон, где приложение будет фронтэндом данных с сервера. Ничего сложного на первое время нет: первое окно — это список диалогов, второе окно — список сообщений в диалоге + поле для написания сообщения, третье окно — информация о пользователе. Всё это я реализовал за три дня не-напряжной работы «на коленке».
Давайте же перейдем к реализации сервера!
❯ Прокси-сервер
Сервер я решил писать на C#, поскольку у .NET Core сейчас всё очень хорошо с кроссплатформенностью и производительностью. Его можно даже на Raspberry Pi запустить :)
Итак, какая-же архитектура такого сервера может быть? Программа инициализирует TDLib, начинает слушать её события в отдельном потоке, пока в основном потоке крутится HTTP-сервер, который обрабатывает каждый отдельный запрос с клиентского приложения. Почему синхронно? Потому что TDLib фактически не возвращает никаких идентификаторов для возвращаемых датасетов, дабы их можно было отличить друг от друга. Приведу пример: у нас есть метод getChatHistory, который возвращает n-сообщений. При этом TDLib сам определяет, сколько хочет сообщений вернуть (и в первый вызов возвращает одно сообщение вне зависимости от настрое и отправляем пакет message n-раз. При этом в пакете message нет какого-либо ID, который позволял бы ассоциировать текущий объект с какой-либо операцией. Увы!
Начинаем с коммуникации с TDLib. Для работы с библиотекой, мы будем использовать json-интерфейс. Для .NET есть биндинги через C++/CLI, но в таком случае, сервер не будет работать на Linux. Для работы с библиотекой хватит лишь три функции: CreateClientID, которая аллокейтит новый инстанс клиента, Send, которая асинхронно отправляет JSON-объект с командой, которую затем обработает TDLib и Receive, которая ждёт N-секунд и возвращает в виде ASCII-строки (!) JSON-объект с описанием события или данными после одного из запросов. За это у нас отвечает класс TDLibInterface, который объявляет PInvoke-методы для вызова нативных методов из библиотеки. .NET Core сам подгрузит библиотеку tdjson (причём на Linux он добавит ей префикс а-ля libtdjson.so, а на Windows загрузит tdjson.dll) и сам разберется с маршаллингом аргументов функций: например, string автоматически преобразует в const char*. Тем не менее, с const char* возвратами нужно быть аккуратнее — у меня был SIGSEGV, пока я ручками не конвертировал их в обычную строку.
З.Ы: На Пикабу нет отдельного тега для кода, а вставить листинги картинками я не могу из-за ограничения на 25 медиаэлементов. Так что листинги будут совсем без табов, но алгоритм их работы понять можно :)
[DllImport(Library, EntryPoint = "td_create_client_id", CallingConvention = CallingConvention.Cdecl)]
public static extern int CreateClientID();
[DllImport(Library, EntryPoint = "td_send", CallingConvention = CallingConvention.Cdecl)]
public static extern void Send(int id, string request);
[DllImport(Library, EntryPoint = "td_receive", CallingConvention = CallingConvention.Cdecl)]
private static extern IntPtr RawReceive(double timeOut);
[DllImport(Library, EntryPoint = "td_execute")]
public static extern StringBuilder Execute(string request);
public static unsafe string Receive(double timeOut)
{
IntPtr str = RawReceive(timeOut);
return str != IntPtr.Zero ? new string((sbyte*)str.ToPointer()) : null;
}
Позволю себе чуточку критики в сторону TDLib. Во первых, почему нет s-версии функции с возможностью указать длину входной строки, а tdjson полагается исключительно на \0 в конце строки? Во вторых, почему const char*, а не wchar_t*? Сейчас юникод во входной строке приходится escape'ами превращать в \u-последовательности.
После этого, нам нужно написать обёртку над TDLib, которая будет вызывать для зарегистрированных событий специальные функции, называемые коллбэками. При этом закомментированный WriteLine снизу — это «дебаг» для того, чтобы узнать названия неизвестных мне ивентов :)
В каждом объекте, полученном с помощью receive, есть поле "@type", которое содержит в себе имя класса возвращаемого объекта. Первый же вопрос от читателей — почему я использую JObject с ручным дерганьем нужных полей и вручную пишу JSON в виде строковых литералов вместо нормальной сериализации/десериализации? Ответ прост: во-первых, для актуализации Data-классов придется писать кодогенератор из TL-схемы, а во-вторых иногда TDLib может возвращать немного разные объекты в JSON, из-за чего приходится мудрить с атрибутами на этих самых Data-классах, иначе десериализатор выбросит исключение. Это решается нормальными юнит-тестами на всех вариантах данных, но зачем себе в колени стрелять, если нужен конкретный фиксированный функционал и лишь малое число от всех полей, возвращаемых TDLib?
string recv = NativeInterface.Receive(10.0d);
if (recv != null)
{
JObject json = JObject.Parse(recv);
string type = json["@type"].ToString();
if (!handlers.ContainsKey(type))
{
//Console.WriteLine("Unknown event type: {0}", type);
continue;
}
handlers[type](recv, json);
}
Теперь переходим к самому интересному — обработке событий и реализации синхронного клиента, который позволяет без async/await просто запросить список сообщений и сразу же его получить (такой подход может быть полезен и юзерботам, которые не хотят размазывать стейты по всей программе). Почему без асинков? Честно сказать, мне они просто не нравятся: как привык к концепции wait/notify и коллбэков из Java, так их и юзаю всю жизнь :)
Сначала TDLib запрашивает параметры инициализации (стейт authorizationStateWaitTdlibParameters), затем если пользователь не авторизован — запрашивает номер телефона и код подтверждения (плюс дополнительные шаги для авторизации если они есть). В конце, TDLib возвращает стейт Ready, что означает готовность библиотеки к работе:
private void OnAuthState(string raw, JObject obj)
{
JObject authState = (JObject)obj["authorization_state"];
string type = authState["@type"].ToString();
if (type == "authorizationStateWaitTdlibParameters")
{
Console.WriteLine("Preparing TDLib parameters...");
NativeInterface.Send(InstanceID,
Utils.Format("{" +
"\"@type\": \"setTdlibParameters\", " +
"\"database_directory\": \"tdlib\", " +
"\"api_id\": {0}, " +
"\"api_hash\": \"{1}\", " +
"\"use_chat_info_database\": true," +
"\"use_file_database\": true," +
"\"use_message_database\": true," +
"\"system_language_code\": \"en\", " +
"\"device_model\": \"Phone\", " +
"\"application_version\": \"1.0\" " +
"}", APIId, APIHash));
}
if (type == "authorizationStateWaitPhoneNumber")
{
Console.WriteLine("Sending phone number");
NativeInterface.Send(InstanceID, Utils.Format("{\"@type\": \"setAuthenticationPhoneNumber\", \"phone_number\": \"{0}\" }", PhoneNumber));
}
if(type == "authorizationStateWaitCode")
{
NativeInterface.Send(InstanceID, Utils.Format("{\"@type\": \"checkAuthenticationCode\", \"code\": \"{0}\" }", WaitCode));
}
if(type == "authorizationStateReady")
{
Console.WriteLine("Authorized");
waitHandle.Set();
}
}
...
Client.AttachEventHandler("updateAuthorizationState", OnAuthState);
После этого, можно начать работу с данными. Обратите внимание, мой подход потоко-небезопасен, его нельзя дергать из нескольких потоков одновременно! В коде ниже, я вызываю метод для фетча сообщений, а затем в соответствующем коллбэке от TDLib обрабатываю данные (дабы статья не разрасталась на 20+ минут, я чуть урезал все листинги).
public List<Message> QueryMessagesInChat(long chatId, long lastMessage, int count)
{
messages.Clear();
requestMessageCount = count;
string json = Utils.Format("{\"@type\": \"getChatHistory\", \"chat_id\": \"{0}\", \"from_message_id\": {1}, \"limit\": {2} }", chatId, lastMessage, count);
NativeInterface.Send(InstanceID, json);
waitHandle.WaitOne();
return messages;
}
public User QueryUser(long userId)
{
string json = Utils.Format("{\"@type\": \"getUser\", \"user_id\": \"{0}\" }", userId);
NativeInterface.Send(InstanceID, json);
waitHandle.WaitOne();
return user;
}
Переходим к реализации самого сервера, для наших целей хватит обычного HttpListener. Сначала мы зарегистрируем все поддерживаемые методы и занесем их в ассоциативный список ключ-значение. Сами методы реализованы в виде делегатов, которые принимают лишь один аргумент — список параметров из строки запроса, а возвращают строку — все ответы, за исключением особых (связанных с загрузкой вложений) — текстовые.
private HttpListener listener;
private List<HttpMethodHandler> methods;
private ScheduledRestart restartManager;
private void AddMethod(HttpMethodHandler info)
{
if(info != null)
{
methods.Add(info);
Console.WriteLine("Registered method: {0}", info.Method.Name);
}
}
private void PrepareMethods()
{
AddMethod(Chats.QueryChats);
AddMethod(Chats.QueryMessages);
AddMethod(Chats.SendMessage);
AddMethod(Users.QueryUserInfo);
}
private void PrepareState()
{
// We should fetch dialog list due to TDLib nature of preloading-everything
Client.QueryChats(15);
}
public HttpServer()
{
listener = new HttpListener();
listener.Prefixes.Add("http://+:13377/");
Client = new SyncClient("test");
Client.Start();
Client.WaitUntilReady();
//restartManager = new ScheduledRestart(5);
//restartManager.Start();
methods = new List<HttpMethodHandler>();
PrepareMethods();
PrepareState();
}
...
public void Start()
{
listener.Start();
while(listener.IsListening)
{
HandleRequest(listener.GetContext());
}
}
Переходим к обработке запроса. Метод ищет, зарегистрирован ли запрошенный метод и если да, то парсит строку запроса, которая начинается с "?", которую затем передаёт в виде коллекции ключ->значения обработчику метода:
private void HandleRequest(HttpListenerContext ctx)
{
string method = ctx.Request.Url.LocalPath.Substring(1).ToLower();
if (method.Length < 0)
{
SendResponse(HttpGenericResponse.MethodRequired.ToString(), ctx);
return;
}
foreach(HttpMethodHandler handler in methods)
{
if(method == handler.Method.Name.ToLower())
{
string result = "";
if (ctx.Request.Url.Query.Length > 0)
{
string[] args = ctx.Request.Url.Query.Substring(1).Split('&', StringSplitOptions.RemoveEmptyEntries);
Dictionary<string, string> keyValuePairs = new Dictionary<string, string>();
foreach (string arg in args)
{
if (arg.IndexOf('=') >= 0)
keyValuePairs.Add(arg.Substring(0, arg.IndexOf('=')), arg.Substring(arg.IndexOf('=') + 1));
else
keyValuePairs.Add(arg.Substring(0, arg.IndexOf('=')), "");
}
result = handler(keyValuePairs);
if (result == null || result.Length < 1)
{
Console.WriteLine("Suspicious result from {0}", handler.Method.Name);
}
}
SendResponse(result, ctx);
return;
}
}
SendResponse(HttpGenericResponse.UnknownMethod.ToString(), ctx);
}
А сами методы, в свою очередь, дергают соответствующие функции из клиента и формируют на их основе датасет в примитивном формате:
public static string QueryChats(Dictionary<string, string> args)
{
if(args.ContainsKey("count"))
{
int count = int.Parse(args["count"]);
StringBuilder ret = new StringBuilder();
List<Chat> chats = HttpServer.Instance.Client.QueryChats(count);
ret.AppendLine(string.Format("Count={0}", chats.Count));
foreach(Chat chat in chats)
{
ret.AppendLine("Begin");
ret.AppendLine("ID=" + chat.ID);
ret.AppendLine("Date=" + chat.LastMessageDate);
ret.AppendLine("Name=" + chat.Name);
ret.AppendLine("Text=" + Uri.EscapeDataString(chat.LastMessageText));
ret.AppendLine("MsgId=" + chat.LastMessageID);
ret.AppendLine("End");
}
return ret.ToString();
}
return HttpGenericResponse.InternalException.ToString();
}
В результате получаем вот такой простой датасет, который, как я и говорил, легко распарсить и на Siemens C60, и на Atmega328 — да где угодно! В целом, такой сервер можно использовать для реализации бота в телеграме, который будет передавать показания каких-то датчиков, сигнализацию и прочие клевые штуки!
Переходим к реализации клиента, т.е. приложения на Android. Здесь будет не менее интересно!
❯ Пилим для Android
В геймдеве есть своеобразный мем — некоторые инди-разработчики сначала начинают делать меню, вместо основного геймплея, что становится предметом насмешек среди других разработчиков. Но в разработке приложений для смартфонов всё по другому — здесь как-раз таки хорошо заранее продумывать макет будущего приложения!
Поскольку у нас с вами мессенджер, то главный экран должен представлять из себя список чатов (ListView) и верхнюю панельку, где в будущем могут разместиться настройки и свайп-менюшка:
Такой вот простой макет.
Каждый пункт меню — это тоже отдельный layout, в котором мы по шаблону строим внешний вид будущего элемента списка. На немолодых устройствах есть смысл использовать как можно меньше контейнеров в layout'е, поскольку пересчет позиций и размеров элементов — одна из самых «тяжелых» операций в UI-фреймворке вообще. Кроме того, не стоит использовать кучу картинок и drawable — в Android 2.x всё 2D рисуется софтварно, аппаратное ускорение появилось только в 3.0 (частично).
Но дабы в списке диалогов что-то появилось, нужно сначала реализовать фетчинг (получение) этих самых диалогов с сервера! Сам объект, который занимается обработкой запросов называется ClientManager и является синглтоном — он в единственном экземпляре на все время работы программы. Помимо менеджмента «ноды» (т.е. прокси-сервера), токена для авторизации и обработчика ошибок, ClientManager реализует метод для асинхронного запроса информации с сервера и, собственно, формирует строки запросов с помощью соответствующих методов:
public void queryChats(int count, Response resp) {
sendRequest(String.format("%s/QueryChats?count=%d&auth_key=%s", nodeAddress, count, token), resp);
}
Подгрузка чатов и сообщений реализована через Adapter — концепция «виртуальных» списков, которая предполагает что система создаст не 50 элементов интерфейса на каждую кнопку чата, а только 5 и будет их виртуально «мотать по кругу», обновляя только данные в уже существующих элементах. Это позволяет значительно ускорить отрисовку, учитывая то, что Android 2.x Canvas рисуется программно.
private void updateDialogList() {
ClientManager.getCurrent().queryChats(50, new ClientManager.Response() {
@override
public void onReady(String str) {
try {
List<Packets.Chat> chats = Packets.parseChatListFromQueryResponse(str);
DialogAdapter adapter = new DialogAdapter();
adapter.setChats(chats);
((ListView) findViewById(R.id.messages_view)).setAdapter(adapter);
} catch (Exception e) {
Toast.makeText(MainActivity.this, "Упс!", Toast.LENGTH_SHORT);
}
}
});
}
Ну вы уже явно замучились видеть простыни кода, давайте посмотрим что у нас вышло!
Шустренько, да? А ведь это ультрабюджетник Alcatel OT-916D, один из последних массовых дешевых QWERTY-смартфонов за 5 000 рублей из 2012 года. Кстати, смартфон подарил мне читатель chuvakoff с Хабра!
Переходим к окну чата. Основной макет почти такой-же, как и у основного окна: только добавилась панелька для ввода сообщения снизу.
Концептуально, всё тоже самое — запрашиваем данные с сервера, парсим их и загружаем в адаптер, благодаря чему мы сможем листать наш диалог. Однако в сообщения я добавил контекстное меню с стандартными фишками типа копирования, ответа и прочих подобных действий. Поскольку у нас нет ни пушей, ни еще каких-либо средств для поулчения данных о новых сообщениях, я раз в определенный интервал просто получаю сообщения — и если новый датасет отличается от старого — обновляю окошко чата.
view.setOnCreateContextMenuListener(new View.OnCreateContextMenuListener() {
@Override
public void onCreateContextMenu(ContextMenu contextMenu, View view, ContextMenu.ContextMenuInfo contextMenuInfo) {
// Reply to...
contextMenu.add(getString(R.string.reply)).setOnMenuItemClickListener(new MenuItem.OnMenuItemClickListener() {
@Override
public boolean onMenuItemClick(MenuItem menuItem) {
setReplyContext((Packets.Message) view.getTag());
return true;
}
});
// Copy
contextMenu.add(getString(R.string.copy)).setOnMenuItemClickListener(new MenuItem.OnMenuItemClickListener() {
@Override
public boolean onMenuItemClick(MenuItem menuItem) {
ViewGroup vg = (ViewGroup)view;
android.text.ClipboardManager manager = (android.text.ClipboardManager) view.getContext().getSystemService(CLIPBOARD_SERVICE);
manager.setText(((TextView)vg.findViewById(R.id.message_content)).getText());
return true;
}
});
// Send to...
contextMenu.add(getString(R.string.resend)).setOnMenuItemClickListener(new MenuItem.OnMenuItemClickListener() {
@Override
public boolean onMenuItemClick(MenuItem menuItem) {
ViewGroup vg = (ViewGroup)view;
String text = ((TextView)vg.findViewById(R.id.message_content)).getText().toString();
Intent intent = new Intent();
intent.setAction(Intent.ACTION_SEND);
intent.putExtra(Intent.EXTRA_TEXT, text);
intent.setType("text/plain");
startActivity(Intent.createChooser(intent, null));
return true;
}
});
}
});
Переходим к реализации поля для ввода сообщения. Здесь всё просто — на серверсайде за это отвечает метод SendMessage. Однако для того, чтобы с нашего клиента можно было ответить на другие сообщения, я ввёл также «контекст ответа», в котором запоминается сообщение, на которое мы хотим ответить. Telegram также поддерживает Markdown, однако его полная поддержка пока не реализована.
EditText editText = ((EditText)findViewById(R.id.message_text));
if(editText.getText().length() > 0) {
long replyTo = replyContext != null ? replyContext.ID : 0;
ClientManager.getCurrent().sendTextMessage(chat.ID, editText.getText().toString(), replyTo, new ClientManager.Response() {
@Override
public void onReady(String str) {
}
});
editText.setText("");
setReplyContext(null);
}
В остальном же, функционал конечно пока совсем базовый, однако клиент работает очень шустро даже бюджетной X10 Mini Pro и позволяет чатится с моими читателями в Telegram. В будущем хотелось бы допилить:
Поддержка картинок: Сейчас уже есть кривоватый механизм кэширования изображений на стороне сервера, который позволяет загружать аватарки чатов. В будущем, я добавлю поддержку «галерей» с картинками!
Поддержка голосовых сообщений: Не все их любят, но они порой удобны и выручают. Реализую как прослушивание, так и запись!
Подробный просмотр профилей и менеджмент чатов: Удаление сообщений, чатов и прочие фишечки из официальных клиентов.
Казалось бы — до официальных клиентов ещё очень далеко. Но сам факт, чтобы всё это работало достаточно шустро на девайсах, которым уже более 10 лет!
❯ Звучит интересно! Как заюзать твой клиент?
Тут всё очень и очень просто! В первую очередь, нам понадобится ПК с белым IP, роутер (если под него есть сборка dotnet), либо VDS. Виртуальные сервера сейчас стоят копейки, у ТаймВеба есть тариф за 188 рублей в месяц, которого с головой хватит для нашего сервера.
Такая вот рекламная интеграция (к слову, прокси для всех приложений уже более года крутятся именно на мощностях TimeWeb Cloud)!
Берём уже собранный TDLib и сервер под Windows, или собираем TDLib под Linux, накатываем .NET Core. Пример для Debian/Ubuntu:
sudo apt-get install dotnet
Затем запускаем сервер:
dotnet tdsrv.dll
Программа сначала запросит номер телефона, а затем код подтверждения Telegram. После этого будет создана папка tdlib/, где будут хранится данные вашей сессии, а также файл authkey.txt, где хранится случайный ключ для сессии (md5 phone_number + response code + псевдослучайное число). Не оставляйте его в /var/www/!
Если всё нормально, программа начнёт слушать порт 13377 на всех сетевых интерфейсах, в т.ч и в локальной сети. После этого, ставим уже предварительно собранный, либо собираем сами в Android Studio APK и в окне авторизации пишем адрес ноды и ключ авторизации. Если всё настроено верно — программа запомнит сервер и будет работать без проблем! Вот так всё легко :) Как видите — всё очень и очень просто!
Кроме того, буквально за пару дней до публикации статьи я сел вечерком из интереса что-нить под Java-телефоны попилить… и, как и обещал, реализовал Proof of Concept возможности работы Telegram даже на сонериках, которым скоро 20 лет стукнет! А ведь если ещё чуть заморочится, можно запустить приложение даже на преусловутых монохромных сименсах!
❯ Заключение
Вот такой у нас получился проект с реализацией лёгкого, примитивного, но тем не менее рабочего клиента Telegram, который на клиентской части вообще не использует никаких зависимостей. Вес собранного APK в release-версии — всего 54 килобайта! Понятное дело что с ростом функционала, вес программы будет увеличиваться, но я обещаю — больше 1Мб он не вырастет :)
Ну а вам, моим читателям, надеюсь было интересно прочитать такой «двойной материал» не только о разработке сетевой части без использования Apache/nginx/IIS, но и UI-фронтэнда для Android-смартфонов, которым уже более 10 лет!
Исходный код проекта можно найти на моём GitHub: как приложения, так и сервера, а также убедиться в отсутствии каких либо закладок и, если совсем не доверяете, собрать бинарники сами! Для сборки понадобится VS2017 или свежее, а также Android Studio 2.3.2 (если собираете для Android 2.1 и ниже).
Друзья! Сейчас на Хабре опросы сломаны, поэтому если у вас есть желание, вы можете проголосовать в комментариях: какой стиль статей вам больше нравится — где больше конкретики и кода с пояснением как конкретно работает та или иная часть программы, или наоборот стиль ближе к научпопу, где фрагментов кода нет, или их значительно меньше? Пишите своё мнение о проекте в комментариях!
Кроме того, у меня есть канал в Telegram, куда я публикую бэкстейдж статей, ссылки на новый материал, свои наработки, а также посты о ремонте девайсов и различные мысли.
Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи каждую неделю!
Сможете найти на картинке цифру среди букв?
Справились? Тогда попробуйте пройти нашу новую игру на внимательность. Приз — награда в профиль на Пикабу: https://pikabu.ru/link/-oD8sjtmAi
НЕЙРОПСИХИАТР : ЗАВИСИМОСТЬ ОТ ГАДЖЕТОВ РАЗРУШАЕТ НЕЙРОННЫЕ СВЯЗИ
Зависимость от информации, потребляемой через интернет, негативно влияет на интеллектуальную продуктивность, нарушая нейронные связи.
В исследованиях показано изменение мозгового субстрата, в частности – снижение количества нейронных связей на 10-20% у зависимых от гаджетов людей. Зависимость порождает безконтрольное потребление информации, а потребление в свою очередь подкрепляет зависимость. В основе такого поведения работает дофаминовый механизм, то есть точно такой же, как в случае зависимости от психоактивных веществ. Проще говоря, наш мозг стимулируется и получает удовольствие от поступления различной легкой информации – пролистывания новостной ленты в социальной сети или просмотра коротких видео.
Прежде всего, опасность кроется в безконтрольном потреблении информации.
В процессе этой деятельности, как правило, изменяется ощущение времени – казалось, заглянул на пять минут, а уже прошел час... По данным агентств, исследующих сферу потребления интернета в разных странах, время, проведенное россиянами в сети в сутки, составляет семь часов 17 минут, из которых 2,5 часа уходит на соцсети. Это данные от января 2020 года. Все это приводит в итоге к довольно печальным последствиям – наши гаджеты снижают интеллектуальную продуктивность, поскольку являются сами по себе фактором многозадачности, заставляя постоянно переключать на себя внимание, когда нужно сосредоточиться на решении какой-то задачи. Мозг человека может работать в режиме решения одной задачи. Когда возникает необходимость переключаться – эффективность падает, тратится много энергии и быстрее наступает утомление.
На информационную зависимость могут указывать следующие поведенческие факторы: безцельное посещение страниц в интернете, пренебрежение делами и сном в угоду потреблению информации, утрата контроля проведенного в сети времени, ощущение скуки без гаджета и предвкушение его использования.
Ограничить использование гаджетов необходимо в первую очередь тем, у кого выявляются симптомы зависимости. Помимо этого тем, у кого уже имеются соматические проблемы, такие как заболевания позвоночника, нарушение зрения, кто склонен к малоподвижному образу жизни или имеет психические заболевания, страдает нарушением сна, да и в целом всем тем, кто дорожит своим телесным-физическим, психическим, психо-эмоциональным, мозговым-ментальным здоровьем – и хочет как можно дольше сохранять свою разумность и трудоспособность.
Чтобы избежать развития зависимости от гаджетов и безконтрольного потребления информации, необходимо соблюдать цифровую гигиену.
В целом правильнее было бы освоить навыки цифровой гигиены. Для этого необходимо прийти к осознанному использованию гаджетов. Каждый раз задавая себе вопрос о цели обращения к гаджету и насколько она важна. Для развлекательной активности желательно выделить определенное время и отключить по возможности все уведомления, особенно звуковые, и очень желательно в домашней обстановке оставить телефон на зарядке и забыть о нем, а также не использовать телефон рано утром и за два часа до сна.
( С )
ВИДЕО МОЖНО ПОКАЗАТЬ РЕБЁНКУ – ТАМ ПРОСТЫМИ СЛОВАМИ ОБ ЭТОМ – И ОЧЕНЬ НАГЛЯДНО-ОБРАЗНО ВСЁ ПОКАЗАНО .
ПРОДОЛЖЕНИЕ И РАСКРЫТИЕ ТЕМЫ : « ЦИФРОВОЙ ГЕРОИН » : КАК ГАД-ЖЕ-ТЫ ВЛИЯЮТ НА МОЗГ
Микросмартфон за 100 рублей: Покупаем смартфон 11-летней давности и… пишем под него приложения
Размер экрана — краеугольный камень мира современных смартфонов. Кто-то считает, что дисплеи должны становиться только больше, а рамки — меньше, кто-то любит «средние» дисплеи диагональю в 5+", ну а кто-то остаётся ярым поклонником и приверженцем компактных смартфонов с крошечными дисплейчиками. В наше время, купить новый смартфон с относительно небольшим дисплеем за приемлемые деньги почти нереально — самые бюджетные модели будут слишком тормозными для современного пользователя. Некоторое время назад, я купил себе бюджетный крошечный смартфон 2012 года выпуска — Samsung Galaxy Pocket, причём всего за 100 рублей. Конечно же мне захотелось довести его до ума — а доводить пришлось руками и навыками прожженного программера! Какой смартфон можно получить за 100 рублей? Читаем в статье!
Минутка предыстории
С самого появления смартфонов на рынке, весь мир шагал к тотальному увеличению дисплеев и уменьшению рамок. В какой-то момент, большие смартфоны даже получили отдельное название — падфоны или смартпэды. Такой ход событий было не трудно предугадать: ведь производители дисплейных матриц осваивали всё более и более высокие разрешения и предлагали больше вариантов производителям смартфонов.
Однако несмотря на всеобщее засилие больших «лопат», в мире всё ещё оставались поклонники маленьких и компактных телефонов, которыми очень удобно пользоваться одной рукой. Сейчас подобные устройства представляют только небольшие бренды, известные достаточно в узких кругах — в основном, их можно купить на маркетплейсах, в обычных салонах связи их не найти. Мне известно о нескольких подобных устройствах, которые сейчас присутствуют на рынке. Первый из них «закос» под iPhone — Soyes XS11:
Но тут уж, если честно, хочется назвать такой смартфон не просто компактным, а совсем малюсеньким. На нём вполне удобно выполнять задачи звонилки, но совсем неудобно набирать текст — поэтому под наши задачи, он не особо подходит. Кроме того, эти девайсы работают на базе бюджетного смартфонного железа 6-7 летней давности, поэтому их производительность будет достаточно невысокой по меркам современного пользователя. Конечно же есть и более серьёзные варианты — например, компания Unihertz (да, тот самый продолжатель идей BlackBerry) делает смартфоны Jelly 2: дисплей с диагональю 3", Helio P61 под капотом и Android 11 на борту. Вот только цена, мягко говоря, кусачая — 18 тысяч рублей на момент написания статьи. Это слишком дорого!
Но если душа прямо таки лежит к компактным смартфонам, почему бы не обратиться к рынку Б/У устройств и не присмотреть что-то из… прошлого десятилетия? А вариантов ведь реально много — тут и LG Optimus L3 (3.2"), и Samsung Galaxy Pocket Neo (2.8"), Samsung Galaxy Star (3"), Samsung Galaxy Fame (3.5"), Samsung Galaxy Young. Все перечисленные девайсы стоят реально копейки — можно купить живой вариант до 400-500 рублей!
Я решил взять себе целых два смартфона: Samsung Galaxy Mini и Samsung Galaxy Pocket первого поколения. Оба достались мне в одном лоте за 2.000 рублей (с 20 телефонами) и обошлись мне по сто рублей, причём оба смартфона были рабочими! Чуть позже я докупил отдельно Galaxy Star (250 рублей), Galaxy Fame (250 рублей) и Galaxy Pocket Neo (~400 рублей) для полноты коллекции — вышло совсем недорого. Итак, что за характеристики мы получаем в смартфоне за 100 рублей:
Android: 2.3 Gingerbread.
Чипсет: Broadcom BCM21553 с одним ядром Cortex-A5 на частоте 832мгц. Видеочип: VideoCore IV, он же использовался в Raspberry Pi.
ОЗУ: 256 мегабайт (предположительно — DDR1).
Встроенная память: 3 гигабайта + слот для SD.
Дисплей: 2.8", 240x320, емкостной тачскрин.
Сеть: Поддержка 2G/3G. Об LTE и речи не идёт.
Выглядит не особо густо, да? И разрешение весьма низкое — большинство софта не запустится, а о клиентах современных сервисов и мечтать не приходится… или приходится?
Конечно же шаловливым ручкам захотелось вернуть жизнь этому миниатюрному красавцу и я решил использовать его как второй смартфон — при этом с клиентом ВК и музыкой, которые я запилил сам.
Разработка под старые версии Android
На самом деле, разработка под старые версии Android не особо отличается от современных версий системы. Кое-где приходится костылить, велосипедить и юзать AppCompat для реализации современных фишек на старых версий системы, но, будем честным, подобного и в последних версиях Android достаточно.
Даже сейчас нет никакой проблемы скачать последнюю версию Android Studio, подключить смартфон с включенной отладкой и отлаживать приложение прямо на девайсе — logcat тоже есть. Единственный нюанс — поиск драйверов и ручное закрытие приложений в таскменеджере, если вы деплоите под Android 2.x (Android Studio не умеет сам закрывать приложение, чтобы переустановить пакет).
В целом, за всё время разработки под старые устройства, я пришёл к следующим выводам:
Поскольку большинство устройств имеет одно ядро, для плавности интерфейса нужно минимизировать любую работу в фоне.
Взаимодействие с современными веб-сервисами может быть осложнено из-за отсутствия поддержки TLS1.2 и устаревших сертификатов (проверка сертификатов легко обходится специальным костылем, а вот TLS — нет).
У Android до 3.0 вся отрисовка интерфейса программная и она опять же, будет сказываться на скорости работы фоновых служб. Чем менее интерфейс комплексный, тем лучше.
Пушей нет — да, вообще. Однако это ничуть не помешает нам сделать уведомления практически в реальном времени с помощью… очередного костыля!
Допиливаем ВК
Я уже писал клиент ВК в рамках одной из прошлых статей. Теперь нам нужно довести его до ума — подогнать под разрешение экрана и переработать интерфейс для большей удобности, а также добавить недостающие разделы — я тот ещё любитель полистать мемчики, сидя в автобусе.
Честно сказать, вся концепция интерфейса требовала полной переработки — боковое меню банально очень неудобно использовать на подобных устройствах из-за малых размеров каждой строчки. Поэтому я решил не изобретать велосипед, а обратился к дизайнерам Apple и первоисточнику: официальному клиенту ВК для iOS 6, родом из 2012 года!
Приложение для Android выглядело +- также в те годы. Видите вкладки с разделами снизу? Они то нам и нужны — это самый удобный способ навигации на таких смартфонах! Накидав макет в layout'е, я приступил к реализации:
Изначально мне хотелось, чтобы всё приложение было плавным и анимированным: для этого я обратился к фреймворку анимаций Android. Суть очень простая — это обычный интерполятор значений от a до b за определенный промежуток времени. При этом мы не можем анимировать произвольное свойство — только те, который уже реализованы в системе (переход, поворот, масштабирование, альфа-канал). Более наглядно это можно представить вот так:
Да, это всё анимация :) Получаем примерно такой результат:
Обратите внимание, что запуск большого количества анимаций будет вызывать перерисовку даже в том случае, если элемент не видно на экране — от чего у нас будут дикие тормоза! Осторожнее с этим.
После этого, я решил доработать раздел с музыкой: я все еще пользуюсь грязными хаками для получения доступа к API музыки, поскольку «левым» клиентам такой возможности не дают. Публично его расписывать не буду, поскольку это скорее всего нелегально, да и сами ребята из ВК об этом знают (но не думаю, что будут применять какие-то санкции по отношению к «маленьким» разработчикам) — но если нужно, пишите в личку, расскажу всю концепцию.
Во первых, мне хотелось добавить возможность скачивать треки на внутреннюю память/флэшку. А во вторых, мне хотелось добавить фоновое воспроизведение — до этого возможность свернуть приложение и послушать музыку уже была, однако Android мог в любой момент прибить окно с музыкой и оставить нас с носом, остаётся только реализация в виде foreground-сервиса:
В Android есть два типа служб: background (фоновые) и foreground (видимые пользователю). Первый тип служб система может прибить когда угодно — например мало памяти или экономия заряда АКБ. А вот второй тип служб система не прибивает практически никогда, поскольку они обозначают выполнение важной операции в фоне — например скачивание файла или обновление системы. Однако у них есть одно ограничение — они должны быть привязаны к собственному уведомлению, которое нельзя закрыть. В процессе реализации возникло еще пару проблем — Wakelock'и (механизм, предотвращающий уход девайса в «сон») и WiFiLock'и (тоже самое, но для WiFi).
Точно таким же способом я реализовал механизм уведомлений — как я уже говорил раньше, пушей на старых смартфонах нет вообще ни в каком виде, поэтому пришлось реализовывать свой механизм «обновления»: каждые 3-5 секунд запрашиваем список последних 5 диалогов с сервера и сравниваем с предыдущим результатом, если есть новые сообщения — создаём нотификацию (листинг слишком длинный - пришлось перезалить на pastebin):
После этого, я начал рутинную работу по реализации интерфейса для данных с сервера — паблики, друзья, профили, лента и.т.п. В некотором смысле, реализация лента весьма занимательна: вообще, для очень больших списков существуют т.н виртуализация ListView — это когда ListView отображает только видимый пользователю кусок датасета (набора данных — например, список записей на стене) и на старых версиях Android она доступна. Однако мне было интересно реализовать вариант, который потреблял бы минимальное количество ОЗУ и где я точно знал бы, когда пользователь видит тот или иной фрагмент приложения. Поэтому я реализовал… пагинацию свайпами! Вот так привет из нулевых!
Для этого я использовал GestureDetector — встроенный в систему класс для обнаружения простых жестов — свайпов и.т.п. ВК при запросе ленты отдаёт специальную метку для получения следующей страницы новостей (поскольку она может динамически меняться и нужно хранить её стейт), мы эти метки просто сохраняем и переключаемся по странницам новостей с помощью обычных свайпов вправо-влево:
Выглядит весьма забавно.
Юзабельно ли всё это на деле?
Давайте смотреть, может ли юзать такой смартфон в наши дни. Берём наш девайс в руки, логинимся и оцениваем его производительность «вхолостую».
Работает весьма шустренько, учитывая что это бюджетник 2012 года. Как насчет нашего самопального клиента ВК? Смотрим:
Работает весьма бодро. Не сказать что также плавно, как последний айфон, но и совсем плохим результат явно не назвать!
Смартфонный функционал у девайса тоже вполне ничего: 1-2 SIM (в зависимости от версии), нормальная синхронизация контактов с ПК (однако Kies вроде-бы не работает на Windows 10, но есть vcf):
Встроенный почтовый клиент продолжает работать без каких либо проблем. Однако настраивать некоторые почтовые сервисы нужно вручную и с помощью «паролей приложений» — напрямую залогинится возможности нет. В случае «покета», придется поставить стоковый клиент из Android 2.3 вручную.
Мультимедийные возможности тоже радуют: встроенный плеер тачвиза мне всегда очень нравился. Есть и настройки эквалайзера.
Единственное, что откровенно подводит — браузер. Последним вариантом осталась Opera Mini 7 — она позволяет смотреть сайты, но не поддерживает динамический контент, только статику. Ну, зайти на википедию или почитать статью на Хабре хватит. Родной браузер уже не в состоянии что либо загрузить :(
Ну а в общем, производителньость смартфона весьма радует, согласитесь? Нельзя сказать, что он уж слишком тормозной — по крайней мере, современные ультрабюджетные смартфоны (до 4-5 тысяч рублей) зачастую показывают себя гораздо хуже чем и флагманы прошлых лет, и даже бюджетники!
Заключение
И всё таки, я считаю что мне удалось в каком-то смысле вдохнуть новую жизнь в старенький девайс. Если использовать подобный девайс как второй — на случай, если сел основной смартфон, то такой миниатюрный красаввчик может неождианно выручить даже в довольно сложной ситуации. Кроме того, эти смартфоны всеядны к аккумуляторам — достаточно подпаять + и — и они будут работать хоть от BL-4C.
Главная ценность Galaxy Pocket — в его компактных размерах. А поскольку по настоящему дешевых, маленьких и шустрых смартфонов становится всё меньше и меньше, то нам остаётся лишь продлять жизнь моделям прошлых лет! Есть ли в этом смысл и получил ли смартфон новую жизнь? Пишите в комментариях!
Клиент ВК можно сказать на 4pda. Там лежит самая последняя версия (для скачивания нужна регистрация на форуме). Если по каким-то причинам не хотите регистрироваться на форуме — я выложил актуальную версию в комментариях.
Эта статья поддерживается командой ITGLOBAL.COM
Мы — первый облачный провайдер в России, а также интегратор, поставщик ИТ-услуг, продуктов, сервисов и разработчик собственного ПО.
• Наш сайт
• Наш блог про виртуализацию и Enterprise IT
• Истории успеха наших клиентов
Ответ на пост «Не дадим Windows Phone умереть! Как я написал свои клиенты VK, YouTube для Nokia Lumia? Сам себе экосистема ч.2»
Это все конечно здорово, энтузиазм дело хорошее.
Может с точки зрения разработчика эта система супер-пупер крутая.
Но с точки зрения пользователя - это редкостное говнище. Хуже только, наверное, виста на пк (в целом под нее и подгонялось).
Судя по интерфейсу и дизайну - система делалась как раз для разработчиков, мол как у нас классно, можно вот это написать, это запрограммировать, это сделать». Но для обычных пользователей это все нахер не надо. Человек хочет достать телефон из кармана, позвонить, отправить пару сообщений, посмотреть видосики и всё. И он хочет, что бы его глазам это было приятно. Виндафон этого не давал даже на 1%. В нем было хреново абсолютно всё от интерфейса до реализации структуры.
Это раз.
Второе:
А вы посмотрите на свой Android-смартфон сейчас. Сколько в нём ОЗУ? 4гб? 8гб? 12гб? Смущает ли вас то, что Android умудряется неприятно подтормаживать даже с такими ресурсами? А теперь вспомните Lumia 520: Snapdragon 200, 512 мегабайт оперативной памяти. Вот так она работает из коробки.
С точки зрения разработчика это полнейшая чушь и ложь. И либо ты не понимаешь как работают системы, либо пытаешься обмануть нас. С каждым годом приложения становятся сложнее и им требуется больше ресурсов. Да может где то это не оптимально. Да, может что то можно было бы лучше. Но общая тенденция это увеличение ресурсопотребления приложений из-за улучшения графики, увеличения вычислительных процессов, усложнения логики приложений.
И это все равно что сравнивать первую денди и PS5. На ПСке сколько оперативки? 32? 64? 128? И все равно некоторые игры тормозят. А вот на денди Марио не тормозил! Ну это же полнейшая чушь.
Это же фактический обман.
Плюс сама по себе система wp это максимально сырое тесто. Хочешь хорошо - бери напильник.
А людям надо что бы ты достал из коробки и сразу стало хорошо.
Вот простое объяснение того, что это система говно и к нее нет и никогда не было будущего.
Друг, это мертвая система которая никогда не будет воскрешена. Она убогая и неприятная (имхо).
И яблоки снискали такую популярность всего лишь по одной причине - они дали людям то, что им нужно - красоту и простоту. К счастью они нашли ровно тот ключик который был нужен.
А все вот эти архаизмы типа wp давно уже умерли и никогда не воскреснут.
А ты сейчас занимаешься некрофилией. Без обид, но по фактам.
Не дадим Windows Phone умереть! Как я написал свои клиенты VK, YouTube для Nokia Lumia? Сам себе экосистема ч.2
Windows Phone… услышав название этой мобильной системы, поневоле начинаешь с теплотой вспоминать своего недавнего, такого необычного мобильного друга, как будто прошло всего пару месяцев с момента смены смартфона на iPhone/Android. А ведь с момента фактической смерти Windows Phone прошло уже почти 10 лет! Увы, время вспять уже не повернуть, а мобильное подразделение Nokia не спасти, однако при наличии навыков разработки мобильных приложений, большом энтузиазме и фанатизме, есть шанс вернуть жизнь своему старому другу! Недавно я снова загорелся диким энтузиазмом и смог вернуть жизнь старенькой «люмии», написав собственные клиенты нужных мне сервисов с нуля — и готов поделиться этим с вами во всех подробностях!
Сегодня вы узнаете о моей мотивации привносить жизнь старым смартфонам, о тонкостях разработки мобильных приложений, чем Windiows Phone был на голову выше Android в техническом плане и о том, почему провал Windows Phone — одна из самых больших потерь мобильного рынка. Интересно? Тогда добро пожаловать в статью!
❯ Предыстория
Пожалуй, довольно большой процент моих читателей и подписчиков когда-либо владел и пользовался смартфонами на Windows Phone. Мнение пользователей этой мобильной платформы во многом разнится — кто-то восхваляет по настоящему продуманный и плавный интерфейс, кто-то ругает Microsoft за «кидалово» с обновлениями, но большинство людей сходится во мнении, что Windows Phone — была действительно необычной и имела собственную изюминку.
Конечно же, Windows Phone была далеко не первым опытом Microsoft на мобильном рынке. До этого, Редмондская компания поддерживала очень крутую платформу для коммуникаторов и КПК под названием Windows Mobile. Фактически, это был полноценный компьютер в кармане — большинство кнопочных телефонов могли максимум запускать простенькие J2ME-приложения, в то время как WM позволял запускать множество самых разных программ — как написанных на C++/Pascal, так и написанных на C#/VB.Net. Мобильная платформа во всём пыталась подражать своему старшему брату — API системы было очень похоже на то, что мы видим в обычной Windows — тут и полноценная оконная система, и waveout для вывода звука, и GDI для вывода графики.
Windows Mobile прочно занимал свою нишу на мобильном рынке: HTC постоянно представляла новые модели коммуникаторов, которые довольно хорошо продавались. Но тут пришёл первый iPhone, который перевернул всё с ног на голову. Оказывается смартфоном можно управлять полностью пальцами, нажимая на красивые, анимированные элементы интерфейса! Это перевернуло всю индустрию — даже Nokia с её Symbian было тяжело конкурировать с продуктом от Apple. Microsoft видела, что пользователи хотят не столько свободы и кастомизации в системе, сколько плавности интерфейса, стабильности и простоты использования.
Плеер Zune HD стал дебютом свежего подхода к созданию интерфейсов — Metro UI. И хотя сам девайс не сыскал особой популярности, став в некоторой степени провальным, Microsoft взяла на вооружение концепцию этого интерфейса, дабы реализовать её уже в полноценной мобильной ОС. В октябре 2010 года выходит первая версия новой мобильной платформы Microsoft — Windows Phone 7, заложившая фундамент той самой системы, которую мы с вами до сих пор вспоминаем с теплотой!
На WP7 вышло весьма много устройств: тут и девайсы от HTC, и смартфоны Lumia от Nokia, и даже продолжение линейки Omnia от Samsung! Но были у этой платформы и серьезные минусы: она базировалась на ядре обычной Windows CE (оно же использовалось в Windows Mobile) и из-за желания повысить безопасность системы, Microsoft отключила возможность использовать код на нативных языках в своих приложениях. Кроме того, во многих аспектах WP7 была достаточно сырая — хотя для неё регулярно выходили обновления.
❯ Почему провал WP — трагедия для мобильного рынка?
Конечно же параллельно с доработкой WP7, Microsoft разрабатывала новую версию ОС, которая должна была объединить мобильные и десктопные приложения в одну общую концепцию. Кроме того, разработчики решили отказаться от лёгкого ядра Windows CE в пользу более тяжелого и продвинутого ядра Windows NT, которое используется в полноценных версиях Windows.
К сожалению, апгрейда с WP7 на WP8 предусмотрено не было, что многие пользователи считают «кидаловом» со стороны Microsoft. Отчасти это так, но проблема была в том, что даже флагманские устройства на WP7 имели 512мб ОЗУ, чего было недостаточно для первой версии WP8. Думаю, в какой-то степени Microsoft просто не хотели портить имидж максимально плавных смартфонов тормозами обновленной системы, хотя примеры шустрой работы на 512мб ОЗУ есть — например, Lumia 520.
Но вот где WP8 была передовой, так это «под капотом». Microsoft смогли сделать что-то невообразимое для мира ARM-устройств: они реализовали нормальный слой абстракции от «железа» и ввели концепцию ACPI, знакомую нам из обычных десктопных ПК. Вкратце, ACPI — это что-то типа списка железа в устройстве, под которое ОС должна найти и загрузить драйверы, не забыв под это всё выделить ресурсы (devicetree в Linux реализует похожую концепцию). Кроме того, Microsoft реализовала полноценный UEFI в своих смартфонах, что позволяло, например, сделать дуалбут в будущем. На практике это всё означает то, что даже неподдерживаемые No-Name смартфоны можно было обновить до Windows 10, банально поменяв пару ключей в реестре: на Android-устройствах такое невообразимо. Фактически, это стандартизация ARM-железа.
На этом технические фишки Windows Phone не заканчиваются. Переходя к пользовательской части, стоит упомянуть фреймворк для построения интерфейса (WPF/Silverlight), который из коробки работает очень шустро, отлично масштабируется под разные размер экрана и предлагает мощные возможности по анимации и кастомизации интерфейса под стиль приложения. Да и само SDK навязывало изначально правильную концепцию программирования, заставляя выделять все задачи в отдельные потоки, не только задействуя дополнительные ядра процессора, но и улучшая пользовательский опыт от приложения (неправильно написанные Android-приложения легко могут подвисать при выполнении какой-то работы).
И третья классная фишка, про которую почему-то все забыли — это поддержка DirectX 11. Конечно в WP7 уже была поддержка Xna (именно на его базе написана Terraria), что позволяло писать игры одновременно для Windows, Xbox 360 и собственно мобилок, но он имел некоторые ограничения и был прослойкой между графическим API (как Direct3D или OpenGL) и самой игрой. Windows Phone 8 же давал настоящий, полноценный DirectX 11 — хотя и поддерживал максимум вторые шейдеры, но при этом умел те фишки, которые не умел Android — инстансинг для оптимальной отрисовки геометрии, установка стейтов «пачками» и эффективное «bindless» управление ресурсами шейдеров. Теоретически, это давало возможность портировать полноценные игры с ПК/Xbox на Windows Phone, хотя на практике не так много кто этим пользовался.
Ну и вспоминая аргумент про кидалово Microsoft с обновлениями, нужно помнить, что обратная совместимость с приложениями для более ранних версий системы была: на Windows Phone 8 можно было играть в годноту с Windows Phone 7 (NFS Undercover, NFS Hot Pursuit, Mirrors Edge и ещё некоторые классные мобильные игры), а на Windows 10 Mobile можно было запускать почти любое приложение для Windows Phone 8.
Так в чём же потеря WP — трагедия для мобильного рынка? А вы посмотрите на свой Android-смартфон сейчас. Сколько в нём ОЗУ? 4гб? 8гб? 12гб? Смущает ли вас то, что Android умудряется неприятно подтормаживать даже с такими ресурсами? А теперь вспомните Lumia 520: Snapdragon 200, 512 мегабайт оперативной памяти. Вот так она работает из коробки:
Думаю, это всё красноречиво объясняет то, что без WP случилась дуополия на рынке — Android продолжает жиреть, впустую жрать ресурсы и при этом практически не получать новых фишек из года в год, а iPhone хоть и остаётся всё такой же плавной и шустрой, ребята из Apple явно не чувствуют конкуренции и их смартфоны стагнируют в плане дизайна и в некоторой степени интерфейса…
❯ Мотивация
Мои давние читатели знают мою любовь к смартфонам прошлых лет. Для меня нет понятия запланированного устаревания: если под устройство есть комплект разработки и документация, то при большом желании я могу дописать нужные мне приложения сам.
Мой проект SelfEco (сам себе экосистема) как раз об этом — почти полгода назад я написал клиент YouTube и ВК для Android 2.2+. Фактически это означает, что мои приложения работали на ВСЕХ Android смартфонах от 2010 года и новее.
Исходным кодом своих приложений я свободно делюсь — как в качестве примера читателям, так и для возможности каких-то фиксов в будущем или даже модов. В 2021-2022 году я ходил с Lumia 640XL с Win10 Mobile на борту, как с основным смартфоном. И в целом, меня все устраивало и всё нравилось: там и годный клиент ВК был (LunaVK), и клиент телеги нормальный, и браузер кое-какие страницы всё ещё нормально переваривал. Но больше всего мне нравится Windows Phone 8 — она работает ещё шустрее и несколько более строгая в плане дизайна. Да и «люмии» сейчас стоят сущие копейки — моя 640XL обошлась мне в100 российских рублей(~1.5$ по тому курсу), я не шучу. А на онлайн-барахолках можно найтиживые, целыеаппараты с нормальными аккумуляторами по 200-500 рублей, иногда даже в родных коробочках!
Lumia 1320 и Lumia 640XL — подарки читателя Kotenilla!
Дак почему бы не применить всю эту круть и мощь во благо, учитывая дешевизну смартфонов? Решено: Качаем SDK и пишем собственный клиент ВК и YouTube — это минимально-необходимые для меня приложения!
❯ Подготовка
Для того, чтобы отлаживать и устанавливать сторонние приложения на смартфоны с Windows Phone, их нужно предварительно разблокировать и сделать «Interop Unlock». Процедура несложная и занимает немного времени на большинстве люмий. Дабы сильно не затягивать статью, я не буду описывать процесс разлочки здесь — его можно найти на 4pda для разных поколений устройств.
❯ YouTube
Начинаем с клиента ютуба. Собственно, концепция отнюдь не поменялась с прошлой статьи — мы всё так же используем API Invidous для получения информации о видео. Нативное API YouTube — полная дичь, да ещё и с ограничениями на один токен, в то время как Invidous сам распоряжается токенами и распределяет их как нужно. Нам лишь остаётся написать «морду», которая будет отображать полученные с сервера данные и передавать ссылку на видео в встроенный плеер.
В отличии от Android, никаких проблем с TLS не возникло: смартфон смог без проблем связаться с инстансом Invidous и получить данные о видео в трендах. Сам по себе, формат ответов очень простой и возвращается в виде JSON, который можно описать такой иерархией:
Практически сразу система нам навязывает распараллелленую парадигму написания кода — часть API банально не имеет синхронных аналогов! Например, из WebRequest убрали GetResponse, дабы неопытные разработчики не делали ошибок и не пытались вызывать долгие I/O операции в главном потоке (что вызывает подвисания приложения). .NET сам по себе имеет крутой механизм тасков (многопоточных задач) и реализацию концепции async/await, которая позволяет подождать выполнение операции, не блокируя остальное приложение.
Я решил придержаться более привычной мне концепции на коллбэках, которая позволяет более четко обрабатывать ошибки в подобных кейсах, да и в целом я не очень люблю подобный синтаксический сахар (а async/await и есть «сахар», поскольку разворачивается в стейт-машину). В качестве десериализатора (механизма парсинга JSON напрямую в экземпляры классов, используя рефлексию) я использовал классический Newtonsoft.Json.
После того, как механизм получения и обработки данных с сервера был готов, я начал реализовывать интерфейс приложения. И вот тут WP показал себя во всей красе. ListView? RecycleView? Нафиг эти костыли, винфон умеет нормально рисовать элементы интерфейса, которые вы выделили в ScrollView. И что забавно: в Android даже реализация с ScrollView при активной подгрузке данных вызывала лаги — на WP такого нет вообще! Тут всё просто работает из коробки!
Механизм анимаций здесь тоже декларативный и реализован в концепции т.н «сторибордов» — наборов действий, которые позволяют создавать достаточно сложные анимации вручную.
Буквально через пару часов после создания проекта, у меня уже была готова загрузка и отображение списка трендов:
А затем и логика воспроизведения видео, которая запускает встроенный плеер и передаёт в него ссылку на видео — которая выбирается относительно кодека (только mp4), разрешения устройства и предпочтений пользователя:
Кроме того, в приложение нужно было добавить настройки — для этого WP8 не предоставляет встроенных средств, нужно реализовывать логику самому. Впрочем, ничего сложного в этом нет — глобальный синглтон с полями настроек и логикой сохранения/загрузки (сюда код не поместился, нет нормальной подсветки кода).
WP предоставляет специальное изолированное хранилище для пользовательских программ — IsolatedStorage, в которое нельзя добраться из остальной системы (без разблокированного загрузчика и режима Mass Storage). Там же можно хранить и конфиги — правда с некоторым API для файлов сильно перемудрили — навязывать распараллеливание чтения обычно маленьких файлов — это совсем уже.
Итак, буквально за сутки разработки у меня получилось реализовать приложение, которое может выводить списки ютуба по региону (тренды/популярное), может искать видео и воспроизводить ролики с различными разрешениями. Кроме того, приложение умеет подгружать превьюшки и имеет собственный раздел истории. Неплохо за 24 часа для программиста, который фактически не имел опыта с платформой UWP/WinRT в прошлом, да? :)
❯ ВК
Теперь пришло время реализовать клиент ВК! Фактически, ничего сложного в реализации клиента с базовым функционалом нет — это всё такая же «морда» к данным с сервера, к которым добавляется необходимость получать уведомления и реализовывать логику обновления данных.
На этот раз, я решил выбрать API WP8.1: оно гораздо более богатое на возможности и ближе к современному UWP, чем Silverlight из WP8. Так уж сложилось, что API обычного WP8 ближе к WP7 и совместимо с WP8.1 только с помощью специальной прослойки.
Я не ставил целью написать полноценную замену ныне не рабочему официальному клиенту, но я хотел чтобы моё приложение поддерживало базовый функционал:
Мессенджер: Конечно же, самое важное в нашем клиенте — это мессенджер.
Музыка: Куда ж без удобной ВК музыки? Её реализация в кастомных клиентах отнюдь несложная, но достаточно костыльная из-за политики ВК в отношении лицензирования аудио. Снова будем идти на хаки, дабы получить работающее приложение!
Новости: Помимо общения и прослушивания музыки, бывает потребность полистать ленту — дабы узнать новости, или посмотреть свежие мемчики.
Начал я с реализации окна с диалогами и продумывания навигации приложения. WP8.1 всё ещё не имел концепции боковых менюшек, поэтому реализовывать панель навигации пришлось самому. Вместе с ней была реализована верхняя часть, которая содержит в себе заголовок со статусом и анимацию загрузки:
Класс-менеджер для общения с API ВК я решил реализовать по тому же принципу, что и для клиента YouTube: у нас есть два метода на всё-про всё, один сразу десериализовывает ответ в виде объекта Root (для каждого типа ответа — он свой, все они описаны в Data.Packet.Root):
До async/await я не дозрел и здесь :)
Спустя достаточно короткое время, у меня уже была готова подгрузка диалогов:
Реализация обновления во всех разделах одинаковая: есть метод RequestUpdate, который начинает процедуру обновления и получает данные с сервера, а затем ставит в очередь задачу на обновление UI из основного потока с помощью UpdateUI:
И механизма загрузки/отправки сообщений.
В целом, с этим ничего сложного нет, однако теперь самое время разобраться с нотификациями. Пуши я пока-что поднять не смог, вместо них пока что лонгполлинг — достаточно для нотификаций пока приложение находится в фоне, но система со временем «прибивает» неактивные задачи, а сделать «бесконечный» фоновый таск как в Android не выйдет — система очень строго относится к любой фоновой работе.
Пришло время заняться музыкой — вот это действительно важный функционал! Для работы с аудио, я использовал довольно старый, но известный способ, который ВК пока что не пофиксил. Не то чтобы это из вредности, просто сами ВК особо не идут на контакт для интеграции аудио в своё приложение — исключением стали лишь очень крупные клиенты, как Kate Mobile — а значит можно реализовать действительно важные штуки: например, скачивание треков напрямую в музыкальную библиотеку, дабы их можно было послушать оффлайн! Вся работа с музыкой производится через прокси-сервер, поэтому аудио должно быть открыто.
Реализация фонового прослушивания музыки достаточно похожа на другие платформы, но в то же время заметно отличается. Само приложение может воспроизводить звуки с помощью MediaElement или BackgroundMediaPlayer, однако при сворачивании звук будет приостановлен (в отличии от MediaPlayer на Android). Для фонового прослушивания музыки, Microsoft решили сделать отдельный сервис BackgroundMusicPlayer, который запускается при попытке получить доступ к плееру из программы. Общаться с этим сервисом можно через межпроцессные вызовы — RPC и система предоставляет для него API. Вкратце: нам нужно создать фоновую задачу в виде отдельного модуля WinRT, который будет получать RPC-посылки от Foreground приложения и если нужно — отсылать ответы обратно. Ничего сложного!
Отдельного внимания заслуживает механизм скачивания музыки в библиотеку. В WP, программы не могут просто так «вторгнуться» в личное пространство пользователя — им обязательно нужны разрешения. Но это ладно, запросить разрешение — совсем не проблема. Зато настоящая проблема — ПОЛНОСТЬЮ асинхронный API. Захотел найти дескриптор файла в ФС — асинхронно, захотел его открыть — снова асинхронно. Поскольку у меня вся работа по скачиванию ведется в отдельном воркере и я не боюсь за дедлоки, пришлось лепить костыли с Task.Wait() :)
А ещё ВК возвращает mp3 без ID3-тегов, поэтому мне пришлось вручную их дописывать, дабы музыка в плеере удобно сортировалась:
Кроме того, дабы иметь возможность управлять музыкой из других приложений и экрана блокировки, Microsoft предоставляет т.н интерфейс SMTC — общий оверлей окна регулировки громкости, который позволяет управлять воспроизведением музыки. Его реализация простая до жути — просто включаем нужные кнопки (IsPlayEnabled, IsPauseEnabled и.т.п), добавляем обработчик события нажатия кнопки и обновляем информацию и обложку с помощью DisplayUpdater.
❯ Заключение
Вот таким образом, буквально за несколько дней мы реализовали клиенты нужных нам приложений с базовым функционалом. Разработка клиента YT заняла ровно сутки, разработка клиента ВК — двое суток. Но можно ли всем этим добром по настоящему пользоваться и как оно работает на настоящем устройстве? Смотрите ниже:
Весьма достойно, да? Ещё до публикации статьи, я выложил клиент YT на 4pda и в профильный Telegram-чатик — люди благодарны и действительно довольны. Только в англоязычном чате о WP8.1 (не вклюая WM10 и WP7/WP8) более 2х тысяч человек! Так что да, девайсы прошлых лет действительно нужны достаточно большому числу пользователей.
Ну а разработка клиентов для меня была эдаким челленджом — пилить что-то полезное под новым API всегда интересно, дак ещё и сами девайсы очень крутые с точки зрения UX и скорости работы. А вы как считаете? Жду ваше мнение в комментариях!
Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропустить новые статьи каждую неделю!
Если вы профи в своем деле — покажите!
Такую задачу поставил Little.Bit пикабушникам. И на его призыв откликнулись PILOTMISHA, MorGott и Lei Radna. Поэтому теперь вы знаете, как сделать игру, скрафтить косплей, написать историю и посадить самолет. А если еще не знаете, то смотрите и учитесь.
Сам себе экосистема: Как я адаптировал старый смартфон под современные реалии и написал клиенты нужных мне сервисов
Время неумолимо бежит вперед: выходят новые гаджеты, постепенно заменяя старые, превращая их в тыкву или в лучшем случае, в «тапочек» для звонков. Сейчас смартфоны стали практически одинаковы во всем: дисплей на всю площадь передней панели, почти полное отсутствие аппаратных кнопок, беспроводная зарядка… Это всё, конечно, здорово, но ведь иногда так хочется взять в руки старый, но такой необычный в наше время QWERTY-смартфон и попытаться его использовать как основной, да и цены на них могут приятно удивить: БУ девайс можно купить за несколько сотен рублей (~5-10$). Одна проблема — клиенты приложений на версии Android 1.6-2.0 безбожно устарели и давно не работают. Но иногда желание воскресить старый девайс превыше потребительского качества и тут я пришёл к мысли… а почему бы не написать с нуля свои клиенты популярных приложений? ВК с музыкой, YouTube, трекинг посылок. Так я и сел писать необходимые в повседневной жизни приложения, с нуля, на голом API Android, без каких либо фреймворков (и даже AppCompat). Получилось ли у меня это? Узнаем в статье!
Мотивация
На самом деле копаться в старых девайсах и пытаться найти им применение — это очень интересное и затягивающее дело. Ведь зачастую попытки оживить девайс заключаются в прочтении большого количества мануалов, документации, копании в терминале, а иногда даже компиляции загрузчиков/ядер! И подобные занятия интересны на всех уровнях: хардварный, системный, прикладной и пользовательский. В предыдущих статьях мы с вами моддили девайсы на всех этих уровнях: ремонтировали «железные» болячки, написали несколько статей о системном моддинге и компиляции загрузчиков под неизвестные китайские устройства, а также узнавали о пользовательском опыте установки готовой кастомной прошивки на 7-летнее устройство.
Но до сегодняшнего дня мы с вами обходили прикладной уровень моддинга устройств: т. е. написание самых обычных, повседневных программ, без которых сложно представить жизнь современного человека. Ещё во времена выхода первого Galaxy S в 2010 году, многие из нас уже сутками красноглазили в Java версии «аськи», кто-то уже сидел в ВКонтакте, хоть и большинство не заглядывали в смартфон каждые пару минут для проверки нотификаций.
К 2012 году смартфонная жизнь уже стала похожа на ту, к которой мы привыкли сейчас — соц. сети, мессенджеры, пуши, потоковое видео — многие из нас успели привязаться к такой жизни и… к конкретно тем самым девайсам!
2012 год давно миновал, тенденции в разработке приложений кардинально поменялись, а учитывая, что многие мои читатели не любят выбрасывать девайсы в мусорку (и правильно делают), наверняка кто-то регулярно заглядывает на полочку к своим пыльным «бывшим» гаджетам и рассматривает их с теплотой… но с сожалением понимает, что их время прошло. Или не прошло? :) Ну, тут как посмотреть. Если есть навыки и огромная мотивация, то программер может многое, в том числе и запилить все самые необходимые приложения сам!
Я давно лелеял эту идею, подумывая, как бы лучше её реализовать. Да и почти всю свою жизнь, я писал на C#, практически не «щупав» API Android и его UI фрейморк. В один день у меня очень сильно зачесались руки написать что-нибудь эдакое под него и причём сразу — весьма серьёзное!
Всем этим устройствам более 10 лет. Самым молодым из них является реплика Lumia 1020, которую мы тоже успели замоддить!
Так и родилась идея написать клиент YouTube. А потом и ВК. Ну и трекинг в придачу. Ну а чего б и нет, на всё про всё я выделил себе неделю: за это время я должен успеть закончить пусть и сыроватые, но вполне юзабельные клиенты для моих любимых сервисов. И я начал думать…
Планирование
Написание приложений под старые мобильные ОС, как и под любые другие платформы, требует планирования того, что и как будет работать с учётом ограничений целевой платформы. У меня было сразу несколько ограничений, что только раззадоривало пыл:
В большинстве своём, на старых версиях 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.
Если я его раздобуду когда-нибудь, то в лепешку расшибусь, но портирую на него свои приложения. Тогда я с гордостью скажу, что мои приложения работают на 100% Android устройств %)
Полный энтузиазма я сел писать код. Основную часть статьи я решил поделить на каждое приложение отдельно с конкретными объяснениями: где, что и как я делал. Хочется заранее сказать — я не особо давно пишу под Android, зато много писал под WinForms, поэтому какие-то решения могут показаться странными. А некоторые решения обусловлены версией Android. Например, нотификации в первых версиях Android не было Notification.Builder, а сам Notification был больше похож на структуру. Приложения, конечно же, мы будем писать на Java.
ВКонтакте
Первым делом я начал писать клиент ВК и сразу определился со своими хотелками, которые были весьма скромными: возможность листать диалоги, читать сообщения и отправлять их (с полной поддержкой QWERTY-клавиатур, т. е. отправка на Enter), плюс возможность слушать музыку без ограничений. На ВК бочку ни в коем случае не гоню, просто публичного API совсем нет, даже с ограничениями, хотя было бы здорово…
Мне снова хотелось почувствовать те эмоции, которые я когда-то ощущал от прослушивания музыки будучи школяром со своим первым Android-смартфоном. В 2013 году я прилетал со школы и слушал плейлист на практически таком же девайсе с идентичным железом и версией Android. Я хорошо помню, как пользовался прелестями многозадачности Android на 2G интернете (3G чипсет просто не поддерживал): одну песню слушаешь, поставил вторую качаться, пока песня доиграет — уже и вторая скачалась. :)
Итак, хотелки выбраны, пора начинать писать приложение. Для дебага у меня было 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 чуть позже).
Архитектура приложения получилось довольно простой и примитивной. При старте активити авторизации проверяет данные приложения (PersistStorage) на наличие API-токена и при его отсутствии запрашивает авторизацию. Как это уже стало классическим среди различных «самопальных» клиентов, мой клиент «прикидывается» официальным приложением ВК — для этого используется связка app_id и app_secret приложения ВКонтакте для Android.
После авторизации приложение перенаправляет нас на страницу диалогов. Поскольку у нас нет ни пушей, ни лонгполлинга, метод обновления остается один — в заданные интервалы. Для этого у нас есть Handler, который раз в 3.5сек берет список диалогов с сервера, проверяет, обновились ли данные и если да — обновляет датасет, отправляя сигнал обновления интерфейса (который построен на ListView). Кроме того, у нас есть кэш аватарок — точно так же распаралелленый на несколько потоков, а загруженные на данный момент превьюшки хранятся в хэшмапе.
При этом сообщения реализованы схожим образом — на данный момент возможности горячей подгрузки сообщений «сверху» нет, поэтому обновляются последние 50 сообщений скопом и сразу. Шустро ли всё это работает? Вполне неплохо. Конечно, основное процессорное время уходит на разбор тяжелых JSON, но тут отчасти вина ВК — мало того, что кастрировали функционал getHistory в последних версиях API, так ещё и нет возможности возвращать только те поля, которые нужны.
Как же я поступил с аудиозаписями? Музыка через API — настоящая заноза для разработчиков клиентов, с которой пришлось «подолбаться». Правда, недолго — раз у нас для основных запросов уже есть сервер-реле, то почему бы не сделать ещё и для музыки? Суть обхода простая: если сгенерировать специальный API-токен, то можно свободно обращаться к методам, связанным с музыкой без необходимости притворяться официальным клиентом и «подписывать» запросы md5 ключом. Примитивный PHP-скрипт как раз и предоставляет такую возможность, позволяя получить доступ к базе музыки ВК, однако ограничение типичное — у пользователя должны быть открыты аудиозаписи:
Тут был код на пхп, о его скушал пикабу!
По итогу у меня получился рабочий плеер с поиском музыки и добавленными треками. Опять же — производительность остаётся отличной! Ссориться с ребятами из ВК не хочу, поэтому добавлять возможность качать треки пока не стал — но вам стоило бы быть подружелюбнее к разработчикам кастомных клиентов! :)
Что мы получили по итогу? Довольно простенький клиент ВК, который практически не потребляет ОЗУ и шустро работает. Да, здесь не хватает кучи различных фич — как минимум, прсомотра ленты и стены. Но ещё успеется — если проект будет интересен не только мне, то продолжим наращивать фишечки потихоньку! Уже ближе к релизу я слегка причесал клиент, добавив более «вкшный» дизайн и приделал анимированное боковое меню. Про Animation ещё кто-то помнит? :)
YouTube
С разработкой клиента YouTube были свои особенности: во-первых, в отличии от клиента ВК, видео через реле просто так не загрузишь, слишком много трафика, а во-вторых, YouTube уже не «отдаёт» видео в форматах, которые поддерживают старые устройства — в основном, это h263 до 720p. К сожалению, потоковое видео с софтовым декодированием уложит на лопатки большинство «одноядерников» тех лет.
Ситуация осложнялась тем, что ни VideoView, ни стандартные плееры всех смартфонов, на которых я отлаживал приложение, не умели игнорировать ошибки SSL и просто валились с ошибкой. Пришлось что-то придумывать: ведь видосики хочется смотреть на крутейшем AMOLED дисплее Galaxy S!
Посидел я, подумал и придумал. Для поиска по базе YouTube, получения информации и прямых ссылок на видео я решил использовать альтернативный фронтэнд YouTube, который называется Invidous API — крутая штука со своим API, которая сама распределяет пул токенов самого ютуба и отдаёт ответы в виде JSON. Форматы запросов очень простые: <url инстанса Invidous>/api/v1/метод, например «search?q=test®ion=RU&hl=ru» — выдаст нам результат поиска «test» в Российском регионе. Очень удобно, да? А ещё Invidous — не какой-то отдельный сервис, а целая сеть т. н. инстансов — какой хочешь, такой и юзай! Поскольку большинство инстансов «прячется» за свежими сертификатами, пришлось идти на довольно известный костыль с отключением верификации хостнеймов у HttpUrlConnection:
А туть был костыль на Java.
А поскольку у нас нет возможности воспроизводить потоковое видео онлайн, то я решил его просто предварительно загружать через собственный менеджер закачек, с возможностью последующей очистки кэша. Поскольку таким устройствам 2060p качество не нужно, я выбираю 240p-360p mp4 в avc кодеке, в среднем ролики по 30 минут весят около 30-40 мегабайт. При HSDPA+, загрузка подобного видео займет около минуты-двух — не так уж и много, можно и подождать. Закинул тестовую версию в беседу любителей ретро-мобилок — люди были в восторге. ;)
Поскольку 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. А вы как считаете? Жду ваше мнение в комментариях.
Статья подготовлена при поддержке компании TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи про девайсы каждую неделю! А ещё не забудьте проставить плюсик на хабре, если статья вам понравилась - это поможет с финансированием и выходом новых статей!