Java rework - what needs to be done
Lauri Laanmets
lauri.laanmets at proekspert.ee
Sun Nov 6 10:54:56 UTC 2011
Hi
Not at all... on the contrary I'm glad that somebody took the time to
have a look into my code and that specific comment I was actually
expecting. I had eye covers on because I was desperate on proving that
everything can be done from C++ side - and I was right :)
But now... do you think I should move even more things into Java or just
the loading of BroadcastReceiver? I actually don't like the byte array
myself because maybe, maybe we will end up in security issues later on
when signing packages. But I would keep the Java part as simple as it is
right now.... otherwise it will be a hell to keep them in sync while
developing new stuff or changing libs. And I have no motivation to
rewrite it :)
So... my main question is: what are the next steps I have to take to put
something into public use already? SPP client profile and device
discovery works quite well already and the code should be clean enough
to merge it into upstream. If we have the main structure settled, I will
start working on the remaining parts - when I have time.
My wet dream is to have my current state of Bluetooth in public Ministro
so that I don't need to use local libs for my own app :)
Regards
Lauri
On 4.11.2011 22:44, BogDan wrote:
> 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