Java rework - what needs to be done

[BogDan]

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
>