Thoughts on Java files and forward compatibility?

[BogDan]

Hi Lauri,

Loading qt-android specific classes at runtime is definitively the way we should go, 
the problem is how to do it ? I, Robert and Christian (in CC) already started a discussion 
about this topic [1], so, if you want to join our effort you are more than welcome ! :)

Now it seems are 2/3 possibilities to do it:
- instantiate those classes from java [1] [2]
- and your Idea (which seems to god to be true :) ), please test it and ask Google if this feature is/will be supported by all platforms.

If any of this methods will be bless by Google, then, we can release the beta version sooner, before we finish all remaining missing features [3].

Cheers,
BogDan.

[1] http://mail.kde.org/pipermail/necessitas-devel/2011-June/000108.html
[2] http://stackoverflow.com/questions/3022454/how-to-load-a-java-class-dynamically-on-android-dalvik
[3] http://community.kde.org/Necessitas/Meetings/QtCS2011

>
>
>Hi
>
>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):
>
>jbyte java_class[] = { 0x01, 0xFF, ...}; // Precompiled and
    hard-coded Java class byte array
>jclass DefineClass(JNIEnv *env, const char *name, jobject loader,
    const jbyte *java_class, jsize bufLen); // register in Env
>jobject NewObject(JNIEnv *env, jclass clazz, jmethodID methodID, ...);
>
>and so on....
>
>Am I thinking the right way or do I miss something? Could I do this?
>
>Regards
>Lauri
>
>
>
>
>
>On 26.06.2011 16:05, Espen Riskedal wrote: 
>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 Necessitas-devel at kde.org https://mail.kde.org/mailman/listinfo/necessitas-devel
>
>_______________________________________________
>Necessitas-devel mailing list
>Necessitas-devel at kde.org
>https://mail.kde.org/mailman/listinfo/necessitas-devel
>
>
>