Java rework - what needs to be done
Lauri Laanmets
lauri.laanmets at proekspert.ee
Thu Nov 3 10:50:42 UTC 2011
Hi
No prob. I was already trying the QtNative.activity() version out but
then realized one possibility to use QApplication still later, not
during the libs loadings.
So, I proudly present 40% ready Bluetooth implementation that doesn't
have any external Java file dependency. I use two tricks:
1. QApplication::platformNativeInterface() to get the Android main
activity object. [1]
2. Write to cache dir and DexClassLoader to defined my Java part [2]
[1]
https://qt.gitorious.org/~pcspets/qt-mobility/proekspert-android-qt-mobility/blobs/master/src/connectivity/android/androidbroadcastreceiver.cpp#line216
<https://qt.gitorious.org/%7Epcspets/qt-mobility/proekspert-android-qt-mobility/blobs/master/src/connectivity/android/androidbroadcastreceiver.cpp#line216>
[2]
https://qt.gitorious.org/~pcspets/qt-mobility/proekspert-android-qt-mobility/blobs/master/src/connectivity/android/androidbroadcastreceiver.cpp#line156
<https://qt.gitorious.org/%7Epcspets/qt-mobility/proekspert-android-qt-mobility/blobs/master/src/connectivity/android/androidbroadcastreceiver.cpp#line156>
Regards
Lauri
On 2.11.2011 20:32, BogDan wrote:
> 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