Чего-то зачесалось у меня в старые игрушки поиграть. Но быстрый поиск показал, что фиг вам там. Либо надо ставить эмуляторы и искать образы, либо идти и платить непонятно за что с каким качеством (у меня до сих пор в голове свежи воспоминания, как угробили pac-man, mario и boulder dash).
Ну если оно не получается, то почему бы не взять и не написать самому? В тех играх не ни графики, ни звука, ни работ на 100500 мульонов денег. А интерес-то тот же …
В общем, отряхнул я руки и за пол-дня написал первую игру: Пинг-Понг.
Получилась простая и тупая до безобразия игрушка. Но по-прежнему захватывает и дальше 20 я уйти не смог 🙂
Что первым делом должна делать программа для учета личных финансов? Конечно, показывать нам эти самые финансы. Или говоря другими словами, показывать состояние счета и транзакции по нему.
Счета у нас внутри базы представляют собой классическое дерево, где у каждой веточки есть свой id и id ветки, из которой она растет. Или id и parent_id. Если parent_id=0, то считаем, что этот счет “корневой” и находится на самом верху.
Методов отображения таких деревьев – уйма. Но я на свою голову решил попробовать применить QTreeView. Обложился документацией, нашел парочку хороших статей на хабре … Казалось бы, бери и делай.
Но фигу. QTreeView в Qt – один из немногих компонентов, который сделан “наотъебись”. Практически нулевая документация, какие-то шаманские пляски для выполнения тривиальнейших вещей и так далее и тому подобное. А практически все примеры в интернете написаны в духе “это просто, берем готовую модель и вуаля!”. А как работает эта модель и почему надо это делать так – ноль.
В общем, потратив впустую пару дней с этими морделями, я плюнул на эту хренотень, взял обычный QTreeWidget и банальным рекурсивным поиском заполнил виджет. На всякие заморочки со скоростью я решил начихать, ибо я не верю, что у обычного пользователя будет больше 100-200 счетов, а на этом уровне сходится все. На тестах виджет вполне нормально крутил 10000 счетов без каких-либо пожираний памяти или тормозов процессора.
Что касается размазывания логики по коду, то вроде этого удалось избежать. Все необходимое уместилось в одном классе. В общем, с моделью тут гораздо больше мороки и код получается гораздо более нечитаемым и не поддерживаемым.
Из того, что не было в предыдущих стадиях так это только то, что добавилась синхронизация таблички rate, в которой хранятся курсы валют. Тут же всплыла проблема: при синхронизации на немощных компьютерах программа сваливается в Application Not Responding. Надо будет куда-нибудь в синхронизацию воткнуть вызов диспетчера очередей. Сменить алгоритм не предлагать, ибо потом некоторые таблички будут расти и расти …
А вот с окошком отображения транзакций получилось все как по книжкам. Там обычная плоская таблица, поэтому QSqlTableModel пришлась впору. И так как документации, примеров и прочего на порядок больше, то и проблем никаких не было. Почти, но об этом позже.
Через некоторое время я переехал на QSqlRelationalTableModel по одной простой причине: у каждой транзакции есть currency_id, которое отвечает за валюту, в которой сделана транзакция. И что бы не мучаться, проще заставить модельку саму выбирать с помощью join нужные значения из таблицы currency.
Во всем этом великолепии меня поджидало только две засады.
Первая заключалась в именах таблиц. Все-таки transaction является ключевым словом и просто так qtшный sql не хотел использовать эту таблицу. Попытка заэскепить имя таблицы как [transaction] не увенчалась успехом. Но на мою радость оказалось, что “transaction” вполне себе хороший идентификатор для qt.
Вторая заключалась в том, что поле для join задается его порядковым номером. То есть мне надо считать, под каким порядковым номером выводится нужное мне поле и задавать его. А функции типа findColumn(name) я не нашел. Можно конечно поизвращаться самому (db.tables никто не отменял), но пока оставлю в качестве todo на будущее.
Наконец, сделал последний штрих: заставил выводить только те транзакции, которые относятся к выделенному счету. Мелочь через setfilter.
В принципе, максимально минимальный клиент готов. Он умеет логиниться и показывать необходимое. Да, коряво, да, даже без капельки дизайна, но умеет.
Что следующее? А следующим будет причесывание внешнего вида и начало эпопеи по разработке интерфейса. Например, надо сделать так, что бы на планшетах, десктопах и телефонах в ландшафтной ориентации отображалось как “счета-транзакции”. А вот на телефонах в портретной ориентации надо выводить “счета”, при тапе на счете выводить отдельное окно с транзакциями. И реализовать “назад”.
И тулбарчик на андроидах сверху, а на айфонах снизу! И еще ..
Короче, в следующей серии будет гламуризация полученного.
Как ни обидно будет читать некоторым, но мне пришлось отказаться от QML. Слишком сырая штука для подобных проектов. Во-первых, делать связку между C++ и QMLной частью – это еще тот секс, а без подобных связок никак. Во-вторых, отсутствие нормальных layout менеджеров ставит полностью крест на кросс-платформенной разработке. Это я понял после того, как для странички логина у меня получился огромный и безформенный кусок спагетти, отвечающий за положение элементов в разных средах и формах. И наконец, вся эта машинерия у меня внезапно сглючила. Например, у меня поля ввода перестали убирать при вводе placeholder и стали оставлять после себя артефакты. И это даже при использовании специальной “чистой” сборочной виртуалки. И под виндовсом и под OS X.
В общем, плюнул я на борьбу с мельницами и вернулся к обкатанным QWidgets.
Сейчас в Stage2 реализовано следующее:
Желтеньким выделено реализованное. Белое я оставил, ибо после размышления я решил, что нефиг этому функционалу делать на окне логина. За кадром остался функционал работы с сетью, базами данных и синхронизацией.
И что больше всего радует, на всех платформах оно работает! И работает довольно шустренько. К примеру, скорость процесса синхронизации не сильно отличается от десктопной.
Что вскрылось в процессе написания и что может быть вам полезно.
Во-первых, забудьте про всякие QDialog и все связанное с ним (QMessageBox и теде). Только QMainWindow для всего. Причина простая – на андроиде и айпаде окошко зажимается в левом верхнем углу и никак его оттуда не вытащить без трахтибидоханья. QMainWindow ведет себя гораздо более приличней и плюс позволяет с собой поделать всякие кунштюки типа сохранения координат-размеров. Да, придется немного помучаться, зато потом оно летает без геморроя.
Во-вторых, вам придется переопределить все методы show и вручную написать для каждого элемента что-то типа ui->element->adjustSize(); без них вы на мобильных платформах с большим dpi получите малюсенькие элементы управления, в которых будут проглядывать надписи.
И наконец, забудьте про пикселы и прочие ldpi. Все в платформонезависимых единицах, типа пунктов для шрифтов. Всякие кнопки и прочие элементы управления – загоняйте в layout. Отдайте это на откуп Qt – у него очень неплохо получается.
Как обычно, полученное доступно тут. Дизайну ноль, зато весь функционал работает.
Теперь пора переходить к главному окну приложения. Но это в следующих постах.
Что-то я давно не описывал процесс разработки. Итак, на предыдущем шаге у нас получилось окошко, которое умеет изменять как положение своих элементов, так и их пропорции при запуске на разных платформах.
Я позапускал приложение на всех доступных мне устройствах и вынужден сказать, что Qt 5.2 вполне справляется со своими обязанностями. Приложение запускается, крутится и вообще ведет себя как взрослое.
Но сразу же выяснилось, что просто так использовать правила “размер в 1/10 экрана” нельзя. Иначе на устройствах с большим экраном (iPad или 27″ монитор) элементы управления начинают напоминать игрушечные: такие же больше и аляповатые. В общем, необходимо размеры некоторых элементов привязать к реальному размеру.
Qt тут помогает. В нем есть Screen.pixelDensity (берем из QtQuick.Window 2.1), который говорит о числе точек экрана на миллиметр. И если нам нужен размер чего-то в сантиметр, то просто ставим Screen.pixelDensity*10 и проблема исчезает.
В том же Screen есть width и height, только они вовсе не про размер экрана. Они описывают размеры прямоугольника, который доступен приложению. За этим прямоугольником располагаются всякие строки статуса, таскбары и прочая системная мишура. Поэтому использовать те же переменные из Window вообще-то не правильно.
Но я отвлекся. Итак, у нас есть формочка с двумя полями ввода, чекбоксом и кнопкой “войти”. Как все это дело обрабатывать? Ну что бы было удобно пользователю и программа не мозолила ему мозги со всякой дрянью?
Берем первый попавшийся под руку Visio и подумав, рисуем вот такенную блок схему. Если чего, то картинка кликабельна.
Вот такая вот небольшая схемка, которая показывает логику приложения от запуска до появления основного окна.
Что я преследовал, рисуя кучу этих линий?
– Если пользователь поставил галочку “запомнить меня”, приложение должно запускаться без каких-либо вопросов, запросов и прочего. Всякие блокировки оставим операционной системе.
– Однако пользователь может быть немного параноидальным и не хочет, что бы кто-то, кто имеет право пользоваться телефоном (ребенок к примеру), что-то там понатыкал. Защита обычным пин-кодом.
– Если пользователь специально на каком-то устройстве снял галочку “запомни меня”, засинхронизировался и перелогинился, то все остальные устройства при первом же подключении к сети должны заново запросить пароль и засинхронизироваться заново. Это защита от утери устройства/утечки токена.
– Ну и устройство не должно при обычной работе лезть в интернет за синхронизацией, если пользователь не разрешил. Говоря другими словами, настройки “синхронизироваться только через wifi” и “синхронизироваться только вручную”.
Скорей, надо скорей писать код! Как театр начинается с вешалки, так и любой клиент ВсёМоё начинается с окошка логина. Надо его нарисовать!
Для начала выдираем скриншотом, прямо из эмулятора, работащий логин.
В оригинале всё, кроме полей ввода и чекбокса, нарисовано прямо на бэкграунде. С одной стороны, это хорошо и уменьшает объем кода. А с другой стороны, ограничивает нарисованным. А ведь охота нарисовать сразу для всех платформ. Ну или практически для всех …
Разбиваем окошко на следующие элементы: бэкграунд, “банка”, логотип, и два поля ввода. Для десктопа еще должна добавиться кнопка “Войти”, ибо на мобильных её функцию выполняет кнопка на виртуальной клавиатуре. Кнопку “регистрация” … а нехай будет
В общем, как-то так получается в реальности.
Берем Qt Creator и создаем в нем проект, который использует QtQuick.Controls. Мне он поугрожал, что использовать полученное можно будет только с версией iOS больше 5.1 … но найдите мне такую версию живьем?
Создаем в нем фаил ресурсов и загоняем туда картинки, тупо выдранные из оригинала (красоту будем наводить потом).
Для начала нам надо добиться, что бы один и тот же код выполнялся и под десктопом и под айфончиком.
Для этого надо:
а) загнать qml в ресурсы
б) нафиг сменить процедуру загрузки, иначе будут ошибки про not ready и прочее. Короче QTBUG-29873
main.cpp сейчас у меня выглядит так
Красивая картинка? Полностью полученное можно посмотреть где положено (то есть в git и нефиг ныть!), а у меня получилось следующее:
Поверьте, на андроиде примерно тоже самое. Теперь необходимо осуществить … гламуризацию всего этого дела. Например, где кнопочка “регистрация” (и нужна ли она)? И все криво при повороте набок. И пароль набирается видимыми буквами. И нету чекбокса. И вообще, все криво.
В общем, надо сделать так, что бы элементы меняли свое положение относительно друг друга при изменении соотношения сторон. Это происходит либо когда окошко у десктопа таскают мышкой, либо мобильник переворачивают.
Для начала убираем всякие Column { и тупо прописываем все подряд. Затем добавляем State почти по инструкции http://doc.qt.digia.com/qtquick-components-symbian-1.1/qt-components-scalability-guidelines-orientation-specific-layouts.html
Так как там немного древнее, я заиспользовал одну StateGroup, без отдельной с when:true
Для проверки я тупо убрал лишнее и в поле для логина начал выводить, какой же State используется. И потом, с помощью PropertyChanges и AnchorChanges я меняю свойства и привязки элементов. В итоге получается “адаптивный” дизайн.
Вот теперь можно и добавить кнопки про регистрацию и вперде!
Правда, вперде прямо сразу не получится. По двум причинам.
Во-первых, для десктопа и мобильного необходимо разные расположения элементов. На мобильном половину (ну или часть) экрана занимает клавиатура, а на десктопе нет. Виндовсные планшеты пока не рассматриваем, их слишком мало, что бы быть принятыми во внимание. И если использовать одну и ту же схему размещения элементов, то либо на мобильном будет криво, либо на десктопе. Некрасиво.
Во-вторых, это долбанное разнообразие разрешений и форматов экрана. У кого-то 4:3, а у кого-то 16:9. Кому-то хватает 640х480 или даже 320 на 240, а кому-то и 1920 на 1080 не хватает.
Что делать?
После некоторого раздумья я решил, что фиг с этими пропорциями. Пусть будет просто две ориентации экрана: горизонтальная и вертикальная.
Для определения платформы (мобильная или десктопная) проще всего использовать предопределенные константы прямо из Qt. напрямую из QML не получится, слишком кроссплатформенный он получился …
Итак, что имеем?
1. ориентацию экрана легко узнать из самого QML. Просто по соотношению высоты и ширины экрана.
2. Ориентацию элементов управления (для мобильного прижимаем кверху, а для десктопа – центрируем) передаем в QML снаружи. Делать свой QML для каждой платформы – моветон.
3. Для удобства позиционирования волевым решением принимаю, что экран в горизонтальной ориентации в реальности имеет размеры 40х30. Кто-то это называет device independed pixels, кто units, кто еще как. И все координаты будут преобразовываться в реальные пикселы отдельной функцией. Сначала засуну ее в QML, а там посмотрим.
Ну, пункт 1 сделан еще на подготовительном этапе.
Теперь надо передать платформу в QML. Обычно народ сразу хватается за классы, но нам-то по идее хватит что-нибудь типа 0 – по центру, 1 – прижимать все вверх.
Теперь везде можно использовать platform. Ну и для порядку неплохо бы обернуть все это в обертку из #define
int platform=0;
#ifdef Q_OS_ANDROID
platform=1;
#endif
#ifdef Q_OS_IOS
platform=1;
#endif
#ifdef Q_OS_WINPHONE
platform=1;
#endif
Потом как-нибудь можно будет сделать более тонкое разделение по платформам.
Что касается пикселов, то это решается еще проще.
Где-нибудь в начале QML, сразу после ApplicationWindow вставляю следующее:
property int guxSize: width/40
property int guySize: height/30
function gux(c)
{
return guxSize*c;
}
function guy(c)
{
return guySize*c;
}
Потом везде, где надо привязаться к координатам, использую gux для х/ширины и guy для y/высоты. Опять же, потом мне ничего не мешает переопределить подсчет этих значений для более тонкого соответствия какому-нибудь хитровыделанному дисплею.
Ну а теперь пора переходить к определению элементов и их размеров. При этом крайне рекомендую внутри элемента описаться на его ширину/высоту, а не на guy/gux. Просто потом будет гораздо легче. И никаких pointSize! Только pixelSize.
Как это выглядит в коде, вы можете увидеть в Stage1. В реальности это выглядит так:
Для “десктопа”
Для “портретного” режима
Можете поизменять размеры окошка и увидеть, как меняется местоположение элементов. Конечно, потом это надо отдать дизайнеру, что бы он своим дизайнерским чутьем подвигал всё туда-сюда, поменял цвета и поделал прочие штуки. На данном этапе важнее функционал.
И да, можно загрузить полученное в телефончик/планшетик и посмотреть, как оно будет выглядеть там. Ну и похвастаться кому-нибудь из знакомых. Всё-таки у вас в руках по настоящему кросс-платформенное приложение.
Давно известна старая фраза “если хочешь, что бы было сделано как надо – сделай это сам”. Правда, мало кто продолжает это фразой “ну или по крайней мере начни”.
Из-за чего все это началось? Давным давно (лет 5 наверное назад, если не больше), я озаботился учетом личных финансов. Ну как-то деньги вроде и были, но почему-то сразу и быстро заканчивались. Я перепробовал кучу всяких разных программ для учета финансов и поначалу остановился на GnuCash. Вроде всем хороша и позволяет делать все, что мне необходимо.
Но через некоторое время она стала меня раздражать. Сделав покупку в магазине, мне необходимо было взять чек с собой, потом не потерять его и затем ввести его в программу. Сначала я делал это каждый вечер, потом стал делать по выходным … а потом забил. Все мое существо протестовало против использования меня в качестве тупого приложения к вобщем-то простой программе. Я стал искать варианты для облегчения своей участи … И не нашел. Нет, в сети есть куча сервисов по учету финансов, но все эти сервисы были или рассчитаны на блондинок, или настолько явно использовали мои данные да еще и за мои деньги, что мне становилось нехорошо.
На тот момент я видел единственный выход – создание своего сервиса, с игрищами и блудницами. Подходящий домен у меня был давно заначен и довольно быстро появился vsemoe.ru. Сервис по учету личных финансов. Поначалу появился клиент под iOS, потом постепенно стал проявляться веб-клиент … и тут ситуация застопорилась. Программисты, которым мы давали писать, постепенно его ушатали до безобразия. С каждой новой версией он жирел и обрастал багами вместо улучшения функционала. В общем, ситуация знакомая практически всем. Ситуация осложняется тем, что Objective-C мне категорически не нравится и я попросту часто не врубаюсь в его логику.
Плюс версия для десктопа тоже постоянно мутировала (у меня в репозитории лежит уже 6й или 7й вариант), но до варианта “мне нравится” так и не дотянула.
Что делать? С одной стороны, по хорошему надо сделать рефакторинг кода и вычистить большую часть наслоений. А с другой стороны, мне очень охота сделать логику одинаковой для всех платформ. Иначе версию для андроида я так никогда и не увижу.
В результате долгих раздумий, проб, макетов и прочих штук, у меня появилось стойкое ощущение, что это можно сделать. В одиночку или с небольшой помощью. Ну и дальше я постараюсь выложить свои шаги по реализации клиента для сервиса vsemoe.ru со своими комментариями.
Скажу сразу: я далеко не профессиональный программист. Говоря нынешними словами, я скорее DevOps с уклоном в сторону администрирования. И я прекрасно сознаю, что кое-какие вещи можно (или даже полагается) делать по-другому. Если знаете как, то помогайте. В общем, начнем.
Для начала я создал аккаунт на гитхабе (https://github.com/kiltum/VseMoe/), в котором и буду выкладывать свои наработки. Опять же, я нагло буду использовать куски уже опубликованного и работающего приложения под iOS (ВсёМоё). Для разработки будут использоваться последние версии Qt/NDK и прочих вещей. Основная работа будет вестись из-под мака (мне так проще).
Итак, что должно получиться в конце?
Приложение-клиент, работающее под Windows, Linux, OS X, iOS, Android и MobileWindows. Короче, под всеми распространенными платформами. Веб-клиент пишется отдельно и я в него не полезу по простой причине: я не понимаю людей, которые все тащат в браузер, словно дети.
