Java rework - what needs to be done
Lauri Laanmets
lauri.laanmets at proekspert.ee
Sun Oct 30 13:33:13 UTC 2011
Hi
Well, QApplication is created in the Qt application "main" function. So,
if I want to use that in my lib, I have to be sure that it is
created/initialised. I could run my lib "initialisation" code after
application has already started and initialized the QApplication, but
that is a work-around, I would need Java part in that case. The right
place for the initialisation code would be in JNI_OnLoad. In that case I
can make sure my lib is initialized way before any of the classes will
be instantiated. And the good part is that JNI_OnLoad is called from
Android main thread - that makes things very simple. But... on the other
hand, QApplication is not created yet and I cannot use
QPlatformNativeInterface :)
So... it is: http://en.wikipedia.org/wiki/Catch-22 :)
Lauri
On 30.10.2011 15:18, BogDan wrote:
> Hi,
>
>
> Hmm ... I'm not sure I understand what is the problem, can you explain more?
>
> You should be able to call anything you want from within Android's main thread (UI thread), so, you can use runOnUiThread [1] to call something in java. Also if that function needs to return something you can use a semaphore to block Qt thread until UI thread finish the execution.
>
> Cheers,
> BogDan.
>
>
> [1] http://developer.android.com/reference/android/app/Activity.html#runOnUiThread%28java.lang.Runnable%29
>
>
>
> ----- Original Message -----
>> From: Lauri Laanmets<lauri.laanmets at proekspert.ee>
>> To: BogDan<bog_dan_ro at yahoo.com>
>> Cc: "necessitas-devel at kde.org"<necessitas-devel at kde.org>
>> Sent: Sunday, October 30, 2011 12:37 PM
>> Subject: Re: Java rework - what needs to be done
>>
>> Hi
>>
>> Well, now I'm in trouble. To get the instance of QPlatformNativeInterface, I
>> need to call QApplication::platformNativeInterface() but that doesn't exist
>> yet while loading libraries because that is instantiated in the application
>> main. But I need to have that available already while loading libraries because
>> JNI_OnLoad is the easiest way to process tasks in the main event loop of the
>> Android application. Otherwise I cannot get default Bluetooth adapter because it
>> wants to be called from a thread having Looper.prepared() in it - since Qt main
>> thread is separate from event looper then...
>>
>> Hmm..... what should I do....
>>
>> Lauri
>>
>>
>>
>> On 17.10.2011 21:25, BogDan wrote:
>>> HiCarlos,
>>>
>>> The beauty of the new java implementation is that we can change practically
>> everything in android plugin without breaking the existing applications on
>> Market.
>>>
>>> BTW you can get current JavaVM using
>> QPlatformNativeInterface::nativeResourcesForWidget("JavaVM",0), and it
>> can be changed to support current Activity, current Surface, etc.
>>> Cheers,
>>> BogDan.
>>>
>>>> Hi,
>>>>
>>>> I just read about this... I might be very late... so just one
>>> question:
>>>> Using Neccesitas alpha 1, I made an example to access the GPS
>>> service using as much JNI as possible, however I had to patch:
>>>> A) qtmain_android.cpp -- so the current activity is passed to the
>>> application to access the GPS service using RequestLocationUpdates
>>>> B) QtApplication.java -- to pass the current activity to
>>> qtmain_android.cpp
>>>> C) I had to create a new .java class to implement the
>>> LocationListener interface.
>>>> It would be nice to allow easy JNI coding instead of patching or
>>> implementing JNI_OnLoad for each Qt application. I reckon this can be
>> done by:
>>>> 1. Providing the bridge (or other module) with a void * currentActivity
>> and a void *currentJavaVM;
>>>> 2. Allowing the inclusion of custom java classes in the dex (so
>> env->FindClass() can find them).
>>>> I know that for GPS it might be better to use Mobility but I wanted
>>> to do it myself :-P .
>>>> Any way... some late thoughts. :-)
>>>>
>>>> Cheers,
>>>> Carlos.
>>>>
>>>> On 07/21/2011 04:31 PM, Robert Schuster wrote:
>>>> Hi,
>>> this is a mail describing the necessary changes for the Java part rework
>>> that I am currently doing. I am in the middle of porting the current way of
>> how and application
>>> starts to the new way with a Loader and a Bridge. This process will take
>>> a bit because of the new design a lot of things can be simplified and
>>> one needs to see whether we want to give the person with acces to the
>>> App sourcecode that much control and stuff. Nevertheless for everything to
>> work at some point we need Java and Dex
>>> compilation support in android-qt. All my changes are living in the
>>> 'rschuster-javarework' branch for now. If you look at the
>> src/android folder you see a few subfolders. There is
>>> 'app' for the App starter code. The stuff that needs to be copied
>> into
>>> every android-qt app. This part is more or less finished. There is
>> 'loader' which consists of the thing that implements the real
>>> Activity. To which the app delegates all its calls. This one is under
>>> heavy development and the code needs to be compiled into an APK during
>>> the compilation of android-qt. There is the 'bridge' folder which
>> contains the Java classes which
>>> interact with the Qt libraries. This code also needs to be compiled into
>>> an APK. I have not yet looked at this code but some minor changes are
>>> also needed. I think that for our first generation Loader I am following
>> the example
>>> in the PoC and implement it in a way that the App developer will have
>>> almost zero control over it. Later in a 2nd generation we can gradually
>>> and slowly give more and more control back to the app. I still need to
>> think a bit longer of how we handle different Android
>>> versions in the App and Loader code. Theoretically we can compile the
>>> Loader and Bridge for each Android version we want and let it have more
>>> or less features dynamically. So if you want to help me I need the support
>> for compiling Java sources
>>> into APKs in android-qt. Regards,
>>> Robert
>>> _______________________________________________
>>> 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
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Necessitas-devel mailing list
>>> Necessitas-devel at kde.org
>>> https://mail.kde.org/mailman/listinfo/necessitas-devel
More information about the Necessitas-devel
mailing list