Java rework - what needs to be done
BogDan
bog_dan_ro at yahoo.com
Wed Nov 2 18:32:07 UTC 2011
Hi Lauri,
Sorry for the late reply.
Hmm .. if you need the Activity object in JNI_OnLoad the only way to
get it is calling QtNative.activity(), this method is static and ca be safely
called at any time.
Cheers,
BogDan.
>
>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