Java rework - what needs to be done
BogDan
bog_dan_ro at yahoo.com
Mon Nov 7 19:36:33 UTC 2011
Hey,
>
>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 :)
>
Anything is possible :)
>
>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 :)
>
As I told you in my last mail, you should use Java anywhere it makes your life easier !
>
>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.
>
Please create a merge request ! Make sure your patches are compiling
and don't break anything :)
>
>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 :)
>
Your dream can become true with a little effort, I don't know how much
you effort you need to finish your work, but I believe is not too much,
and probably if you'll use more java you'll be more productive ;-)
>
>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