LINUX.ORG.RU

Qt5 QPSQL driver для Android arm и x86

 , , , ,


0

1

Среда разработки Qt Creator 3.3.0 Qt 5.4.0 (GCC 4.6.1, 64 бита) Установлено всё для компиляции под android, видимо кроме драйвера QPSQL

W/System.err(26392): 	... 25 more
W/System.err(26392): Caused by: java.lang.ClassNotFoundException: Didn't find class "android.graphics.drawable.VectorDrawable" on path: DexPathList[[zip file "/data/app/org.qtproject.example.Diplom-1.apk"],nativeLibraryDirectories=[/data/app-lib/org.qtproject.example.Diplom-1, /vendor/lib, /system/lib, /system/lib/arm]]
W/System.err(26392): 	at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
W/System.err(26392): 	at java.lang.ClassLoader.loadClass(ClassLoader.java:497)
W/System.err(26392): 	at java.lang.ClassLoader.loadClass(ClassLoader.java:457)
W/System.err(26392): 	... 25 more
W/ResourceType(26392): Skipping entry 0x1060087 in package table 0 because it is not complex!
D/dalvikvm(26392): GC_CONCURRENT freed 2500K, 20% free 10759K/13292K, paused 2ms+2ms, total 8ms
D/dalvikvm(26392): GC_CONCURRENT freed 3277K, 23% free 11475K/14780K, paused 1ms+5ms, total 10ms
D/dalvikvm(26392): Trying to load lib /data/app-lib/org.qtproject.example.Diplom-1/libDiplom.so 0x43a0e4f0
D/dalvikvm(26392): Added shared lib /data/app-lib/org.qtproject.example.Diplom-1/libDiplom.so 0x43a0e4f0
D/dalvikvm(26392): No JNI_OnLoad found in /data/app-lib/org.qtproject.example.Diplom-1/libDiplom.so 0x43a0e4f0, skipping init
E/IMGSRV  (26392): :0: PVRDRMOpen: TP3, ret = 46
E/IMGSRV  (26392): :0: PVRDRMOpen: TP3, ret = 48
E/IMGSRV  (26392): :0: PVRDRMOpen: TP3, ret = 50
E/IMGSRV  (26392): :0: PVRDRMOpen: TP3, ret = 50
E/IMGSRV  (26392): :0: PVRDRMOpen: TP3, ret = 50
E/IMGSRV  (26392): :0: PVRDRMOpen: TP3, ret = 52
D/OpenGLRenderer(26392): Enabling debug mode 0
D/Qt      (26392): (null):0 ((null)): FT_New_Face failed with index 0 : 90
W/Qt      (26392): (null):0 ((null)): QSqlDatabase: QPSQL driver not loaded
W/Qt      (26392): (null):0 ((null)): QSqlDatabase: available drivers: QSQLITE
D/Qt      (26392): (null):0 ((null)): "Driver not loaded Driver not loaded"

Где взять/собрать драйверы QPSQL под android arm, x86.

Здесь есть одна проблема. Чтобы собрать QPSQL драйвер, сначала нужно иметь клиентскую либу PostgreSQL. А она под андроид не портирована. Вообще.

Есть какой-то древний порт psqldroid, можешь его поковырять, но там последний коммит от 2010 года.

https://code.google.com/p/psqldroid/

Лучше всего использовать MariaDB, у них есть LGPL клиент, поддерживающий сборку под андроид. Собирал с ним плагин QMYSQL под линухом, работало как часы.

http://qt-project.org/wiki/Build_Qt5_mysql_plugin_for_Android

archie
()
Ответ на: комментарий от archie

Проект в стадии зарождения, поэтому выбор СУБД открыт. Может что лучше подскажите? Кроме MySQL.

Вообщем то хотелось бы сделать кросс-платформенное приложение...

vladcraft
() автор топика

вообще странно что тебе понадобился постгрес или мускул на андроиде. у тебя там сервер будет вертеться?

мой уровень телепатии подсказывает что на андроиде у тебя будет клиент, и ты хочешь сделать сервер бд и клиентом туда коннектиться да? Если так то это плохой путь. делай трехзвенную систему. Клиент RPC сервер BD

MikeDM ★★★★★
()
Ответ на: комментарий от vladcraft

Под андроидом у тебя выбор все равно сводится к MySQL и SQLite, причем последний отпадает.

Тогда плюсую предыдущего оратора. Делай какой-нибудь простенький RESTful вебсервис, который будет отдавать данные клиенту.

archie
()
Ответ на: комментарий от archie

А просто скросскомпилировать клиентскую либу не вариант?

Слабо представляю, что в кроссплатформенной клиентской либе к БД может быть такого что нельзя портануть под андроид:) Там же ни графики, ни работы с железом, так по сети да может ещё по паре транспортов тупо туда сюда чё нить гоняется.

pon4ik ★★★★★
()
Ответ на: комментарий от vladcraft

Прежде чем думать о смене БД(а пострегресс очень неплох), попробуй таки скросскомпилить клиентскую либу... Учитывая что сацесс стори уже имела место быть, я думаю что это будет не очень сложно, а если ты ещё и патч запилишь и где нибудь опубликуешь (в идеале в основном репозитории:) ) то будет совсем уж круто.

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

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

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

В то время как клиентская либа MariaDB уже портирована и по ней имеются легконагугливаемые мануалы.

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

archie
()
Ответ на: комментарий от archie

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

Спорно. Есть популярный сервис parse.com, там по сути голая БД высунута в инет. И ничего, очень популярно. Тут главное, права настроить, чтобы не подропали чего лишнего, так это на постгресе делается.

Legioner ★★★★★
()
Ответ на: комментарий от archie

насчёт трёхзвенной архитектуры верно, но

В любом случае, высовывать голую БД в инет весьма нежелательно,

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

Harald ★★★★★
()
Ответ на: комментарий от vladcraft

На андроиде хотел клиент сделать. Сервер на дебиане.

сделай трехзвенную систему.

Client <-RPC-> Server <-DBPROTO-> DataBase

MikeDM ★★★★★
()
Ответ на: комментарий от Legioner

Тут главное, права настроить, чтобы не подропали чего лишнего, так это на постгресе делается.

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

Про parse.com интересно, не знал. Так у них же ведь куча сдк под разные платформы понаписана, которыми они настоятельно рекомендуют пользоваться. Или это чисто для упрощения работы с данными, чтобы не лазить руками в базу?

archie
()
Ответ на: комментарий от Harald

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

Мускуль-то умеет. Вопрос в том, умеют ли культи. Когда последний раз ковырялись год назад, нужно было Qt плагин дописывать. В итоге забили и сделали запросы вебсервису через HTTPS. С тех пор похоже ничего не изменилось. Подозреваю, с другими плагинами ситуация не лучше.

http://qt-project.org/forums/viewthread/48147

archie
()
Ответ на: комментарий от archie

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

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

Про parse.com интересно, не знал. Так у них же ведь куча сдк под разные платформы понаписана, которыми они настоятельно рекомендуют пользоваться. Или это чисто для упрощения работы с данными, чтобы не лазить руками в базу?

Не, у них всё как бы через API идёт. Но это API по сути один в один интерфейс к БД. select/insert/update/delete. Можно это называть веб-апи, я не вижу отличий от SQL-like интерфейса, кроме деталей реализации. А все SDK в конечном итоге, насколько я знаю, сводятся к HTTP REST-вызовам. А безопасность сводится к тому, что в админке размечаешь, к каким сущностям какие операции пользователи могут применять. Полный аналог БД-шных прав.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от Legioner

Ага, действительно получается практически голый SQL-like интерфейс. Под веб апи обычно понимается более высокоуровневый протокол, который работает с объектами в предметной области, а не с таблицами. Понятно. Спасибо.

archie
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.