<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi<br>
<br>
That's what I also would like to sort out - for example I'm trying
to figure out the cleanest way to implement Bluetooth support and
was thinking of an idea to precompile the .java file to .class and
put it in Qt source code as a byte array and use JNI DefineClass.
Something like this (in expressional syntax):<br>
<br>
jbyte java_class[] = { 0x01, 0xFF, ...}; // Precompiled and
hard-coded Java class byte array<br>
jclass DefineClass(JNIEnv *env, const char *name, jobject loader,
const jbyte *java_class, jsize bufLen); // register in Env<br>
<code class="cCode">jobject NewObject(JNIEnv *env, jclass clazz,
jmethodID methodID, ...);</code><br>
<br>
and so on....<br>
<br>
Am I thinking the right way or do I miss something? Could I do this?<br>
<br>
Regards<br>
Lauri<br>
<br>
<br>
<br>
<br>
<br>
On 26.06.2011 16:05, Espen Riskedal wrote:
<blockquote
cite="mid:BANLkTikKe0juoTEEKZw=zLJCn1Z8OtVgMQ@mail.gmail.com"
type="cite">
<pre wrap="">A small problem just bit me in the ass, but it does show some issues
regarding being able to promise forward compatibility with never
versions of Qt.
With Qt Creator, at the moment, it will copy QtApplication.java etc.
to your local project. I had already done this for some older
projects, and when I was trying to run these projects with a newer
version of Qt they failed because:
E/AndroidRuntime(21608): FATAL EXCEPTION: Thread-10
E/AndroidRuntime(21608): java.lang.NoClassDefFoundError:
eu.licentia.necessitas.industrius.QtApplication$4
E/AndroidRuntime(21608): at
eu.licentia.necessitas.industrius.QtApplication.setFullScreen(QtApplication.java:375)
E/AndroidRuntime(21608): at dalvik.system.NativeStart.run(Native Method)
E/AndroidRuntime(21608): Caused by: java.lang.NoSuchMethodError: openURL
Now, openURL was added in QtApplication.java after I generated the
project files, so we could simply fix this by instead of copying the
eu.licentia *.java files simply _refer_ to them to where they're
actually located in your installed Qt version. This would solve my
problem.
But actually, it won't solve the real problem: Changes in
QtApplication.java will/may (it seems?) be reflected in changes in Qt
libraries or the Android QPA plugin, which means older applications
that don't have updated QtApplication.java implementations will crash
as Qt libraries or the QPA plugin may call these functions.
I'd say:
1 - we should not copy the .java files into projects, but simply refer
to the .java files as they are in the installed Qt you're using (or at
least, overwrite if they're different)
2 - find a more robust way which enables changes to the .java wrapper
functions regardless
I know Robert and Christian has been working on this? What are your thoughts?
espen
_______________________________________________
Necessitas-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Necessitas-devel@kde.org">Necessitas-devel@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/necessitas-devel">https://mail.kde.org/mailman/listinfo/necessitas-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>