Некоторые особенности разработки под Ubuntu Touch



    Пришла весна. Коты думаю о кошках, мужчины о женщинах, а программист — куда бы ещё портировать имеющийся код. Я ещё прошлой осенью стал обладателем Meizu MX4 Ubuntu Edition, и поэтому выбор был давно очевиден. А тут нашлось и время, и силы.

    Освоение новой платформы состояло в портировании на неё сначала библиотеки Allegro, а потом — моей игры Return of Dr. Destructo, о которой я уже здесь писал, и мобильная версия которой всё ещё находится в разработке под iOS и Android, но уже вот-вот скоро когда-нибудь выйдет.

    Впрочем, на особенностях портирования именно моего проекта в этом посте я сосредотачиваться не буду, а просто расскажу, с какими подводными камнями повстречался в этот раз. Цели у меня две: во-первых, систематизировать и объединить в одном месте информацию, которая может быть полезна начинающим разработчикам под Ubuntu Touch, а во-вторых — просто напомнить всем о существовании этой платформы, с надеждой общими усилиями сделать её ведущей на мировом рынке, а то на основную пару лидеров у меня профессиональная аллергия.

    Мой опыт с данной платформой распространяется исключительно на разработку OpenGL приложений, поэтому если вас больше интересует использование нативного UI (Qt), то здесь вы может найти для себя не так много интересного. Впрочем, как раз разработка Qt и QML приложений достаточно неплохо документирована на официальных ресурсах, в отличие от моих задач (и ЕЩЁ одна платформа опять забыла о геймдеве на старте...).

    Чем хороша Ubuntu Touch, и как начать с ней работать


    Лично для меня, как для разработчика игр, Ubuntu Touch хороша, в первую очередь, тем, что в отличие от Android здесь программы на C++ являются гражданами первого сорта. Все системные библиотеки и службы имеют C++-интерфейсы, не надо писать никакого кода на странных языках, чтобы создать окошко или отправить запрос на оплату. Официальная IDE — QtCreator, не лишена недостатков, особенно в плане отладочного UI, но в целом очень неплоха, а главное — «из коробки» хорошо поддерживает отладку C++ приложений на устройстве, которую Google в своём Android Studio до сих пор прикрутить нормально не может, бе-бе-бе. Ну, а плюс по сравнению с iOS тут главный в том, что не нужно иметь Mac (или страдать с плохо работающими виртуальными машинами)

    Теперь о минусах. Во-первых, вам всё же придётся поставить Ubuntu или какой-то более-менее совместимый Linux. Причём поставить его на Virtual Box — плохой вариант! Разработчики Ubuntu Touch-плагина под QtCreator использовали OpenGL (QtQuick) для отрисовки своего UI, и как результат, в Virtual Box всё это работает очень плохо — например, окно QtCreator'a всегда находится поверх любых других окон.


    Ubuntu IDE приветствует нас

    Так же, лично мне не удалось заставить Ubuntu SDK увидеть моё устройство, пока я пытался работать в Virtual Box, при том, что сама Ubuntu его видела. Но тут, возможно, был мой косяк, я так и не разобрался, и поставил Ubuntu на реальное железо.

    Чтобы начать разрабатывать приложение под Ubuntu Touch, проще всего поставить Ubuntu SDK. В общем-то, никто не мешает скачать нужные компоненты и руками, но мне кажется, это больше боли, чем нужно в организме. По инструкции для установки SDK надо подключить PPA, в котором оно живёт (вообще-то, SDK есть и в обычном Software Centre, но может быть какой-то не той версии?).

    Если вы будете пока что довольствоваться эмулятором, то дальше надо его создать в закладке Devices. Процесс подробно описан, однако заставить его работать мне так и не удалось — эмулятор вроде бы как создавался, но видеть его IDE не хотела (возможно, я указал при создании версию framework, отличающуюся от той, с которой компилировал программу).

    Чтобы запуститься на устройстве, придётся включить на нём режим разработчика. К моему невероятному удивлению, для этого потребовалось установить на нём PIN-код, которым я раньше не пользовался! Очень неудобно, минусик Canonical, Андроид такой фигнёй заниматься не заставляет.

    Кроме того, компьютер будет видеть телефон, только если у того включён экран и снят лок-скрин (который с кружочком). Что интересно, набирать ПИН-код как раз не надо.


    Подключённое устройство здорового человека

    Если даже после этого ваш телефон (а может быть и планшет) всё равно не появился в списке устройств во вкладке Devices, то придётся вспомнить полученные при общении с всё тем же Андроидом навыки, и лезть править конфигурацию ADB (поскольку пока что все наличиные устройства с Ubuntu Touch в основе своей являются Андроид-устройствами). Посты (1, 2) рекомендуют добавить в файл ~/.android/adb_usb.ini vendorID вашего устройства.

    chroot, зачем он нужен для компиляции под Ubuntu Touch, и что с ним делать


    Опытные линуксоиды, давно знакомые с chroot, schroot, а может уже даже и с click, могут пропустить эту секцию, чтобы не смеяться над тем, как жалкие виндузятники познают мощь Линукса.

    Чтобы скомпилировать приложение, понятное дело, нужна туча всего — компилятор, линковщик, гора библиотек. Всё это должно быть в наличие под ту платформу, под которую мы компилируем. Google решили эту проблему, задав несколько переменных окружения и создав свои собственные скрипты для сборки (ndk-build). Решение, надо сказать, довольно плохое, с трудом работающее с внешними системами сборки, и ненадёжное, как и вся поддержка C++ «корпорацией добра». Зато платформо-независимое (ну, в теории).

    Ubuntu SDK пока работает только под Ubuntu, теряет ему нечего, поэтому тут всё по другому. Для сборки создаётся файловая система, полностью отражающая нормальную линуксовую, но с gcc под ARM, и с библиотеками для архитектуры armhf в нужных директориях. Далее, эта ФС объявляется рутовой на время сборки, и всё работает, как если бы у нас просто был такой вот хитрый, специально заточенный под сборку для ARM Linux.

    Достигается это при помощи механизма chroot, которые позволяет работать с этими вот самыми хитрыми ФС. Нужные chroot'ы Ubuntu SDK создаёт сама по вашей команде, поэтому разбираться с ними досконально не обязательно. Но учтите, что процесс это довольно долгий, т.к. всё содержимое chroot'а (а это много-много пакетов, около 1.5Gb) выкачивается из сети, а создавать его надо под конкретную архитектуру (i386 для эмулятора, или armhf для реального устройства или другого эмулятора) и конкретную версию SDK.

    Интересное начинается тогда, когда вы решили, что хотите использовать не только те библиотеки, которые идут в стандартной поставке chroot'а, а ещё какие-нибудь дополнительные. Документация гласит, что всё, что входит в поставку chroot'a — гарантированно будет на телефоне, всегда в совместимых версиях, поэтому с такими библиотеками можно смело линковаться динамически, и рассчитывать на то, что у юзера на телефоне всё заработает. Но многого из того, что нужно для жизни разработчика игр там нет: libpng, libfreetype, libogg… Всё это придётся ставить руками, и вот тут появляется необходимость знать о chroot'ах больше.

    Дело в том, что chroot поддерживает не только работу с отдельной подменной ФС, но и создание её снимков. Базовый, source снимок при обычной работе остаётся неизменным, чтобы вы ни делали. Более того, можно насоздавать сессий, и у каждой сессии тоже будет свой снимок source, который будет жить, пока жива сессия (и, что важно, не будет отражать изменений в source, если они за это время произойдут!). Сессии, создаваемые Ubuntu SDK переживают не только рестарт редактора, но даже перезагрузку компьютера!

    Правильные способ ставить новые библиотеки в chroot — использовать кнопочку «Maintain» в закладке «Click» в разделе «Ubuntu» в настройках IDE. Это даст вам консоль, в которой можно позвать apt-get install libpng-dev:armhf и тому подобное. При этом, изменятся будет как раз source chroot. Правда, вот не знаю, перезапустит ли свои сессии редактор.


    Вот вам скриншот, чтобы не заблудиться

    Если же вам захотелось полазить по chroot'у руками, из-за пределов IDE, или, скажем, написать скрипт, автоматизирующий установку нужных пакетов в свежескачанный chroot, то команды для этого описаны в документации, но я повторю их здесь, потому что лично я их там в первый раз упустил, и долго тормозил.

    click chroot -a armhf -f ubuntu-sdk-15.04 run COMMANDNAME — запускает COMMANDNAME внутри (не source!) chroot'a и сразу же выходит. Параметр -a — архитектура, для которой создан chroot, -f — версия SDK. С помощью этой команды, установить в chroot ничего нельзя (всё установленное тут же исчезнет), но можно запустить, например, сборку, или find, с целью найти что-нибудь внутри chroot'овой ФС.

    click chroot -a armhf -f ubuntu-sdk-15.04 install PKGNAME — запускает apt-get install PKGNAME, изменяет source chroot

    click chroot -a armhf -f ubuntu-sdk-15.04 maint — аналогично кнопочке «Maintain», запускает консоль для изменения source chroot'a

    И ещё пара важных команд:

    schroot --list --all-sessions — покажет нам список всех активных сессий

    schroot --end-session SESSION_ID — убьёт указанную сессию

    Если вы поставили библиотеку в chroot самостоятельно при помощи install или maint — не забудьте убить сессии, принадлежащие Ubuntu SDK, иначе QtCreator не заметит сделанных изменений (я потерял из-за незнания этого день)!

    Напоследок, уточню: то, что вы поставили в chroot руками — на телефоне по умолчанию будет отсутствовать! Поэтому с такими библиотеками надо либо линковаться статически, либо таскать их с собой в click-пакете (просто указать, какие либы вам нужны, и надеяться, что при установке вашего пакета в систему зависимости докачаются сами, как при использовании deb, нельзя — click так не умеет идеологически).

    Миру — Mir


    Привычных Иксов на Ubuntu Touch нет. Вместо них, там имеется давно обещанный Canonical Mir, который всё никак не придёт на десктопы, а на мобилках — уже пожалуйста, здравствуйте, вот и он. По своему API, Mir очень милый — всё просто, достаточно неплохо документировано, и, чудо из чудес, большинство функций имеют и синхронный, а асинхронный вариант, что вообще такое супер, что суперее некуда. Более того, если вдруг хочется почему-то позвать асинхронную функцию, а потом, в другой точке, дождаться её результата — есть mir_wait_for, который это сделать позволяет. Просто как будто люди писали, а не обычные инопланетяне!

    Из минусов, следует отметить почти полное отсутствие официальных примеров Mir-клиента. То, что лежит на вики — демонстрирует лишь самые-самые основы, и не демонстрирует того, что нужно нам — а именно, как связать MirSurface и контекст OpenGL. К счастью, в других местах примеры найти можно.

    Учтите, что API Mir'a пока не очень стабилен, поэтому приведённый выше пример не компилируется — функции mir_surface_get_egl_native_window не существует. Вместо неё, для получения из MirSurface окна, совместимого с eglCreateWindowSurface, следует использовать связку mir_buffer_stream_get_egl_native_window
    (mir_surface_get_buffer_stream(surface))
    .

    Также, следует помнить, что Ubuntu Touch не поддерживает OpenGL ES первой версии — только OpenGL ES2 и 3! Нужные хидера и библиотеки просто отсутствуют. Поэтому, если у вас, как у меня, где-то завалялся легаси-код времён Очаковских и существенно до нового покорения Крыма, то придётся обложить его ifdef'ами.

    Не забудьте передать в списке атрибутов eglChooseConfig пару

    EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT
    

    А в списке атрибутов контекста для eglCreateContext —

    EGL_CONTEXT_CLIENT_VERSION, 2
    

    Иначе будете долго удивлённо смотреть на многозначительные ошибки BAD_CONFIG и BAD_ATTRIBUTE. Чёрт побери, XXI век на дворе, OpenGL до сих пор не умеет рассказать, какой именно аттрибут плохой, и что ему не понравилось в конфиге…

    Обработка ввода в Mir осуществляется путём установки обработчика событий. Что совершенно прекрасно — если вы используете Mir из программы на C++, то вам будет доступен вариант API с поддержкой std::function в качестве коллбэков. Ну, а если вам больше по душе обычный C, то будет вам вариант с простыми указателями на функции и void *context.

    А коды клавиш Mir присылает те же самые, что X11, так что не спешите выкидывать ваш вариант функции get_key_name!

    Make it Click


    И вот, допустим, портируемый нами код скомпилировался, и готов к запуску. Возникает вопрос, как его засунуть на устройство, вместе с ресурсами, динамическими библиотеками и прочими чертями рогатыми. deb нынче не модно, на rpm, который вы нежно любите ещё с Mandrake 6.0, Ubuntu Touch даже не посмотрит, а использовать надо новый формат пакетов — Click. Именно его и собирает Ubuntu IDE для заливки на телефон.

    На мой взгляд, существенным минусом Click-пакетов по сравнению с IPA или APK является то, что он — не ZIP, а что-то своё, хитрое. Как результат, вот просто взять, и посмотреть, что же там напаковалось — низзя, придётся лезть в консоль, разбираться в ключах click. Впрочем, конечно, скоро кто-нибудь напишет плагин для Midnight Commander, чтобы была Click VFS, и всё снова станет более-менее хорошо.

    Существенным плюсом click является то, что засунуть в него можно что угодно, и как угодно внутри расположить (почти). Всё, что там лежит, во время запуска пакета будет смонтированно в качестве файловой системы от корня, и дальше вы сможете искать библиотеки и данные по привычным вам путям в каком-нибудь /usr/local. Это, конечно, если ваше приложение переехало на Touch с обычного Линукса. Если же оно — гость с враждебной Винды, то может вам и не надо дублировать структуру папок, привычную линуксоидам, а просто плюхнуть исполняемый файл прямо в корень, а данные — рядом, чтобы не искать, и всё удобно и просто. По умолчанию, Ubuntu IDE делает именно первый вариант, но уговорить её перейти ко второму при помощи редактирования CMake или QMake файлов — не сложно, если вы уже знакомы с их INSTALL-директивами.

    И есть, значит, ещё один тонкий момент, а точнее, три. Для подготовки click-файла, вам ещё понадобятся:

    a) manifest.json — файл с описанием, что ваша программа есть, для какой она архитектуры, и кого бить, если что-то не работает. Он же содержит имена для следующих двух файлов в разделе «hooks»

    б) AppName.desktop — файл, описывающий как выше приложение на телефоне выглядит — имя, иконка и т.п. — и как себя ведёт. Последнее касается, например, настроек сплэш-экрана, а также допустимых ориентаций (см. ниже)

    в) AppName.apparmor — файл, где перечисленно, что вашей программе можно (по умолчанию — всё нельзя). Аналог permissions в AndroidManifest.xml.

    Тут мы с некоторым недоумением натыкаемся на отсутствие документации. Базовое содержимое всех трёх файлов проблемы не представляет — его можно подсмотреть в шаблонах, или в сети, но я приведу их здесь для полноты.

    manifest.json:

    {
        "name": "APPNAME.DOMAINNAME",
        "description": "DESCRIPTION",
        "architecture": "ARCH",
        "title": "TITLE",
        "hooks": {
            "APPNAME": {
                "apparmor": "APPNAME.apparmor",
                "desktop":  "APPNAME.desktop"
            }
        },
        "version": "VERSION",
        "maintainer": "NAME SURNAME <EMAIL@ISP.COM>",
        "framework" : "FRAMEWORK"
    }
    


    Содержимое manifest.json легко редактируется с помощью встроенного в Ubuntu IDE редактора.

    AppName.apparmor:

    {
        "policy_groups": [
            "networking",
        ],
        "policy_version": 1.3
    }
    


    Сюда надо добавлять нужные вам разрешения. Это тоже удобнее делать через редактор IDE.

    AppName.desktop:

    [Desktop Entry]
    _Name=VISIBLE_APP_NAME
    Exec=EXECUTABLE_NAME
    Icon=ICON
    Terminal=false
    Type=Application
    X-Ubuntu-Touch=true
    X-Ubuntu-Supported-Orientations=landscape 
    

    А вот desktop-файл почему-то не редактируется в IDE, точнее, открывается просто в виде текста. На первый взгляд, это не проблема, но на второй, когда добираешься до конца и видишь все эти X-Ubuntu-Whatever, сразу возникают вопросы — а сколько этих настроек вообще, и какие они бывают. Разработчики под новую платформу — они подобны исследователям нового континента, и поэтому спрашивать их про такие вещи — всё равно, что спрашивать исследователя, сколько на новом континенте рек — «а хрен его знает». Документации по нашему континенту Ubuntu в этом плане почти нет. Известно следующее:

    Общая документация по формату имеется тут, и содержит много полезного, но только не X-поля.

    X-Ubuntu-Touch=[true/false] — это несущий костыль, который показывает, что, что приложение телефонное, а не десктопное.
    X-Ubuntu-Supported-Orientations=[portrait/landscape/primary] — допустимые для приложения ориентации экрана (primary — это, как я понимаю, portrait для телефонов и landscape для планшетов). Список взят отсюда, в более официальных доках есть только первые два варианта; чтобы поддерживать все возможные положения экрана — не указывайте этот ключ вообще.
    X-Ubuntu-Gettext-Domain=[?] — имеет отношения к выбору файла перевода, который будет использовать. Точнее — я не понял, с документацией всё тухло.

    Поля, контролирующие поведение сплэш-экрана:
    X-Ubuntu-Splash-Show-Header=[true/false] — показывать ли заголовок приложения на сплэш-экране.
    X-Ubuntu-Splash-Title=[TEXT] — какой именно текст показывать в заголовке.
    X-Ubuntu-Splash-Image=[FILENAME] — изображение, которое будет показано на сплэш-экране. Изображение будет показано в том размере, в котором есть, без подгонки под размер экрана.
    X-Ubuntu-Splash-Color=[COLOR] — (сплошной) цвет фона сплэш-скрина в формате QColor::setNamedColor.
    X-Ubuntu-Splash-Color-Header=[COLOR] и X-Ubuntu-Splash-Color-Footer=[COLOR] — цвета верха и низа сплэш-скрина, между которыми будет сделан градиент.

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


    Редактор manifest-файла. Вот хочу такой же для desktop-файлов


    Ubuntu IDE: CMake vs. QMake


    Матёрый линуксоид, конечно, с презрением смотрит на все эти ваши IDE, собирает программы при помощи старого доброго make, устанавливает их на устройство из консоли, и отлаживает консольным же gdb. Мы же, изнеженные прелестями Visual Studio и прочих богопротивных IDE, хотим, чтобы всё нам было на блюдечке с голубым графическим интерфейсом. Поэтому пытаемся использовать Ubuntu IDE, а также чуть менее инопланетные системы сборки, например, CMake или QMake.

    Если вы фанат QMake, и давно используете его для всех ваших проектов, у меня для вас отличные новости — на Ubuntu Touch у вас всё будет зашибись! Подключите нужный модуль при помощи load(ubuntu-click), добавьте в проект описанные выше манифесты, и всё должно заработать.

    С CMake в теории тоже всё просто. Для того, чтобы Ubuntu IDE начала запускать ваши проекты на телефоне, достаточно указать в вашем CMakeLists.txt следующую строку с путём к manifest-файлу вашего приложения:

    set(UBUNTU_MANIFEST_PATH "manifest.json" CACHE INTERNAL "Path to manifest file")
    

    Очень важный момент — обязательно укажите, что переменная попадает в кэш! IDE будет её искать именно там, а если не найдёт — ничего не скажет, но работать всё будет неправильно. Кроме того, мои эксперименты показали, что нельзя указывать путь к manifest'у через переменные CMake. Во всяком случае, значение "${CMAKE_SOURCE_DIR}/manifest.json" приводило к тому же эффекту, как если бы я вообще не указал ничего.

    Далее, имеет место быть странное, и я бы даже сказал бажное поведение IDE. Даже если вы всё указали совершенно правильно, IDE создаст для вашего приложения две конфигурации запуска. Первая будет по имени совпадать с тем, что у вас было указано в CMakeLists.txt в add_executable. Это плохая, негодная конфигурация, и она выбрана по умолчанию! В этой конфигурации, сборка кода и пакета идёт под ARM, а вот запускать всё это IDE будет пробовать на десктопе. Чего у неё, естественно, не будет получаться (если у вас не ARM-десктоп), и вы будете видеть в Application Output ошибки вида

    Selected architecture arm is not compatible with reported target architecture i386:x86-64
    Architecture rejected target-supplied description Debugging has finished
    

    Чтобы так не было, надо зайти в закладу Run в разделе Projects вашего проекта, и там переключиться на вторую конфигурацию. Её имя будет взято из manifest-файла, из раздела «hooks». Если оно будет совпадать с тем, что было указано в add_executable, то к нему будет дописана цифра 2 (например, «cmake_test2»). Это вот хорошая конфигурация, если выбрать её — то проект будет пытаться запускаться на устройстве (или эмуляторе).

    Кстати, с библиотеками, собранными CMake, вас ждёт ещё один неприятный сюрприз: если вы вздумаете в пределах сессии IDE выстроить зависимости между либами и приложением, то ничего у вас не получится. Дело в том, что Ubuntu IDE для собранных библиотек попробует вызвать шаг Deploy (то бишь, Install в терминах CMake), и обломается, потому что у библиотеки, сюрприз-сюрприз, нет manifest.json (который ей нафиг не впёрся). Разработчики говорят, что такой способ использования IDE не предусмотрен, и, скорее всего, в этом плане ничего не изменится. Добавляйте библиотеки суб-проектами — тогда всё будет хорошо.

    По первому же странному поведению, мною заведён баг в багр-треккере Ubuntu IDE.


    «Плохая» конфигурация. Обратите внимание на парметры запуска — аргументы командной строки и рабочую папку. Это верный признак того, что IDE будет пытаться запускать ваш проект на десктопе вместо телефона! Не обращайте внимания на шаг «Deploy to Ubuntu Device» в списке шагов запуска — на устройство-то ваш пакет может и зальётся, но запускаться всё равно будет на десктопе.


    «Хорошая» конфигурация. Как видно, вместо коммандной строки и рабочей папки — совсем другие настройки.


    Как я раньше без этого жил?!


    Напоследок, ещё поделюсь трюком, который не имеет к Ubuntu Touch никакого отношения, но который я узнал только недавно, а хотел узнать — как минимум, год назад, если не больше. Порой, стоит задача слинковать приложение не с динамической, а со статической версией библиотеки. Конечно, у gcc есть флаг -static, но он не очень удобен (да ещё, по моему опыту, и не работает в каких-то случаях). Но оказывается, можно делать вот так:

    gcc yourprogram.o -ldynamiclib -l:libstaticLib.a

    В этом случае, первая библиотека будет взята та, которая есть (то есть, обычно динамическая), а вторая — строго статическая. Обратите внимание, что после двоеточия надо указывать ПОЛНОЕ ИМЯ файла, вместе с lib и .a!

    Этот трюк сработает в QMake-файле, а вот если вам хочется слинковаться со статической библиотекой в CMake, то просто надо в аргументах target_link_libraries написать не libname, а libname.a, и всё сработает автоматически.

    Заключение


    Разработка под Ubuntu Touch пока что полна сложностей и приключений. Единственный компонент системы, не доставивший мне хлопот, это Mir. Основные сложности представляет почти полное отсутствие документации и местами странное и непредсказуемое поведение IDE. Кроме того, постоянное обновление всего участвующего в разработке софта всегда имеет шанс что-нибудь сломать (например, у меня в течении дня был поломан chroot для сборки — но не совсем, а просто не мог обновиться; после выкатки фикса, пришлось его пересобрать, что есть большая трата времени).

    Помощь по проблемам, связанным с Ubuntu Touch и разработкой под неё можно получить по следующим каналам:

    AskUbuntu — StackOverflow для Убунту в целом. На вопросы про Touch отвечают, но мало и с большими задержками.

    Ubuntu Phone Mailing List — список рассылки для пользователей Ubuntu Touch. На вопросы разработчиков здесь почти никогда не отвечают, но если у вас что-то глючит в телефоне — то высока вероятность, что именно тут вам помогут.

    #ubuntu-app-devel IRC — IRC канал для общение разработчиков под Ubuntu Touch. Если вам удастся достучаться до кого-то из опытных разработчиков, например из Core Apps, то вам вполне могут помочь с вашими вопросами, но большую часть времени тут, как и в любом техническом IRC, стоит гробовая тишина, а вопросы «в воздух» игонрируются. Hint: не бойтесь использовать ключевое слов appdevs, чтобы захайлайтить разработчиков (см. тему канала)!

    Также, существует список рассылки для разработчиков, но он мёртв. На IRC есть и другие каналы, связанные с Ubuntu Touch, см. полный список на Вики.

    Что до меня, то я не уверен, что я буду заниматься разработкой под эту платформу за пределами портирования текущего проекта. Не потому, что мне не понравилось, но потому, что нет больше подходящих проектов, пока что. Тем не менее, у этого поста ещё может появиться продолжение — когда я разберусь с новым API для платежей Ubuntu Pay, с тем, почему у меня не работет звук, с проблемами сворачивания и разворачивания приложения и в целом доведу игру до состояния, близкого к релизу. Если, конечно, наберётся какого-то интересного материала.


    Ну, и напоследок, скриншот моего проекта, запущенного на устройстве. Как видно, мне пока не удалось убрать верхний барчик (в IRC говорят, что это баг текущей версии ОС)

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 25

      +1
      А насколько сильно она вообще распространилась? Какова рентабельность удобной разработки под нее? Или пока все еще выгоднее купить мак для яблок и потерпеть отладчик андройд студии?
        0
        У меня нет данных, но думаю, пока что распространение очень и очень узкое. Если даже Windows Phone, сумевший таки скушать несколько процентов рынка — и то считается нерентабельно платформой, то всякие проекты типа Ubuntu Phone, FireFox OS и т.п. не могут даже надеяться на рентабельность в ближайшее время. Поэтому основная причина разрабатывать под UT — энтузиазм и желание помочь реально открытой платформе.
        Впрочем, ещё может оказаться (об этом я расскажу как-нибудь после релиза :) ), что там хороший процент платящих пользователей. На основной работе у нас одно время доходы с Windows Phone не сильно уступали iOS и Android, несмотря на существенно меньшее количество игроков просто потому, что на WP была выше конверсия и средний чек.
          0
          Учитывая, что в Mozilla прекратили разработку Firefox OS, а каталог приложений будет работать только до 2017, довольно-таки вероятно, что и Ubuntu Phone постигнет та же участь. Canonical не сможет подобно Microsoft'у поддерживать нерентабельные и непопулярные проекты, пусть и хорошие по своей сути.
            0
            Всё может быть. В общем-то, я и не советовал сейчас кому-либо делать UT основной платформой :)
              +2
              Да не, вряд ли они отступятся. Это будет слишком громкое поражение, так же оно будет означать, что никто и никогда не сдвинет Android и iOS…
              А вообще, вектор развития Ubuntu сейчас как раз ориентировал на все девайсы, единая кодовая база, различные форм-факторы, одни и те же приложения на десктопе, телефоне, ТВ. Я думаю, что у них получится, ведь есть хороший приток денег от использования ОС в облаках. Проблемы, конечно, есть, но они все же фиксятся! Вот недавно за голову взялись и решили UI фреймворк переписать на C++, радует.
                +1
                А я вот болею за KDE Active…
                  0
                  У Jolla больше шансов, имхо, чем у UT. У них по крайней мере уже два поколения девайсов вышло.
                    0
                    Не скажу что больше, так как поставить UT можно на любой андроид девайс, да и девайсы, которые выходят на UT тоже появляются
                      0
                      Ещё посмотрим, что у Canonical получится с Convergence (я, честно говоря, плохо понимаю этот use case, но многие очень поддерживают идею планшета-оборотня, превращающегося при присоединении всякой периферии в десктоп), а также с запуском X11 приложений (libertine).
                        0
                        А где можно глянуть на девайсы UT? Я имею ввиду в продаже, а не концепты.
                    0
                    А что еще им останется делать? Поддерживать проект только как имиджевый? Или предвидится какой-то прорыв? Если честно, я вообще не представляю, как можно подвинуть Android и iOS, разве только в Google или Apple допустят ряд ошибок, и пользователи будут вынуждены искать альтернативу.
                  0
                  Так же на таких платформах (WP, Ubuntu Touch) очень низкая конкуренция
                    0
                    Тоже верно, кстати! Гораздо проще добиться хорошей видимости продукта, не надо сражаться с миллионом клонов. Хотя, на WP волна китайских поделок тоже поднимались одно время (сейчас не знаю, не слежу особенно).
                0
                На мой взгляд, существенным минусом Click-пакетов по сравнению с IPA или APK является то, что он — не ZIP, а что-то своё, хитрое.

                The top-level binary format for Click packages is an ar archive containing control and data tar archives, as for .deb packages: see deb(5) for full details.
                  0
                  Это хорошо, но по кнопке Enter в mc не открывается и по F3 не просматривается :)
                    0
                    Любопытный способ определения типа файла) Рекомендую попробовать file. Это гораздо более информативно и надежнее.
                      0
                      Это не способ определения типа, это способ просмотра содержимого. Я-то знаю, конечно, что можно в консоли click contents packagname.click набрать… Но не хочу :) Я не тру-Линуксоид, и люблю двухпанельные файловые менеджеры, а не консоль, и просмотр архивов прямо в них.
                  0
                  Происходит нечто странное, если не прав, поправьте:
                  1. Они выпустили этот дистрибутив как достаточно не универсальный в плане платформ, заточенный под конкретные девайсы, только ARM
                  2. Получается, что у него нет инсталлера и его нельзя установить на обычный x86 планшет или комп и использовать для тестов.
                  3. Нужно купить конкретный ARM планшет и путем некоторых манипуляций вшить туда этот дистрибутив.
                  4. Здесь достаточно странный рабочий стол, не признанный и спорный так сказать.
                  5. Как уже было сказано — используется свой тип пакетов.
                  6. Экосистема почти ноль и к тому же, видимо, вследствие отличия типов пакета и другого рабочего стола многие полезные вещи тоже будут недоступны из репозитария.
                    0
                    1. Не исследовал вопрос детально, но вроде бы проблем собрать под x86 нет, и вроде бы я видел где-то сборку под Virtual Box.
                    2. Инсталлера "на что угодно" нет и быть не может, в силу того, что поддержка каждого конкретного устройства требует наличия драйверов под него. Драйвера можно использовать от Андроида благодаря libhubris, но это не автоматический процесс, их придётся выковыривать руками, и плюс учитывать всякие особенности устройства. Имеется гайд по портированию на новые устройства: https://developer.ubuntu.com/en/start/ubuntu-for-devices/porting-new-device/ А для "потестить" есть эмуляторы (x86 и arm) (http://askubuntu.com/questions/259338/is-there-an-ubuntu-touch-emulator-or-a-way-to-install-it-in-a-vm)
                    3. Можно купить ARM-планшет с уже установленным дистрибутивом (доступная модель пока одна). Если хочется большего — то да, вшить дистрибутив самому (но см. п.2 про драйвера)
                    4. В смысле, Unity? Вроде бы, в десктопной Убунте он уже давно и прочно. А если имеется в виду Mir, то проект libertine может всё спасти :)
                    5. (и 6) Ну, вообще говоря, deb-пакеты поддерживаются, из терминала можно сделать apt-get. Click — это формат для распространения софта через местный AppStore. Но это (apt-get) больше касается библиотек и консольных утилит, конечно. С другой стороны, насколько я понимаю, планируется, что в скором времени можно будет запускать X11-приложения при помощи библиотеки libertine. На телефоне, да и на просто планшете это почти не актуально (идиомы интерфейса слишком разные, чтобы было удобно), а вот на планшете в режиме Convergence с подключённым внешним монитором и мышью — может оказаться рабочим вариантом.
                    0
                    Все мысли озвучены в контексте — разработка+разворачивание+юзабилити.
                    Когда вы ставите виндовс, вы не задумываетесь о развертывании на большинстве установок. Ваш инструмент — инсталлер. Вы уверены в нем.
                    В ubuntu touch этого нет. Возьмите к примеру android x86, проект, с достаточно уже успешным так сказать инсталлером. Значительно число платформ можно заставить работать с помощью дистрибутива с этого сайта.
                    Сейчас в плане развертывания внезапно ubuntu touch отстала даже андроида. Как так? Вендоры так и будут пилить, ковырять, делать это всегда несколько разным образом и в итоге делать сложным в поддержке. Куда тогда направлена стратегия ubuntu touch? Я всегда полагал, что если и появится native linux based mobile platform, то она должна бить в самые больные места конкурентов.
                      0
                      Ну, не может же инсталлер появиться как Афина из головы Зевса, в один момент и полностью сформированным :) Я не знаю, честно говоря, как работает abdroid-x86 — откуда он берёт драйверы, кто поддерживает костыли, позволяющие работать на разных устройствах, но полагаю, что это вопрос долгой работы сообщества, постепенно набиравшего обороты.
                      За стратегию Canonical я ничего не скажу, так как не являюсь их работником, и тем более топ-менеджером, но полагаю, что они так же надеются привлечь заинтересованных разработчиков, которые помогут написать драйвера под разные устройства, и таким образом постепенно расширять охват. В конце концов, на десктопном Линуксе тоже раньше очень не хватало дров — по той же самой причине, вендоры их не писали, а опен-сорс разработчиков на весь адский зоопарк железа не хватало.
                      А основным "больным местом" конкурентов, на мой взгляд, являются ужасные АппСторы, в которых ужасный discoverability, но которым нет альтернативы (особенно на iOS/Windows Phone, но и на Android тоже). Ничем, кроме этого, их не пронять — на открытость системы наплевать всем, кроме кучки гиков, на удобство использования, как показывает опыт ранних версий Android — тоже. В плане цены, Ubuntu Touch тоже не победит — Android не повышает цену устройств настолько, чтобы то же железо с UT могло быть дешевле. Одна надежда на то, что как раз открытость альтернативных платформ позволит породить какие-то лучшие варианты AppStore, которые позволяют одной из них, наконец, откусить рынок.
                      +1
                      в Virtual Box всё это работает очень плохо — например, окно QtCreator'a всегда находится поверх любых других окон.
                      Xubunt 15.10 c Qt 5.6.0 — QtCreator прекрасно работает в VirtualBox включая OpenGL, кросскомпиляторы, GDBServer/GDB и все остальные плюшки. Кроме того никто не мешает прикрутить какой-нибудь linaro+rootfs целевой машины к QtCreatorу под форточки, что я и делаю, когда пишу под малину.

                        0
                        Хм, возможно, дело в Xfce вместо Unity — у меня глючила именно обычная Убунта.
                        А вот решение с linaro+rootfs — это для меня что-то новое, я даже не слышал о таком. Однако, полагаю, на пути его использования меня ждёт чуть больше боли — ведь плагин Ubuntu под Windows-версию QtCreator, не факт, что соберётся под Винду, а без него — не будет управления Kit'ами и автоматической сборки click-пакетов. Впрочем, можно попробовать как-нибудь на досуге.
                          0
                          Если у Вас в свойствах виртуалки стоит флажок «Включить 3D-ускорение», а на хосте видеокарта NV, креатор вываливается. Тут, либо снимать этот флажок, либо в креаторе снять флажок «Справка->О модулях->Welcome». Во втором случае Вы не сможете на хосте пользовать QML/OpenGL, но для сборки и запуска на целевой системы это не важно.

                      Only users with full accounts can post comments. Log in, please.