Увидел сегодня в ленте статью и вспомнил, что хотел ведь про свой проект пару строк на Хабр написать.

В общем, некоторое время я работал техлидом с программистами iOS/Android, которые много использовали в своем коде API на Django/Yii2/проприетарщине. И посмотрев со стороны на инструменты, имеющиеся у них для работы с REST API, я решил нечто подобное добавить и в Qt, т.к. нормальных средств по работе с REST с использованием Qt моделей не существовало.

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

Привет.

Хочу поделиться простым способом оптимизации своего рабочего времени при разработке QML приложений под Android/iOS/Embedded.

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

Суть проблемы — при разработке, отладке или прототипировании любого мобильного приложения на любом языке мы как правило всегда проходим одни и те же этапы: правка кода, деплой, запуск. И так до бесконечности. В случае с мобильной разработкой, этап деплоя кода может растянуться на внушительное время — от 2 до 10 минут, в течение которого заниматься в общем-то нечем. Возможно для кого-то это и хорошо, но точно не для тех, кто ценит своё время. В общем, думаю, не только меня выбешивает такое положение вещей ;-)

Ситуация усугубляется для нативных средств разработки, к примеру, под Android, где нам всегда, без вариантов нужно перекомпилировать Java-код перед следующим запуском на устройстве.

Qt на первый взгляд обладает той же проблемой — каждый новый билд проекта также деплоится на устройство продолжительное время. Вот только есть одна особенность — мы ведь можем писать приложения не на Qt/C++, а на чистом QML. В этом случае, если мы не меняем логику в C++ части приложения, нам ничего не нужно компилировать под целевую платформу. А значит — было бы круто просто обновлять набор qml файлов приложения и перезапускать приложение на устройстве. Ведь экономия времени на 10 запусков составила бы не менее часа!

Ну что ж, раз есть потенциальная возможность — грех ею не воспользоваться. Читайте под катом, что у меня получилось.

Привет.

Вкратце. Не так давно на хабре была статья о скрещивании AdMob и Qt путём реализации кроссплатформенной библиотеки. Вот только не было там возможности интегрировать библиотеку с QML приложением. Недавно, решив встроить AdMob в своё небольшое новое Qt Quick приложение, я столкнулся с этой проблемой и реализовал небольшую обёртку. Но, так как я решил встроить рекламу, то мне понадобилась и аналитика.

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

Но вдруг я наткнулся на интересный cross-promoution сервис — StartAd.mobi. Его суть в том, что в первый месяц сеть бесплатно даёт тебе в разы больше трафика, чем приводишь ты. Стало интересно, внедрил и этот сервис в проект для того чтобы проверить статистику и попытать счастья.

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

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

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

Так родился AdCtl.

Под катом я расскажу о деталях реализации библиотеки и приведу примеры её внедрения в свой собственный проект.

Привет.

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

Зачем это может понадобиться? Например — если вы разрабатываете приложение, в котором несколько людей должны работать в рамках одной группы над каким-либо проектом. Это может быть к примеру учебное расписание, которое может редактировать несколько людей или каталог продукции Интернет-магазина компании.

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

Итак, наш пример будет уметь:
1) Отображать интерфейс приглашений включая список существующих приглашений и форму для отправки нового;
2) Сохранять все приглашения в базе данных;
3) Следить за статусами приглашений;
4) Отправлять приглашения на email;
5) Следить за ролями пользователей;
6) Активировать приглашения новых пользователей;
7) Использовать кучу сторонних модулей.

Внимание: Пример будет рассмотрен на основании живого проекта, так что просто скопировать и вставить его к себе, вероятно, не получится…

Привет.

Хочу поделиться небольшим модулем, предназначенным для создания страницы настроек в своём приложении. А заодно узнать у сообщества, что в нём можно было бы улучшить.

Задача по своей идее простая — сделать табличку в БД, хранящую параметры типа «ключ -> значение», а к ней сделать страничку редактирования, позволяющую изменять данные значения. ну и конечно же реализовать программный интерфейс для доступа к параметрам хранимым в БД.

Срок реализации — около получаса. В интернете почему-то готового решения было не найти. Исправим положение, авось кому пригодится.

Как-то эта замечательная новость обошла Хабр стороной, тем не менее, я считаю что она заслуживает внимания.

Посты-ссылки отменили, так что процитирую новость здесь, надеюсь никто не против.

В рамках Qt Developer Days компанией Digia, которая с сентября 2012 года полностью отвечает за Qt Framework, был намечен ряд амбициозных задач по развитию продукта. Старший вице-президент Digia Tommi Laitinen и глава Qt Digia и Qt Project Lars Knoll изложили стратегию и план действий, направленных на то, чтобы Qt стал ведущей в мире кросс-платформенной средой разработки в течение пяти лет.

Этот пост является продолжением данной (в переводе) статьи.

В предыдущем посте мы рассмотрели, как движок QML загружает файлы. Напомню, что сначала QML-файлы разбираются парсером, затем компилируются в промежуточный байт-код и наконец следуя инструкция байт-кода, для каждого эемента в каждом QML-файле создаётся C++ объект. Например, мы видели, что когда QML файл содержит элемент Text, то движок создает экземпляр C++ класса QQuickText.

На самом деле, загрузка файлов — это почти всё, чем занимается движок QML. После загрузки, он перестаёт вмешиваться в процесс работы приложения. Обработка событий и отрисовка элементов в Runtime полностью ложится на плечи C++. Например, элемент TextInput обрабатывает события вроде QQuickTextInput::keyPressEvent() и обновления QQuickTextInput::updatePaintNode(), без участия движка QML.

Но существуют две важные вещи, на которые движок QML всё же влияет во время выполнения: Связанные обработчики сигналов (Bound signal handlers) и обновление привязок свойств (property binding). Связанные обработчики сигналов — это такие вещи, как onClicked обработчик для MouseArea. Сегодня же мы рассмотрим привязки (Bindings).

В этой (2 часть в переводе) серии статей мы заглянем под капот движка QML и раскроем некоторые из особенностей его внутренней работы.Статьи основаны на Qt5 версия QtQuick, QtQuick 2.0.

Большинство людей знают, что каждый элемент в QML файле опирается на конкретный C++ класс. Когда QML файл загружен, движок QML как-то создает один C++ объект для всех элементов в файле. В этом посте мы рассмотрим, как движок QML переходит от чтения текстового файла, включающего полное дерево C++ объектов. В документации Qt присутствует раздел с обширным описанием взаимодействия QML и C++, прочтение которого стоит потраченного времени. В данной серии статей, я предполагаю что пользователь прочёл и понимает описанное в документации.

За последние месяцев 20 я написал немало постов о Qt5, QML Scene Graph, шейдерах и многом другом. Сейчас, когда бета-версия Qt5 уже на подходе, я думаю что пора показать очередное технологическое демо. Оно называется 'Cinematic Experience' и выглядит следующим образом:

Одним из недостатков Qt Quick API является то, что хоть рендеринг и выполняется в выделенном потоке, тем не менее наша анимация всегда работает в потоке графического интерфейса пользователя.

Запуск же анимации за пределами основного потока приложения имеет то преимущество, что значительно снижает влияние ресурсоёмких задач на анимацию, которые обычно блокируют основной поток и приводят к задержкам анимации.

Существуют три основные проблемы, препятствующие нам вынести анимацию в отдельный поток:

• Анимация обновляющаяся при изменении свойств. Свойства являются частью QObject и системы мета-объектов. Чтобы избежать безумия с потоками, нам разрешается лишь читать и писать эти свойства в потоке графического интерфейса пользователя.
• Свойства часто имеют привязки и связи в QML, которые вызывают JavaScript-код, при наступлении неких событий, который также должен выполняться в потоке GUI.
• Цикл рендера в библиотеке QtQuick завязан на поток GUI, а следовательно, когда данный поток заблокирован, анимация не обновляется.

Предисловие

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

Введение

Это заметка, в которой я хотел бы немного описать архитектуру и систему расширений среды разработки Qt Creator. Изначально, я предполагал лишь перевести документ Writing-Qt-Cretor-plugins.pdf, но так уж вышло, что развитие Qt Creator не стоит на месте и во первых, данный документ уже не столь актуален (сам устарел, API поменялось, куски кода не полные и часто не работают), а во вторых со времени его написания появлись дополнительные возможности расширения Qt Creator, которые хотелось бы описать.

Тем не менее, не будь этого документа, не было бы и данной заметки: из него я взял очень много, вплоть до структуры поста, при этом постаравшись где-то что-то выкидывая/заменяя/добавляя сделать пост актуальным для последней на текущий момент времени версии Qt Creator 2.4.0.

Кому может быть полезен данный документ? В первую очередь это конечно же Qt-программисты, которые выбрали данную IDE как основную среду разработки.

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

Итак, что же нас ожидает под катом (жирным отмечены готовые разделы):

1. Сборка Qt Creator
2. Первое расширение
3. Добавление новых меню и пунктов меню
4. Архитектура Qt Creator
5. Добавление нового редактора (Editor)
6. Добавление боковой навигационной панели
7. Добавление страницы в диалог настроек
8. Добавление фильтра в диалог поиска
9. Добавление нового типа проекта

Напомню, что Qt Creator является кросс-платформенной свободной IDE для работы с фреймворком Qt, разработанной Trolltech (Nokia). Что не мешает сделать из него простой текстовый редактор с подсветкой синтаксиса, простым отключением всех расширений. Внимание, сотни картинок!

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

В своё время, Qt4 была разделена на несколько модулей, что в частности позволило создавать приложения, не требующих графического интерфейса. Благодаря сильной фокусировке на архитектуре встраиваемых систем и нескольким здравомыслящим решениям в области архитектуры, Qt5 вывела данный подход на новый уровень.

Давайте посмотрим на простую функцию:

QCoreApplication app(argc, argv);
QTimer::singleShot(3000, &app, SLOT(quit()));
return app.exec();

Это Qt-приложение, не имеющее графического интерфейса. Оно работает 3 секунды и затем завершается.

От переводчика: не пинайте, ждал пока кто-либо переведёт эту новость, но данного события так и не случилось, а обсудить очень хочется.

Вслед за недавним объявлением, о полном приобретении Qt у Nokia, Digia изложила свои дальнейшие планы в письме к сообществу KDE.

Директор R&D департамента Digia, Tuukka Turunen заявил, что видит будущее Qt, как лучшей кросс-платформенной среды разработки и желает наладить более тесное сотрудничество с KDE и другими партнерами в экосистеме Qt.

Полный текст письма приводится ниже.

 

Привет!

Откровенно говоря, я не знаю, один ли я в своей беде, но за долгое время использования Google Reader в качестве RSS-читалки, мне изрядно надоела непропорциональная ширина кнопки «Подписаться» и всплывающего по её нажатии блока. Казалось бы, всё это фигня, но глаз мозолит очень сильно.

А что ещё прискорбнее, этот баг из старой версии ридера, переехал в новую. Да и вообще, у меня закрадываются подозрения, что я один кто с ним столкнулся…

Короче говоря, вот она, проблема:

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

Тем не менее, от того, что пост был хреновым, само приложение хуже не стало. Хоть и на некоторое время было отложено в долгий ящик. Вчера вечером, я как-то мельком проглядывал блог ребят из Сutehacks, компании, занимающейся разработкой Qt приложений и старающихся сделать на этом денежку. Так вот, просматривая блог, я наткнулся на пост, в конце которого была презентация под названием «Targeting Android with Qt».

В этой презентации, помимо каких-то абстрактных мыслей, разработчики подробно объяснили, какие шаги необходимо сделать для того, чтобы портировать своё приложение на новую платформу, а затем и загрузить его в Android Market. Здесь я хочу вкратце перечислить эти этапы, а всю дополнительную информацию желающие смогут получить из оригинальной презентации на Slide Share.

Этот пост участвует в конкурсе „Умные телефоны за умные посты“

Введение

Не секрет, что с появлением HTML5, фокус разработки постепенно стал смещаться в сторону Web. Это и простые Web-сайты и динамические приложения и даже мобильные приложения, целиком и полностью написанные с использованием HTML5. Независящие от платформы и среды исполнения и требующие лишь беспрекословного выполнения стандартов. Но тем не менее, как бы ни был хорош весь стек технологий привнесённых новыми стандартами HTML, всё ещё остаются некоторые задачи, для решения которых необходимо использовать нативные средства разработки.

Такими проблемами к примеру, является получение доступа к системной информации, управление и изменение чего-либо в системе. Доступ из HTML5 к контактам, календарю, органайзеру на мобильном устройстве и другие. Опять же, если наше приложение производит какие-то серьёзные вычисления, то их можно перенести с медленного JS на быстрый C++. В данной статье хочу рассмотреть несколько техник взаимодействия Web-приложения и нативного кода на примере модуля QtWebKit, которые могут оказаться полезными.

Этот пост участвует в конкурсе „Умные телефоны за умные посты“

Даже не смотря на то, что многие программисты, в данный момент, не спешат переводить разработку своих приложений и игр на рельсы Qt Quick, инфраструктура вокруг самой технологии с каждым днём лишь растёт и развивается.

Вот и до симуляции физики в двухмерном пространстве дошло дело. А вернее до появления QML-плагина. который позволяет с присущей Qt Quick легкостью интегрировать в своё приложения физический движок Box2D. Вот об этом сегодня и поговорим. А точнее, разберём на примере реализации простого арканоида, насколько быстро можно создать простенькую игру, никогда ранее не работая с физическими движками и почти незная терминологии.

 

Предыстория

Все мы любим послушать музыку. Все мы для этого пользуемся устройствами/приложениями для её прослушивания. У кого-то это Winamp или стандартный медиа-плеер Windows, а у кого-то плеер на мобильном телефоне или вовсе отдельный mp3-шник.