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

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

Нам стало интересно, насколько реально исправить эту ситуацию с помощью VK API, и вот, что из этого вышло:

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

Технология взрослела, разработчики лечили детские болезни, но для полного счастья не хватало трех вещей:

• Правильного масштабирования на High DPI экранах
• Компонентов, специфичных для смартфонов
• Гибкой стилизации имеющихся компонентов

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

С отсутствием компонентов решалось тоже просто, но трудоемко: велосипедами. Надо заметить, что в последнее время появилось несколько приличных пользовательских наборов, под Android, Material, iOS. Для меня до сих пор загадка, почему Digia при всей ориентированности на мобильники выпустили первую версию контролов под настольные платформы, где и виджеты себя чувствуют неплохо.

Полтора года назад появился стандартный стиль имитирующий Android 4.x — ситуацию это не спасло. Стилизация у Qt Quick Controls 1 недостаточно гибкая, в общем опять велосипеды, благо пишутся они довольно просто, и почти все нужное уже написано в предыдущем пункте.

В общем до 5.6* была печалька, а теперь и на нашей улице праздник

*В Qt 5.6 новые контролы представлены в качестве технологического превью под именем Qt Labs Controls, полноценно запустятся в ближайшем релизе 5.7, который обещают в июне.

Можно ли написать обыкновенное мобильное приложение на Qt Quick? Не игру, а именно традиционное приложение? Если полгода назад у меня были серьезные сомнения в осуществимости этого предприятия, то теперь сомнений не осталось — можно!

Конечно, на этом пути поджидало (и поджидает) множество проблем, большинство из которых описано тут. На данный момент накопилось уже приличное количество наработок, надеюсь эта статья положит начало циклу по систематизации и документированию опыта. Начнем с чего-нибудь простого и нужного, а именно с виджета выбора цифрового значения, по английски именуемого Picker. Такой используется в Android, когда нужно ввести дату, время, или какое-нибудь специфическое значение.

Привет!

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

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

Итак, давайте посмотрим, что нового в этом релизе:

В процессе написания мобильной версии органайзера на QML у меня появился вопрос: можно ли построить такую непротиворечивую модель навигации, которая могла бы с минимальными изменениями подстраиваться под обе основные платформы. То есть которая соответствовала бы HIG, была привычна пользователям, и не вызывала отторжения, чем страдают многие кроссплатформенные программы. Был произведен анализ основных приемов организации экранов на обоих платформах, на основании чего появилась модель, которой хочу поделиться.

Многие разработчики хотят выпускать свои приложения под несколько платформ. Если вы планируете адаптировать программу под Android, нужно учитывать, что разные платформы придерживаются разных правил оформления и поведения. Визуальные решения, идеально вписывающиеся в окружение одной ОС, могут выглядеть чужеродными на другой. Несомненно, подход «один дизайн — много платформ» может сэкономить приличное количество времени, но при этом нужно понимать, что приложение наверняка получится чужеродным, что может оттолкнуть пользователей. Следующие приемы помогут вам избежать наиболее частых ловушек и подводных камней.

Представим на минуту, что существует простая технология, позволяющая писать мобильные приложения под все платформы сразу. Без проблем с производительностью, с легким доступом к железу на низком уровне. Бесплатно*. Приложения выглядят почти как родные. Ведут себя как родные. Просто мечта, а не технология! «Так не бывает» — скажете вы. И будете правы. Почти. Но у сообщества есть отличный шанс изменить ситуацию, благо все предпосылки для этого есть. Если интересно, что уже сделано, и что еще предстоит — прошу под кат.

* Печалит только юридическая неопределенность при статической линковке (LGPL), обязательной, например, под iOS

Сборка дистрибутива — завершающий этап подготовки программы к выходу в свет. К сожалению, ни о какой стандартизации в этой области речи не идет, более того, на некоторых ОС (не будем показывать пальцем), так вообще целый зоопарк форматов.

Итак, в идеале нам нужны дистрибутивы:

• Windows
• OS X (.dmg)
• OS X (.pkg — App Store)
• Linux (.deb)
• Linux (.rpm)
• Linux (.tar.gz — universal)

После завершения разработки под OS X может остаться ощущение незавершенности — для полного счастья хотелось бы видеть свое приложение в каталоге, тем более, что это, пожалуй, лучшая площадка для продажи десктопных приложений. На эту тему есть статья времен Qt 4.8 в официальном блоге, и еще более старая на хабре. К счастью, больше нет необходимости пересобирать Qt, однако с приходом OS X 10.9 некоторые баги стали критичными, приходится выкручиваться.

Сегодня я хотел бы рассмотреть вопрос кастомизации интерфейса программ на Qt. Основным вариантом является использование Qt Style Sheets. Как становится очевидно из названия, это немного специфичный аналог привычных всем каскадных таблиц стилей (CSS2), без которых немыслим современный интернет. QSS чаще всего применяются для двух вещей: либо доточить какой-нибудь виджет до более родного вида, либо наоборот, сделать интерфейс более нарядным, выделяющимся, возможно одинаковым на всех платформах.


На скриншоте приведен один из диалогов нашего органайзера для студентов, весь интерфейс которого реализован на QSS.

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

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

	16	32	48	64	128	256	512	1024
OS X*	*	*		*	*	*	*	*
Linux	*	*	*	*	*
Windows	*	*	*			*

Qt — по-настоящему замечательная библиотека, позволяющая перенести программу на другую операционную систему простой перекомпиляцией. И если разработчик не использовал чего-нибудь ОС-специфичного, она таки будет выглядеть и работать почти как родная. После разработки основного функционала, при которой различия минимальны, наступает стадия полировки и доводки — об этом и будет рассказывать настоящий цикл статей.

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

Все началось на втором курсе, во времена, когда человеческие планшеты только начали появляться, а Android был еще во второй ветке. Я тогда был большим поклонником гибкости и настраиваемости linux-систем, потому и неудивительно, что появилась мысль написать свое окружение рабочего стола, позволяющее запускать несколько приложений одновременно, но при этом адаптированное для небольших сенсорных экранов. Эту идею разделял один мой одногруппник(Кирилл), имевший уже к тому моменту некоторый опыт в разработке на OpenGL.

Планирование — самая захватывающая часть в разработке ПО, а в такой масштабной задаче оно приятно затянулось аж на целый месяц. Хотя стоит признать, что выбор названия занял приличную часть времени. Было принято решение написать сначала свой 2.5D движок, а после доработать его до полноценного композитного менеджера окон. Тащить какой-нибудь тулкит нам показалось излишеством, потому подразумевалось, что панели и меню будут использовать тот же движок для отрисовки( как это сделано в Unity, насколько я понимаю ). Велосипедить свои файловый менеджер и плеер было бы неразумно, да и, раз уж мы независимы от тулкитов, пусть каждый использует то, что ему ближе. Программ, адаптированных для сенсорных экранов практически не было, потому планировалось после релиза начать работу по адаптации GUI некоторых популярных проектов, поддерживать соответствующий репозиторий.