Thoughts on Java files and forward compatibility?

[BogDan]

Hi,

It seems you are right,  DexClassLoader needs a path to extract the .dex files, so please use cache folder (please make sure you create that folder before using it, because it may not exists).

You can't get rid of java part and stats using android app glue thing because you still need Ministro to tell your application where it can find the QtLibs. Also that thing was introduced too late (android-9) and we can't use it.

I'm using something similar (Activity.runOnUiThread [1]) to run commands on ui thread, if you want to "synchronize" that call, I recommend you to use a semaphore :

class MyClass
{
private final Semaphore m_sem =new Semaphore(1);

public void registerReciever() throws InterruptedException
{
        QtApplication.mainActivity().runOnUiThread( new Runnable(){ 
                   @Override
                   public void run(){
                        // do your stuff here
                        m_sem.release(); // the wait is over
                 }
        });
        m_sem.acquire(); // wait until the command is fired
}
}



Cheers,
BogDan.

[1] http://developer.android.com/reference/android/app/Activity.html#runOnUiThread(java.lang.Runnable)

>
>Hi
>
>I have used .jar files and in that case DexClassLoader definitely needs the temp folder - it starts even whining when the exact sub folder doesn't exist. Since there will be several .dex files (IMHO) I guess we need to keep them in .jar. I'll try to use the cache, thanxs.
>
>About the Thread - that's a tricky one, yes. Current android Qt app runs in a separate (clean) thread and that by default doesn't have the Android Looper prepared. And that's actually OK because looper can be used only if it creates the event loop itself. IMHO we should use the android app glue (like in the "native-activity" sample in NDK without ANY java files) and port the QApplication.exec into Android event looper. But of course I don't know much about that and maybe I'm totally wrong - excuse me if I am.
>
>So my problem was while executing "BluetoothAdapter.getDefaultAdapter()". Somewhere in the Android library, it needs to create a Handler and that execution must be in the main UI thread and not in the Qt thread.  So I had no other option than to implement a general JNIRunnable so that I can register a C++ function into it and pass it on to the main Activity to be executed. It works :) The only trouble is that I'm not in control WHEN Android chooses to execute it. So I have to block everything for a short time in Qt Bluetooth API. It's OK for me but I'm a bit reluctant on releasing such a library.
>
>Regards
>Lauri Laanmets
>
>
>On 6.07.2011 8:55, BogDan wrote:
>> Hi Lauri,
>> 
>> 
>> AFAIK that folder is not used, I recommend you to use  getCacheDir( ) [1].
>> 
>> Regarding the error, I think you are trying to create that object from Qt thread, you should use UI thread for that job. 
>> Cheers,
>> BogDan.
>> 
>> [1] http://developer.android.com/reference/android/content/Context.html#getCacheDir()
>> 
>> 
>> P.S. Sorry for the slow replay.
>> 
>> 
>> ----- Original Message -----
>>> From: Lauri Laanmets<lauri.laanmets at proekspert.ee>
>>> To: BogDan<bog_dan_ro at yahoo.com>
>>> Cc: necessitas-devel at kde.org
>>> Sent: Tuesday, July 5, 2011 2:11 AM
>>> Subject: Re: Thoughts on Java files and forward compatibility?
>>> 
>>> Evening
>>> 
>>> I see... ok, having .jar files in ministro folder is ok but the DexClassLoader
>>> also needs a "temp" folder. Any ideas where to direct that?
>>> 
>>> I made a prototype of generic JNIBroadcastReceiver, one can just inherit and
>>> implement "onReceive" function, have a look if interested:
>>> https://qt.gitorious.org/~pcspets/qt-mobility/proekspert-android-qt-mobility/commit/c5820d506b35e0e1b1bff8a4839899c01ab2722f
>>> 
>>> 
>>> And I also need help, I keep getting the following error, any experience?:
>>> 
>>> W/dalvikvm( 1513): threadid=15: thread exiting with uncaught exception
>>> (group=0x4001e390)
>>> E/AndroidRuntime( 1513): Uncaught handler: thread Thread-11 exiting due to
>>> uncaught exception
>>> E/AndroidRuntime( 1513): java.lang.RuntimeException: Can't create handler
>>> inside thread that has not called Looper.prepare()
>>> E/AndroidRuntime( 1513):     at
>>> android.os.Handler.<init>(Handler.java:121)
>>> E/AndroidRuntime( 1513):     at
>>> android.bluetooth.BluetoothAdapter$1.<init>(BluetoothAdapter.java:807)
>>> E/AndroidRuntime( 1513):     at
>>> android.bluetooth.BluetoothAdapter.<init>(BluetoothAdapter.java:806)
>>> E/AndroidRuntime( 1513):     at
>>> android.bluetooth.BluetoothAdapter.getDefaultAdapter(BluetoothAdapter.java:298)
>>> E/AndroidRuntime( 1513):     at dalvik.system.NativeStart.run(Native Method)
>>> 
>>> Lauri
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>> I know that class, the "problem" now is to redesign the current Java
>>> part :)
>>> Because the java which will be shipped with your application should be VERY small and VERY stable, it should only search for Ministro and create
>>> the main activity. The rest of java should be loaded from Ministro's
>>> repository.
>>> 
>
>
>
>