Java rework - what needs to be done
BogDan
bog_dan_ro at yahoo.com
Fri Nov 4 20:44:10 UTC 2011
Hi Lauri,
I took a quick look to your code and I must confess I was impressed ! Good job !
But I have a few comments, hope you don't take offense!
Even if your code looks very clean, I think you abused too much by JNI :) e.g. what you have done in AndroidBroadcastReceiver::loadJavaClass for me is very scary. I don't know what is behind JNIBroadcastReceiver_jar, I don't know what these bytes mean !
Your approach is good if we had not found a way to load .jar files at runtime, but is not the case now, all android application contain only a small amount of java code which loads the .jar files provided by Ministro/QtCreator, this files contains all application logic (surface, keyboard, contacts, etc.).IMHO writing everything in C/C++ using JNI is not the best approach (the above example :) ), you should not be afraid to choose java everywhere it makes your life easier, and it makes the things more clear :), I think a good example is what Elektrobit team did in QtMobility, IMHO they found a perfect balance between java and C/C++.
Again, I really hope you don't take offense, it was not my intention !
I hope your work will be finished and integrated soon into Necessitas SDK !
Thanks.
Cheers,
BogDan.
----- 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: Thursday, November 3, 2011 12:50 PM
> Subject: Re: Java rework - what needs to be done
>
> 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