Серьезно, сейчас большинство проектов используют те или иные SDK (сложные контролы, просмотр файлов, свои карты, оплата онлайн, навигация, работа с Push, сбор пользовательских метрик и крешей), которые теоретически можно подключить к Qt, но быстрее может оказаться написать нативное приложение :)
Все зависит от специфики проекта, конечно. Из моего опыта работы с Qt (более 5 лет для desktop, maemo, symbian, windows mobile и embedded):
Неродной UI — получаем тот же Look and Feel, но быстрее! На винде Alien-виджеты работают намного быстрее честных виндовых окошек.
Так UI все равно не родной, а для получения нужного Look'n'Feel (стандартные анимации и поведение элементов) потеть приходится очень усердно для каждой платформы.
отсутствуют сторонние компоненты (только библиотеки “из коробки”) — в Qt из коробки есть не только лишь все… Серьезно, Qt обычно только за это и ругают, что он тяжелый, потому как там реально все есть.
Современный mobile это в первую очередь работа со сторонними библиотеками ;) В Qt очень ограниченный доступ к нативке, только через свои обертки.
возникают сложности при сборке и отладке приложения — какие? Я с одной машины могу под все платформы Qt собрать, да еще и свое мобильное приложение под Desktop'ом покрутить в окошке
Отладка и тестирование реальных приложений на реальных устройствах с полной функциональностью. Десктоп-версия далеко не весь функционал позволяет посмотреть, но судя по всему вы пока с этим не сталкивались.
сложности также при доступе к нативной функциональности — тут да, однако C++ могучий, с ним до куда угодно можно дотянуться, без всяких PInvoke'ов
К Java и Objective C дотянуться ой как непросто ;) В реальных проектах, конечно же.
Но это все мое IMHO, основанное на моем опыте работы с большим количеством реальных мобильных проектов.
Ну здесь все просто :) В реальных проектах практически всегда требуется доработка UI-контролов и часто нужен доступ к какой-нибудь специфической нативной функциональности (вроде фоновой синхронизации), которую хочешь или не хочешь, но надо делать на Objective C и Java.
Про саму авторизацию — все будет зависеть от того, REST вы используете, SOAP или что-то еще. В любом случае там все решается достаточно просто на уровне HTTP-заголовков или параметров URL. Если вы используете REST, то мы уже описывали работу с ним на Xamarin.Forms с помощью Refit и там можно легко добавить нужные механизмы авторизации: https://habrahabr.ru/company/microsoft/blog/310704/
Cordova и Ionic имеют свои плюсы, однако за ними нет крупных игроков (Apple, Microsoft, Facebook, Google), да и сам по себе подход отображения UI внутри WebView не всех устраивает, так как нет возможности управлять жизненным циклом UI. А мобильные приложения это в первую очередь UI. Но это все IMHO — сами работали в экспериментальном формате с Cordova, но приложения на выходе были не того качества которое нужно, плюс требовалось использовать Objective C и Java для создания своих платформенных фич.
Статья максимально практическая, поэтому вопросы культуры и подхода к работе остались за скобками. Об этом мы подробнее рассказывали на DevCon School «Современная мобильная и веб-разработка». Когда тема с культурой и процессом дозреет — опишем и ее. Пока же — максимальная практика и минимум философии.
Глобально, VK для Xamarin цепляется вполне хорошо. Тогда в следующей статье рассмотрим. Потом до кучи разберем OAuth, чтобы и другие соц. сети можно было цеплять без проблем.
У RestSharp традиционные проблемы с PCL-проектами, поэтому для Xamarin.Forms он не очень хорошо подходит. Да и Refit на наш взгляд более удобное и простое решение. Но это все IMHO, а так RestSharp — да, хороший инструмент.
Про пользовательский режим не совсем понятно. На базе SVG-иконок создается TTF-шрифт, который по аналогии с обычными шрифтами используется в приложении.
Спасибо! SkiaSharp штука хорошая, но это все-таки больше полноценная платформа для рисования графики. А вот NControl подходит для разных мелочей, которые быстрее нарисовать руками, чем возиться с подгонкой графики под разные экраны.
Так UI все равно не родной, а для получения нужного Look'n'Feel (стандартные анимации и поведение элементов) потеть приходится очень усердно для каждой платформы.
Современный mobile это в первую очередь работа со сторонними библиотеками ;) В Qt очень ограниченный доступ к нативке, только через свои обертки.
Отладка и тестирование реальных приложений на реальных устройствах с полной функциональностью. Десктоп-версия далеко не весь функционал позволяет посмотреть, но судя по всему вы пока с этим не сталкивались.
К Java и Objective C дотянуться ой как непросто ;) В реальных проектах, конечно же.
Но это все мое IMHO, основанное на моем опыте работы с большим количеством реальных мобильных проектов.
Про Expo полезное дополнение, спасибо!
По ВКонтакте и OAuth сделаем следующие статьи