В общем, я очередной "вкатун", "вайтишник", "свитчер" или как там нас ещё называют.
Изучаю Java, параллельно работая на своей работе (я работаю в нефтегазовой отрасли и она мне ужасно надоела, собсна из-за чего и собираюсь вкатываться). Учу java-core уже 4 месяца. Да, согласен, это медленно, но на работе выходных у меня практически нет.
И слава богу, что до Spring и прочего непотребства я ещё не успел дойти, потому что у меня назрел резонный вопрос: почему не андройд разработка?
Изучение рынка труда java backend оставила неизгладимое впечатление безнадеги, а один знакомый HR, который хайрит как раз джава бэкендеров сказал, что в этой отрасли людей без опыта НЕ РАССМАТРИВАЮТ ОТ СЛОВА СОВСЕМ. Но это если верить ему. Как дела обстоят на самом деле я не знаю
Собсна поэтому и обращаюсь к всезнающей аудитории Пикабу. Пока не начал изучать стек для бэкендера может перейти на андройд, доучив джаву и затем приправить все это дело котлином и остальными технологиями, нужными в андройд разработке? Как вообще с новичками дела обстоят в этой сфере? Легче ли вкатывание чем в джава бэкенд? Сопоставимы ли зарплатные вилки?
Заранее всем большое спасибо за ответы. Я надеюсь, что этот вопрос дойдет до нужной аудитории
Итак, в прошлый раз я описал три проблемы, которыми, на мой взгляд, страдают все MVx и даже некоторые не MVx архитектуры. Если коротко, то это:
проблема остатка — при делении фичи на заявленные компоненты архитектуры остаётся либо «неделимая» часть фичи, либо лишние компоненты архитектуры;
проблема масштабирования — при расширении фичи компоненты архитектуры начинают раздуваться, что усложняет дальнейшую поддержку;
и проблема разрывов логики, когда из-за взаимодействия с UI логика разрывается на части, что тоже не помогает нам делать систему более цельной, предсказуемой и тестируемой.
Описание проблем это, конечно, хорошо, но вопрос в том, как их решать? Об этом я бы и хотел поразмышлять в этом тексте. Спойлер: когда я нашел решение проблемы разрывов, я понял, что оно может решить и все остальные проблемы.
❯ Проблема остатка (Remainder issue)
Первый вопрос: что делать с остатком? Все просто — взять делитель поменьше, потому что чем меньше делитель, тем меньше остаток. Этому меня еще в школе научили. Но я столкнулся с тем, что это не работает с MVx архитектурами, потому что мой делитель, обычно, это набор определенных компонент, и введение новых — значит изменение архитектуры.
Возможно и вы с этим сталкивались, когда вводили всякие мапперы, делегаты, интеракторы (те, что репозитории репозиториев) и прочее. Помогли ли они мне? Нет. Лучшее решение, что я видел — это Flux- и ELM-like архитектуры, которые заявляют «чистую» функцию как единицу деления логики, но со всеми вытекающими отсюда удобствами и следующими за ними «эффектами».
Но решение проблемы остатка, даже если бы оно у меня было, не помогает мне решить проблему масштабирования.
❯ Проблема масштабирования (Scalability issue)
В прошлый раз я упоминал «интуитивный» подход к решению задачи масштабирования и рассказывал почему он не работает. По крайней мере не у меня.
А какой не интуитивный?
На мой взгляд это старая и уже не раз решенная задача. И примеры решения можно увидеть в том, как в теории вычислений доказывают некоторые теоремы через вкладывание одной машины Тьюринга в другую, или как элегантно эта проблема решается в процессорах, где более сложные компоненты — просто композиция более простых.
Так и в MVx архитектурах: можно было бы попробовать реализовывать доработки отдельно, а уже потом объединять их с существующей фичей, вместо того, чтобы вносить изменения в уже написанные компоненты. Что в прошлом не раз приводило меня к череде переписываний тестов, судорожному протыкиванию приложения на предмет того, что ничего не поменялось, и мольбам о том, чтобы очередной баг-репорт был не по моим изменениям.Но вот что я заметил, ведь именно такой подход, когда мы предпочитаем композицию изменениям, я и мои коллеги используем для Data-слоев. Например, новые источники данных оборачиваются в Репозитории, а потом комбинируются в Интеракторы. Но почему-то чем ближе мы подходим к UI-слою, тем больше начинаем изменять, а не комбинировать.
Чаще всего я вижу эту проблему как вечное переписывание тестов уже существующих компонент, или Presenter, ViewModel, Controller размером со вселенную, который даже трогать страшно, потому что что-то точно развалится.
Такой подход, где мы предпочитаем покомпонентную композицию фичи и доработок, вместо прямых изменений какого-нибудь компонента, действительно будет не интуитивным, потому что потребует реализовывать доработки как самостоятельную фичу. Я имею ввиду, что надо будет имплементировать доработки используя наш архитектурный подход, а потом написать еще одну пачку компонент, которая уже будет склеивать существующий функционал с новым. Но каким бы правильным мне это не казалось, я никак не могу отделаться от мысли, что такой подход приведет к написанию большого количества кода, который на первый взгляд будет казаться бесполезным.
Еще мне показалось интересным, что тут нам может помешать проблема остатка, которая по идее должна привести к ситуации, когда такой подход не сработает, потому что надо будет внедрить доработки в “середину” компонента из уже существующей фичи, а значит придется делить существующие компоненты на новые, более мелкие. Чем крупнее делитель, тем крупнее остаток, да?
В итоге, даже использовав “неинтуитивный” подход к масштабированию, я все-равно не могу до конца понять как решить проблему масштабирования. А между прочим еще остается проблема разрывов.
❯ Проблема разрывов (Gaps issue)
И вот тут становится интересно. Все дело в Hello World. Мне все никак не дает покоя вопрос: какая у него архитектура?
Hello world
Я видел примеры Hello World в разных языках, фреймворках и архитектурах (кроме Open GL, конечно же), и у них не было проблем с его реализацией. Если не считать проблемой то, сколько усилий надо приложить, чтобы написать изначальный шаблон. Но, если результат одинаковый, не значит ли это, что разница только в том, сколько обвязок надо написать, чтобы Hello World работал? И нужны ли они? Тогда я стал думать: а что общего у всех этих реализаций Hello World в разных архитектурах? И как-то я пришел к мысли, что скорее всего правильный ответ — Алгоритм. И он до безобразия тривиален.
И что интересно, у самого алгоритма нигде не написана архитектура в которой он должен быть имплементирован. Но это Hello World. Как я и сказал: он чересчур прост.
Более интересные примеры
Давайте лучше взглянем на следующий пример, который используют в учебниках по программированию — Hello %username%. У него все та же проблема с архитектурами — его можно написать в любой из них, и общее между всеми реализациями в разных архитектурах — алгоритм.
А вот еще интересное наблюдение: если мы немного обобщим алгоритм Hello World, отделив show от Hello World, то увидим, что он дважды появляется в алгоритме этого примера.
Все еще слишком просто, правда? Следующий учебный пример — работа со структурами данных. И в самом простом виде — это CRUD плюс “показать все” с хранением в списке (он же List). Этот пример, не очень интересный с точки зрения реализации, интересен тем, что он добавляет в предыдущий алгоритм композицию.
По сути здесь мы первый раз сталкиваемся с тем, что нам надо создать пять независимых программ, а потом объединить их под управлением шестой. А еще эти шесть программ делят между собой один блок памяти — сам список структур. И мне кажется, что это уже напоминает решение одной из наших проблем, не так ли?
Появление Gaps issue
Но что происходит даже с этими простыми программами, когда мы пытаемся перенести их в UI-среду?
Легче всего Hello World, потому что он просто обрастает кучей компонент, которые помогают ему “жить” в новой среде. Даже не интересно.
А вот Hello %user name% приходится куда сложнее. Беднягу размазывает по компонентам системы или архитектуры: в одном месте мы слушаем ввод имени, в другом показываем приветствие, а в третьем прописываем реакцию на введенное имя.
Я даже боюсь говорить о том, что же происходит с CRUD-примером. В зависимости от того, какой макет нам нарисуют, мы будем писать совершенно разные приложения. Вот представьте, что вас попросили сделать такую программу как несколько разных экранов, а потом попросили переделать так, чтобы это был один экран. С часто используемым подходом к декомпозиции, когда один экран — один набор MVx-компонент, мы получим бессонную ночь переписывания кода, потому что части нашей логики разорваны и раскиданы по всей реализации.
Но ведь изначально “не было ни единого разрыва”, а алгоритм остался тем же. Почему все стало так плохо?
Причина — асинхронность
На этот вопрос некоторые уже дали ответ в комментариях к предыдущим статье и видео, и я с ними полностью согласен. Причина — асинхронность. И я был искренне удивлен, когда пришел к этому выводу.
Многие, если не все GUI-системы построены вокруг event loop, потому что нам надо одновременно и экран рисовать, и ввод от пользователя слушать. А чтобы сюда добавить еще и наш алгоритм, его придется разделить так, чтобы он хорошо встраивался в этот event loop.
Я уже не говорю о том, что мы вообще-то еще должны взаимодействовать с другими асинхронными системами. Кстати, с ними то, обычно, проблем и не возникает. А почему?
Решение — закрытие разрыва
Обратим внимание на графикоподобную картинку, на которой я объяснял проблему разрывов в прошлый раз.
Напомню как всё было, и в этот раз уже не буду лукавить: путь нашей логики начинается в каком-то из callback’ов, а не в абстрактном “начале”. По мере выполнения мы продвигаемся все глубже по стеку вызовов, выполняем одну за другой функции, и в самой верхней точке нашего графика мы обращаемся к источнику данных: бэкенду, файлу, какой-то системе хранения. И что здесь обычно находится?
Обычно это вызов какой-то “асинхронной” функции: корутины, async- или suspend- функции, уж простите мой котлинский, или какой-то функции с callback’ом, или функции возвращающей какой-нибудь Future, Promise или Single.
И вот вопрос: вызывая эту функцию с callback’ом, как часто мы задумываемся, что эта операция может вообще никогда не вернуться в этот callback? Лично я до недавнего времени считал, что управление гарантированно будет передано в наш callback. Не считая случаев “отмены”, конечно же. Но откуда у нас такая гарантия? Возможно все дело в реализации системы? Давайте “заглянем под капот” и посмотрим что же там на самом деле происходит.
Наша функция формирует наш запрос к базе, запрос в сеть или еще что-то. В общем случае формирует какой-то контекст, с помощью которого надо выполнить запрос, и вместе с callback’ом, в который надо вернуть результат, отправляет его на другой поток, и там происходит все выполнение. После завершения выполнения, тот поток вызывает callback, передавая в него результат, что для нас, разработчиков, выглядит как своего рода возврат в точку вызова. Таким образом логика выглядит более цельной, и такого разрыва, как в случае с UI не происходит.
Так вот вопрос: а почему бы нам не повторить этот же трюк с UI?
На картинке это будет выглядеть как параллельный перенос: мы просто поднимем нашу линию, а вот тут, в нижней точке, вместо того чтобы разрывать логику и отдельно задавать на UI какое-то состояние и callback’и, сделаем функцию, которая отправляет запрос на UI и ждет от него ответа. Таким образом мы закрываем разрыв и теперь наша логика будет выглядеть как единое целое.
Ничего сложного, мы даже не изобретаем что-то новое, но такой подход поможет нам взаимодействовать с UI, как с любой другой внешней системой, а не как с чем-то особенным. И вот моё видение того, как это могло бы работать и решать проблемы, описанные выше.
❯ Proposal
Давайте писать функции…
Да, может звучать нелогично, тем более, что я уже говорил о том, что это не помогает Flux- и ELM-like архитектурам, но я объясню. Начнем с проблемы остатка.
Влияние на решение проблемы остатка
Добавлю небольшую аналогию с математикой. Как я и говорил «архитектура» — это делитель. А чтобы при делении не оставалось остатка — нам нужно найти наибольший общий делитель. Чем и является функция, на мой взгляд. Чем больше я смотрю на реализации всех наших «архитектур», тем больше я вижу, что все они, по сути, просто один из способов удобнее объединять и специализировать функции (и тут я подразумеваю, что метод класса — это функция, которая иногда неявно принимает дополнительный аргумент).
Дальше лучше — проблема масштабирования.
Решение проблемы масштабирования
Функции очень хорошо масштабируются, потому что, с точки зрения реализации, они могут вмещать в себя любой набор инструкций и в том числе вызовы других функций, а с точки зрения пользователя функции это всегда просто вызов функции: имя, параметры, результат, независимо от того как она реализована.
А что с разрывами?
Решение проблемы разрывов
До тех пор, пока мы будем поддерживаем нашу логику, как композицию функций, проблема разрывов будет естественным образом «выталкиваться наружу», за пределы нашей логики. А это в свою очередь будет гарантировать нам последовательность выполнения, тестируемость и как следствие — стабильность.
❯ Концепт
Так что же я предлагаю?
Во-первых, реализовывать логику, как функции и их композицию, а не как компоненты какой-нибудь архитектуры. Это позволит нам гарантировать и поддерживать последовательность выполнения, позитивно скажется на масштабируемости и тестируемости нашего кода, да и понимать такой код будет проще.
Во-вторых, у этой функции (композиции функций) должна быть возможность работать независимо от «сторонних» систем, поэтому я предлагаю вынести ее в свой поток, чтобы у нее была возможность спокойно выполняться, блокироваться при необходимости, параллелиться и тому подобное. Пусть будет “синхронной”. Обычно мне не надо, чтобы логика продолжала свое выполнение, когда она ждет какой-то ресурс. А если такое поведение нужно, то почему-бы его не описать его явно? И назвать бы этот поток Main, но имя уже “занято”. =)
В-третьих, хотя это и самый важный пункт, а у меня видимо есть тенденция оставлять все важное на потом, я предлагаю сосредоточиться на реализации логики приложений, а не экранов и виджетов. Как видите, с таким подходом нет разницы между слоем данных и пользователем. Есть только наша детерминированная логика и внешние системы, которые обмениваются данными через нее. Логика просто ходит между ними и предоставляет им некий контекст для принятия решения и набор возможных действий, а внешние системы в свою очередь “отвечают” нашей логике руководствуясь представленным контекстом. Это похоже на игру в шахматы, где внешние системы — игроки, а логика — доска с фигурами и правила игры.
Логика наших фич зачастую не зависит от представления, а как раз наоборот: представление является способом, который помогает логике взаимодействовать с пользователем в определенной среде, как какой-нибудь адаптер. Я думаю, что такой адаптер должен быть плагином к логике, а не фактором определяющим ее.
В конце концов, применив этот концепт, я хочу помочь всем нам проектировать и писать кроссплатформенные приложения в самом широком смысле этого слова: разрабатывая и реализуя end-to-end алгоритмы которые прозрачно перескакивают с бэкенда на фронт и обратно, которые не видят различия между разными видами фронтов, будь то Web, iOS или Android, или разными типами вроде UI, CLI, или TalkBack.
Но пока это только концепт и виденье. Пожалуй пора посмотреть на код, но он будет в следующий раз. А сейчас есть время порефлексировать на эту тему. Дайте этим идеям время перевариться. Прочитайте еще раз. Задайте вопросы. И может вы сможете написать код еще до того, как я опубликую продолжение. Хотите посоревноваться?
Увидимся.
Написано специально для Timeweb Cloudи читателей Пикабу. Больше интересных статей в нашемблоге на Хабре и телеграм-каналах (статьи и новости).
Привет, пикабу! Доделал первую версию бота для своей онлайн стратегии типа "Катан". На гифке ИИ бот сам играет и побеждает в игре. Ну а вы можете попробовать победить его бесплатно на мобильных устройствах с андроид, компьютерах с windows или в браузере. Ссылки для каждой платформы найти можно тут: https://plugfox.dev/make-world-ru/
В наше время, из-за санкций одноплатники стали стоить каких-то «конских» денег. Даже б/у RaspberryPi Zero стоит 2-3 тысячи рублей на барахолках, что, мягко скажем, не совсем лояльная цена для «самого дешевого одноплатного компьютера в мире». Конечно, Orange Pi Zero всё ещё можно купить в пределах 1.500-2.000 рублей, но как по мне и эта цена не слишком лояльна за те характеристики, который предлагает такой одноплатник. С другой стороны, Android-планшеты 10-летней давности продаются на барахолках по 100-300 рублей, что выглядит гораздо привлекательнее, причём на некоторые устройства практически без костылей можно установить полноценный дистрибутив Linux! Вероятно, многие читатели скажут мол «автор бомж» и будут правы: ведь в рамках этой статьи, я хочу рассказать о том, как использовать полурабочий древний планшет в качестве полноценного одноплатника путём подключения его к микроконтроллеру и выводу GPIO! Сегодня мы с вами: узнаем, как подключить микроконтроллер к шине UART в планшете и научимся работать с последовательной шиной в Android прямо из Java и нативных программ. Интересна моя концепция антикризисного одноплатника? Тогда добро пожаловать под кат!
❯ Зачем это нужно?
Пожалуй, нельзя сказать, что подобная концепция пристраивания старых планшетов — вопрос исключительно цены. 2-3 тысячи рублей не такие уж и большие деньги и при желании можно купить хотя-бы Б/У, но всё таки полноценный одноплатник с нормальной GPIO-гребенкой. Однако здесь стоит вопрос не столько дешевизны, сколько E-Waste: зачем выкидывать в помойку потенциально рабочие планшеты с живым процессором, если их можно пристроить куда-то ещё?
На самом деле, планшеты с ROOT-доступом уже из коробки могут выполнять весьма полезные задачи, как, например, хостинг http-сервера для домашней страницы, работать как панель с часиками и погодой, или, например, работать в качестве HMI-панели для оформления заказов в шаурмечной. Кроме того, многие планшеты на базе смартфонных чипсетов (MediaTek, Spreadtrum) имеют полноценный Bluetooth-модуль, что позволяет «подружить» планшет с микроконтроллером через радиоканал, что значительно расширяет возможный спектр применений.
Преимуществ у такого подхода много: у «пожилого» планшета уже есть большой, достаточно качественный (хороший TN, либо даже IPS) дисплей с тачскрином, который поддерживает мультитач, GPU для вывода 3D-графики, 3.5мм для вывода звука + встроенные динамики, а также весьма неплохое, по сравнению с дешевыми одноплатниками, железо. Звучит весьма вкусно для цены в 300 рублей: собрать хоть немного похожую конфигурацию на базе RPi выйдет в 10-15 тысяч рублей (учитывая дороговизну MIPI-матриц с тачскринами + цену самой «малинки» и обвязки для аудиотракта).
Но при всех перечисленных достоинствах, атрибутом любого полноценного одноплатника является наличие GPIO — и даже здесь мы сможем с вами выкрутится! Первый способ, о котором я чуть выше вскользь рассказал, позволяет реализовать общение с МК и «ногодрыг» через BT-радиоканал, но минусы такого подхода очевидны (МК с BT дороже, радиоканал потребляет дополнительную энергию, некоторые могут посчитать BT небезопасным). Однако есть и второй подход, который заключается в использовании диагностических пятачков UART на плате устройства для наших личных целей!
С таким подходом можно использовать как «голый» Linux, используя концепцию, которую я представил в этой статье, так и взаимодействовать из Java-приложений для Android (что даёт уже, как минимум, удобный GUI-фреймворк). Сегодняшняя статья будет «без воды», только чистая конкретика, поэтому давайте перейдем к реализации!
❯ Подготовка
Как я уже говорил выше — в рамках данной статьи мы рассмотрим использование UART в планшете для наших собственных целей. UART — это двунаправленная полнодуплексная цифровая шина, которая позволяет обеспечить стабильную передачу данных при относительно невысокой скорости, измеряемой вбодах. То есть, быстро стримить картинку с её помощью вы не сможете, но сможете, например, получить состояние входов МК, прочитать что-то на шине I2C, используя мост UART -> I2C или, например, прочитать показания датчиков, которые МК предварительно опросил.
Сама по себе концепция очень простая: многие китайские производители планшетов и смартфонов не только разводят UART в виде отдельного пятачка на плате, но и подписывают его, задействуя UART-канал как вывод для логов ядра, а иногда и предоставляя доступ к рутовой консоли! В свою очередь, из юзерспейса мы можем получить доступ к UART с помощью устройства/dev/ttyS<x>на подавляющем числе чипсетов и/dev/ttyMT<x>на MediaTek. Однако учтите, что в некоторых случаях придется патчить загрузчик, дабы редиректнуть логи ядра в /dev/null.
Однако наличие UART на плате — не всегда признак того, что он сконфигурирован в системе верно. Например, на смартфонах с чипсетами SC6820 нормально завести UART я так и не смог, а на некоторых устройствах на базе MT657x нужно патчить загрузчик, дабы он «увидел» нужный канал UART! В моём случае, героем статьи стал планшет Prestigio, у которого отказал тачскрин, но был доступен UART:
Конкретно в моём случае, после установки последней официальной прошивки планшет перестал слать логи на UART и устройство /dev/ttyMT3 оказалось доступным для наших операций, в вашем же случае может потребоваться настройка devicetree, или просто патчинг загрузчика, дабы редиректнуть консоль на другой вывод UART. Кроме того, необходимо обязательно получить root-доступ хотя-бы к adb shell, поскольку доступ к /dev/tty устройствам возможен только от имени суперпользователя. Как же проверить UART на возможность чтения/записи? Сначала нам необходимо взять ESP32 или любой UART-USB преобразователь, припаять сигнальные линии RX/TX и использовать любую программу для работы с последовательным портом, например Putty. Заходим в adb shell, и пишем что-нибудь в консоль:
Вуаля! Всё работает :)
Работает? Замечательно, значит мы сможем использовать планшет вместе с микроконтроллером! Переходим к практической реализации нашего приложения!
❯ Используем из Java
Я специально решил выделить для Java-подхода отдельный раздел, поскольку просто взять и открыть /dev/ttyMT3 с помощью FileInputStream не выйдет. Дело в том, что даже несмотря на наличие root-доступа, по факту ни одно Android-приложение его не имеет (за исключением подписанных системных в папке /system/app/) и для всех операций, требующих повышенных привилегий, либо распаковывают и запускают внешнюю нативную программу из под суперпользователя, либо с помощью специального костыля с запуском sh-программ читают/пишут нужные блочные устройства сами. Связано это с тем, что все Android-приложения работают в хост-процессе app_process, который форкается (отпочковывается) от «главного» процесса, который запущен из под «простого» пользователя, который не находится в группе system.
Здесь концепция также очень простая: su имеет аргумент -c, который позволяет запустить команду от имени root-пользователя и возвращает объект процесса, дабы мы потом могли перехватить stdout:
Таким образом, для чтения текстовых данных из UART'а нам достаточно лишь периодически «слушать» stdout команды cat и обрабатывать данные:
Костыль, но со вкусом :) Если вас не устраивает такой подход или ваше приложение значительно более комплексное, вы можете использовать UART и из под нативных программ.
❯ Используем из C
Работа с последовательными портами в Linux не отличается от работы с любыми другими файлами и устройствами: вызовов open, read, write и close обычно хватает и лишь иногда к ним в довесок нужен ioctl.
int fd = open("/dev/ttyMT3", O_RDWR); int result = write(fd, command, strlen(command));
Для работы с терминалом необходимо использовать модуль termio который предоставляет все необходимые структуры для настройки режима работы терминала, в т.ч и бодрейт. Дело в том, что изначально последовательное устройство настроено на режим работы в качестве терминала, т.е драйвер отдаст данные только после того, как устройство на UART пошлёт \n, или превысит размер внутреннего буфера для сообщения. Если вам нужно работать с бинарными данными и получать их «на лету» — необходимо настроить последовательный порт в «binary» режим:
Если же вам достаточно текстового терминального режима, то можно продолжить как есть и использовать fgets, fscanf и прочие удобные функции из libc! О том, как собрать нативную программу для смартфона и как вообще выбросить Android из него, читайте в моей отдельной статье.
❯ Заключение
Вот таким образом можно использовать проводную шину в планшете для собственных нужд! Как видите, совершенно ничего сложного и используя эти наработки, я реализовал уже не один проект! Надеюсь, материал вам был интересен и полезен :) Пишите своё мнение, можно ли использовать дешевые планшеты по 300 рублей в качестве одноплатников?
Статья была подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю! Ну а больше подробностей о будущем контенте, как обычно, в первом комменте! Также у меня есть свой Telegram-канал, куда я выкладываю свои мысли, советы по ремонту и моддингу различных гаджетов, а также вовремя публикую ссылки на новые статьи!
Друзья! Много ли платформ вы знаете, где для написания пользовательских приложений используется стек… веб-технологий, причём это единственный нативный способ писать программы? Услышав о HTML5 + CSS + JS, на ум приходит разве что webOS — которая используется в современных телевизорах от LG (а ранее использовалась ещё и в Palm Pre — уникальный смартфон, единственный в своём роде), а олды вспомнят ещё и про FireFox OS, в которой вся оболочка (включая многозадачность, шторку уведомлений и все приложения) также была реализована на JS. Но ни webOS, ни FFOS в своё время не суждено было стать массовыми ОС на смартфонах: сказывались аппаратные ограничения устройств, да и проблемы с портированием уже существующих приложений с других платформ (например, игр). Однако несколько лет назад, проект FireFox OS был форкнут и на свет появилась новая система, предназначенная для… умных кнопочных телефонов с LTE! И имя ей — KaiOS. Вероятно, многие мои читатели слышали о ней и о новых умных кнопочниках от Nokia. Но что из себя представляет система под капотом и чем она может быть интересна гику? Читайте в новом материале!
❯ Предыстория
В наше время, стек веб-технологий стал чуть ли не вторым по важности для разработки клиентских приложений. С появлением PWA и модных MVC-фреймворков, а также таких проектов, как Electron, визуальная составляющая многих приложений радикально поменялась: стало возможным реализовывать кастомный, гибкий и адаптивный интерфейс с поддержкой тем и анимаций буквально в несколько строчек кода. Такой подход значительно упрощает и удешевляет разработку клиентских приложений для популярных сервисов: например, «набросать» своё приложение для MP3-плеера может даже зелёный джун, который только начал писать код.
Первой попыткой сделать PWA-приложения «нативными» был, как ни странно, первый iPhone. iOS 1.0, которая в те годы ещё называлась iPhone OS, не имела AppStore и поддержки нативных ipa-приложений и предлагала просто выносить значки нужных сайтов на рабочий стол. При этом возможность отображения полноценных десктопных сайтов была одна из самых сильных сторон iPhone в те годы! Как показала практика, Стив Джобс немного поспешил с интеграцией PWA на смартфонах и в iOS 2.0 уже был добавлен AppStore, куда разработчики могли публиковать нативные и быстрые приложения!
Alcatel OneTouch Fire E — один из двух смартфонов на FireFox OS в моей коллекции!
Но всё это итак знакомо многим моим читателям: подписчики часто жалуются на то, что современные приложения жиреют и лагают, а ещё тащат за собой целый CEF и миллион npm-пакетов из-за чего даже какие-то простые приложения начинают требовать слишком большие ресурсы. Но кто бы мог подумать, что веб-стек найдет своё место на… кнопочных мобильниках! Казалось бы, дешевые кнопочники не имеют ресурсов для запуска полноценного браузера, их главная задача — именно звонить. Но ведь на складах всё ещё лежат, полагаю, целые стеллажи бюджетных смартфонных процессоров 10-летней давности, которые вполне способы запустить Android… смекаете, к чему я? :)
KaiOS появилась как форк и концептуальное продолжение провалившейся FireFox OS: система от Mozilla предлагала множество интересных концепций и шустро работала даже на очень-очень бюджетных смартфонах, несмотря на веб-направленность. Минимальные требования системы были скромными: ОС шустро работала на бюджетном ZTE Open с 256Мб ОЗУ и чипсетом MSM7225A из 2012 года. FireFox OS работала на ядре Linux, основой был браузерный движок Gecko, а поскольку Mozilla, полагаю, не смогла заручиться поддержкой вендоров чипсетов и хотела, чтобы систему мог портировать на своё устройство любой желающий, для взаимодействия с железом устройства система использовала драйвера для… Android! Поскольку Gecko собирался с использованием стандартного libc, а драйверы использовали bionic, FireFox OS активно использовала библиотеку libHybris, что позволяло портировать систему на уже существующие смартфоны с любыми чипсетами.
LG fx0 — редчайший смартфон на FireFox OS. Правда на фото он на Android :)
Идея системы простая: формально, это один большой браузер (оболочка Gaia), который при запуске приложений создаёт ещё маленькие «браузеры» (элемент webview, это не iframe). Плюсы такого подхода очевидны: отказоустойчивость (потенциально, весь рестарт Gaia — это WebView.Refresh. В случае Android — это закрытие всех приложений и перезапуск app_process), безопасность (нельзя вызвать Private API), лёгкость отладки и малый вес конечных приложений (причём вес — основной критерий для публикации приложения в официальном магазине KaiOS, пакет до 20Мб). Стоит ли говорить о том, что приложение на такое устройство сможет написать даже ребенок, а игру в стиле «Змейки» можно реализовать за пару часов? Порог вхождения значительно ниже даже чем на Android!
В основном, KaiOS разрабатывалась как система, которая должна вывести кнопочные телефоны из разряда «просто-звонилок» и позволить использовать на привычных устройствах современные мессенджеры и различные сервисы (например, тот-же YouTube). Пожалуй, это отнюдь не «прокачанные бабушкофоны», как некоторые могут подумать, а перспективные девайсы с современным железом (поддержка дисплеев высокого разрешения, 3D GPU, LTE) и заделом на будущее, пусть пока и без крутых девайсов в стиле Nokia N-серии. Концепция умных кнопочников не ограничена KaiOS: выходят различные девайсы и на Android, об одном из таких смартфонов я даже писал две отдельные статьи с обзором и моддингом.
Сейчас на барахолках можно найти дешевые девайсы на KaiOS до 2х тысяч рублей, правда свежие Nokia ценятся обычно выше. Мне же достался в подарок Nobby 240 LTE от моего читателя jameskod007, за что ему большое спасибо! Чем такие девайсы могут быть интересны гику? Давайте посмотрим!
❯ Что «под капотом»?
Под капотом у устройств на KaiOS трудятся старые и такие знакомые многим читателям бюджетные чипсеты, как MediaTek MT6572 (использовался в смартфонах до 3-4х тысяч рублей в 2014-2015), SpreadTrum SC7731E (наследник SC7731 2014 года с другим GPU) и Qualcomm 205 (судя по всему, наследник Snapdragon 200 — популярного чипсета 2014-2015 года, который использовался, например, в Lumia 520). Само собой, это позитивно сказывается на цене устройства: зачем в девайс с дисплеем 240x320 ставить 800'ый Snapdragon? :)
Значительным плюсом подобных устройств является простота обслуживания. По правде сказать, здесь и ломаться то особо нечему: дисплей относительно надежно защищен от внешнего влияния с помощью воздушной прослойки и защитного стекла, а элементная база смартфона весьма маленькая и «не ломучая». Разбирается смартфон просто: достаточно лишь открутить несколько винтов с обратной стороны корпуса и расщелкнуть телефон пластиковой картой. Что забавно — такие формы корпусов будто «унифицированы» среди производителей дешевых телефонов, никто, почему-то, не экспериментирует с корпусами в стиле а-ля Nokia N-серий.
Перед нашим взором открывается плата. К сожалению, я пока не видел на кнопочных смартфонах UART в открытом виде, иначе давно бы реализовал что-то типа такого. На плате мы можем заметить, что LTE-версия Nobby 240 работает на достаточно свежем Spreadtrum SC9820E с двумя 64-битными ARMv8 ядрами Cortex-A53 на частоте 1.3ГГц и GPU Mali T820 MP1, а также с LTE модемом. Чип выполнен по техпроцессу 28Нм, максимальное разрешение дисплея — 480x854 (т. е. DSI матрицы всё таки поддерживаются, параллельно с DBI). Весьма шустрый чипсет для девайса такого класса, его едва ли можно назвать «бабушкофонским», подобные характеристики были флагманскими для смартфонов ~2012 года. Для сравнения — простые кнопочники все еще работают на ARMv5 ядрах на частоте около 200-300МГц.
Дисплей припаян и приклеен к плате, подключен к процессору при помощи 16-битного протокола 8080, а не MIPI DSI, как в современных смартфонах. Его разрешение — классические 240x320. Поиск его замены скорее всего не составит труда, хотя точная модель контроллера мне пока неизвестна (предполагаю, либо ILI9341/ILI9325, либо ST7731, либо так любимый китайцами GC9306).
А вот клавиатура — болячка таких девайсов. По каким-то причинам, пластиковые толкатели кнопок очень быстро изнашиваются и кнопки начинают дребезжать (нажиматься несколько раз одновременно), либо не прожиматься. Это очень обидно и неприятно, но быстрофикс есть — напечатать крохотные проставки на 3D-принтере.
В остальном, конструктивно девайс вполне хорош и надежен. Корпус почти не поддается трещинам и царапкам, при аппаратных болячек его относительно легко диагностировать. Ну не замечательно ли? Давайте глянем, чем интересен девайс с точки зрения веб-разработчика!
❯ Веб-разработка
Для разработки нам потребуется совсем немного: любой текстовый редактор (хоть блокнот), FireFox 59 и platform-tools с adb для Android. В первую очередь, на смартфоне необходимо включить режим отладки, который активируется набором кода *#*#33284#*#* (DEBUG) в номеронабирателе. После этого, в шторке уведомлений появится значок «жука». На некоторых устройствах, режим отладки активируется прямо в настройках. После этого, смартфон будет виден через adb и мы сможем дебажить на нем свои приложения!
Теперь нам необходимо накатить «древний» FireFox 59, это последняя версия с поддержкой WebIDE и возможностью деплоя под FireFox OS от 2018 года. WebIDE — это дебаггер и менеджер приложений для экосистемы Mozilla, активируется с помощью хоткея Shift + F8. Не забудьте отключить авто-обновление в настройках браузера!
После этого, нам необходимо связать WebIDE с нашим смартфоном с помощью «Remote Runtime». Однако перед этим, нам необходимо форварднуть adb-сокет с помощью команды:
После этого, мы жмем «Remote Runtime» и «Runtime Info», дабы получить информацию о нашем девайсе и убедится что всё нормально:
Создаём новое приложение и вперед творить! По правде сказать, я практически не знаю, каких приложений особо не хватает на KaiOS. ВК частично есть, YouTube почти полноценный, WhatsApp тоже реализован… не хватает разве что Telegram? Но я лично не смог бы полноценно чатится с телефона такого типа (и дело не в форм-факторе), поэтому я решил запилить ради прикола приложение-виджет для просмотра погоды в моём городе :)
У каждого приложения есть манифест, который объявляет используемые разрешения, значки и различные данные, необходимые для публикации приложения в магазине приложений. Существует три типа приложений: «web» (Hosted web apps — или, фактически, PWA), «privileged», и «certified» (приложения с доступом к критичным функциям смартфона типа СМС. В привилегерованном режиме, приложения могут обращаться к службам KaiOS, таким, как например Bluetooth и настройках сети.
Сначала я сверстал простенький интерфейс для приложения. Логика простая: поскольку это приложение-виджет, при его запуске отображается прелоадер (анимация загрузки), а как только данные загружены — программа показывает блок content и скрывает анимацию загрузки. Никаких фреймворков типа React я тащить не стал, но для более сложных приложений придётся продумывать более сложную логику для реализации диалогов.
Не ругайте за <center>! Я не веб-разработчик, адаптивные верстки делать не умею :))
Фетчить данные мы будем с OpenWeatherMap, хотя можно попросить доступ к API и у Gismeteo. Формат запросов у API очень простой — фетчим данные о погоде в локации относительно координат широты/долготы, при этом встроенный API для геокодинга поможет найти координаты того или иного района в городе. Делаем вот такой GET-запрос:
queryWeather(onReady) { var req = new XMLHttpRequest(); req.onreadystatechange = () => { if(req.readyState == XMLHttpRequest.DONE) { var json = JSON.parse(req.responseText);
Вся логика программы уложилась в 85 строк кода. Преимущества веб-подхода и «жабоскрипта» при грамотном использовании очевидны, согласитесь? Опять-же повторюсь, я не веб-разработчик, мои познания в JS ограничиваются «олдовым» стилем уровня начала-середины 2010х годов, я, вон, даже jquery тащить не стал.
❯ Рут
Изначально материал должен был состоять из двух частей: обзор «клиентской» части девайса с приложениями на веб-стеке и выкидывание B2G, дабы реализовать нечто подобное одной из моих более ранних статей. Но вендор смартфона подложил «свинью»: у устройства залочен загрузчик и разблокировать его штатными средствами невозможно. Вообще, инфраструктура FireFox OS имеет много общего с Android изнутри, так что я попробовал с помощью патчера magisk'а пропатчить бут и залить в него su… но увы, девайс валился на верификации signed-образа и отказывался прошивать раздел! За это жирнющий минус вендору.
Если хотите взять подобный девайс для моддинга и экспериментов, присмотритесь к девайсам на Android, или KaiOS на базе MT6572/SC7731 — те обычно разблокированы с завода. Например, год назад я сделал первую кастомную прошивку для Android-кнопочника и написал для него кастомный лаунчер.
Я лично буду очень рад, если ЕС обяжет вендоров смартфонов давать возможность заводской разлочки загрузчиков, иначе это ущемление в правах тех людей, которые покупают смартфон с изначально открытой системой!
❯ Заключение
Вот такой материал про KaiOS у нас с вами получился. Теперь вы и сами знаете, что девайс может быть интересен не только как «бабушкофон» или продвинутая звонилка, но и как платформа для реализации каких-то собственных прикольных фишек :)
Какие применения могут быть у такого девайса? Да самые разные! Например:
Маленький фронтэнд для данных с микроконтроллера: тут уже и дисплейчик небольшой есть, и кнопки, а также GPU, если нужно показывать какие-то данные в 3D. Почему-бы и нет?
BT-плеер в машину: пилим фронтэнд к ВК Музыке/Спотику или еще какому-либо сервису, коннектим по BT и получаем миниатюрный автомобильный самодостаточный плеер, который еще и аккумулятор относительно долго держит :)
Часы с погодой: частичную реализацию этого проекта я уже представил в статье. Собственно, а почему-бы и нет? Многие смартфоны от Motorola и Sony с док-станциями сейчас так и используют. Почему бы не заюзать для этого и девайс на KaiOS?
Надеюсь вам было интересно! Пишите своё мнение, есть ли перспективы у смартфонов на KaiOS? Также у меня есть свой Telegram-канал, куда я выкладываю бэкстейдж со статей, различные заметки о ремонте, моддинге и программировании под девайсы прошлых лет и вовремя публикую линки на новые статьи. Подписывайтесь!
Насчёт машины
Друзья! Те читатели, которые подписаны на меня наверняка знают о том, что я коплю на покупку ТАЗика, дабы реализовать интересный проект с разработкой самопального ГУ "из того что было" по самому дешману. Сейчас у меня есть чуть более 100.000 рублей, из которых 8.000 рублей - донаты читателей! В Ейске, на юге, за такие деньги купить относительно живой по мотору и, что немаловажно, с +- целым дном тазик сложновато. Я даже Волгу и Москвич рассматривал как вариант, но Волга ушла, а у Москвича мотор не родной. Если вам нравятся мои статьи и вы хотите помочь материально будущему проекту - с помощью формы ниже можно помочь проспонсировать проект!
Если вы вдруг живете в Ейске или в 50км от Ейска и вы или ваши знакомые продают относительно живой ТАЗик (кроме классики, критерии - на ходу, чистые документы и не совсем панорамное дно. Машинка может быть помята, с плохим ЛКП и конечно другими косяками, машина ведь не новая!) - пишите в ТГ @monobogdan!
Статья подготовлена при активной финансовой поддержке TimeWeb Cloud. Не стесняйтесь пользоваться их услугами, если вам нужен VDS, выделенный сервер или иные облачные услуги. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать интересные технические статьи каждую неделю!
С момента выхода первой части статьи из рубрики «сам себе экосистема» прошёл уже практически год! За это время, мы успели с вами реализовать клиенты 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 медиаэлементов. Так что листинги будут совсем без табов, но алгоритм их работы понять можно :)
Позволю себе чуточку критики в сторону 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);
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, что означает готовность библиотеки к работе:
После этого, можно начать работу с данными. Обратите внимание, мой подход потоко-небезопасен, его нельзя дергать из нескольких потоков одновременно! В коде ниже, я вызываю метод для фетча сообщений, а затем в соответствующем коллбэке от TDLib обрабатываю данные (дабы статья не разрасталась на 20+ минут, я чуть урезал все листинги).
public List<Message> QueryMessagesInChat(long chatId, long lastMessage, int count) { messages.Clear();
public User QueryUser(long userId) { string json = Utils.Format("{\"@type\": \"getUser\", \"user_id\": \"{0}\" }", userId); NativeInterface.Send(InstanceID, json);
waitHandle.WaitOne(); return user; }
Переходим к реализации самого сервера, для наших целей хватит обычного HttpListener. Сначала мы зарегистрируем все поддерживаемые методы и занесем их в ассоциативный список ключ-значение. Сами методы реализованы в виде делегатов, которые принимают лишь один аргумент — список параметров из строки запроса, а возвращают строку — все ответы, за исключением особых (связанных с загрузкой вложений) — текстовые.
Переходим к обработке запроса. Метод ищет, зарегистрирован ли запрошенный метод и если да, то парсит строку запроса, которая начинается с "?", которую затем передаёт в виде коллекции ключ->значения обработчику метода:
А сами методы, в свою очередь, дергают соответствующие функции из клиента и формируют на их основе датасет в примитивном формате:
public staticstring QueryChats(Dictionary<string, string> args) { if(args.ContainsKey("count")) { int count = int.Parse(args["count"]); StringBuilder ret = new StringBuilder();
В результате получаем вот такой простой датасет, который, как я и говорил, легко распарсить и на Siemens C60, и на Atmega328 — да где угодно! В целом, такой сервер можно использовать для реализации бота в телеграме, который будет передавать показания каких-то датчиков, сигнализацию и прочие клевые штуки!
Переходим к реализации клиента, т.е. приложения на Android. Здесь будет не менее интересно!
❯ Пилим для Android
В геймдеве есть своеобразный мем — некоторые инди-разработчики сначала начинают делать меню, вместо основного геймплея, что становится предметом насмешек среди других разработчиков. Но в разработке приложений для смартфонов всё по другому — здесь как-раз таки хорошо заранее продумывать макет будущего приложения!
Поскольку у нас с вами мессенджер, то главный экран должен представлять из себя список чатов (ListView) и верхнюю панельку, где в будущем могут разместиться настройки и свайп-менюшка:
Такой вот простой макет.
Каждый пункт меню — это тоже отдельный layout, в котором мы по шаблону строим внешний вид будущего элемента списка. На немолодых устройствах есть смысл использовать как можно меньше контейнеров в layout'е, поскольку пересчет позиций и размеров элементов — одна из самых «тяжелых» операций в UI-фреймворке вообще. Кроме того, не стоит использовать кучу картинок и drawable — в Android 2.x всё 2D рисуется софтварно, аппаратное ускорение появилось только в 3.0 (частично).
Но дабы в списке диалогов что-то появилось, нужно сначала реализовать фетчинг (получение) этих самых диалогов с сервера! Сам объект, который занимается обработкой запросов называется ClientManager и является синглтоном — он в единственном экземпляре на все время работы программы. Помимо менеджмента «ноды» (т.е. прокси-сервера), токена для авторизации и обработчика ошибок, ClientManager реализует метод для асинхронного запроса информации с сервера и, собственно, формирует строки запросов с помощью соответствующих методов:
Подгрузка чатов и сообщений реализована через Adapter — концепция «виртуальных» списков, которая предполагает что система создаст не 50 элементов интерфейса на каждую кнопку чата, а только 5 и будет их виртуально «мотать по кругу», обновляя только данные в уже существующих элементах. Это позволяет значительно ускорить отрисовку, учитывая то, что Android 2.x Canvas рисуется программно.
Ну вы уже явно замучились видеть простыни кода, давайте посмотрим что у нас вышло!
Шустренько, да? А ведь это ультрабюджетник Alcatel OT-916D, один из последних массовых дешевых QWERTY-смартфонов за 5 000 рублей из 2012 года. Кстати, смартфон подарил мне читатель chuvakoff с Хабра!
Переходим к окну чата. Основной макет почти такой-же, как и у основного окна: только добавилась панелька для ввода сообщения снизу.
Концептуально, всё тоже самое — запрашиваем данные с сервера, парсим их и загружаем в адаптер, благодаря чему мы сможем листать наш диалог. Однако в сообщения я добавил контекстное меню с стандартными фишками типа копирования, ответа и прочих подобных действий. Поскольку у нас нет ни пушей, ни еще каких-либо средств для поулчения данных о новых сообщениях, я раз в определенный интервал просто получаю сообщения — и если новый датасет отличается от старого — обновляю окошко чата.
Переходим к реализации поля для ввода сообщения. Здесь всё просто — на серверсайде за это отвечает метод SendMessage. Однако для того, чтобы с нашего клиента можно было ответить на другие сообщения, я ввёл также «контекст ответа», в котором запоминается сообщение, на которое мы хотим ответить. Telegram также поддерживает Markdown, однако его полная поддержка пока не реализована.
В остальном же, функционал конечно пока совсем базовый, однако клиент работает очень шустро даже бюджетной X10 Mini Pro и позволяет чатится с моими читателями в Telegram. В будущем хотелось бы допилить:
Поддержка картинок: Сейчас уже есть кривоватый механизм кэширования изображений на стороне сервера, который позволяет загружать аватарки чатов. В будущем, я добавлю поддержку «галерей» с картинками!
Поддержка голосовых сообщений: Не все их любят, но они порой удобны и выручают. Реализую как прослушивание, так и запись!
Подробный просмотр профилей и менеджмент чатов: Удаление сообщений, чатов и прочие фишечки из официальных клиентов.
Казалось бы — до официальных клиентов ещё очень далеко. Но сам факт, чтобы всё это работало достаточно шустро на девайсах, которым уже более 10 лет!
❯ Звучит интересно! Как заюзать твой клиент?
Тут всё очень и очень просто! В первую очередь, нам понадобится ПК с белым IP, роутер (если под него есть сборка dotnet), либо VDS. Виртуальные сервера сейчас стоят копейки, у ТаймВеба есть тариф за 188 рублей в месяц, которого с головой хватит для нашего сервера.
Такая вот рекламная интеграция (к слову, прокси для всех приложений уже более года крутятся именно на мощностях TimeWeb Cloud)!
Программа сначала запросит номер телефона, а затем код подтверждения 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, чтобы не пропускать новые статьи каждую неделю!