Thoughts on Java files and forward compatibility?
Lauri Laanmets
lauri.laanmets at proekspert.ee
Wed Jul 6 12:11:59 CEST 2011
Hi
I like the Semaphore idea - will go that way definitely. Somehow I feel
that we should cooperate more (not to copy our work), write some general
Java classes (Runnable, BroadcastReceiver, etc...) that can later be
used purely from C++ side. I see a need for a meeting.
Regards,
Lauri
On 6.07.2011 12:08, BogDan wrote:
> 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.
>>>>
>>
>>
>>
More information about the Necessitas-devel
mailing list