Java reworknd now trying to use

Lauri Laanmets lauri.laanmets at proekspert.ee
Tue Oct 18 18:16:49 UTC 2011


Hi

OK, now I see. Again another thing that I'm not familiar with (read: that I have to study).

I decided to reduce the scope of my BroadcastReceiver to the connectivity module - that is just good enough in the beginning. But... I'm trying to access main activity through the QPlatformNativeInterface and seems that function "platformNativeInterface()" is not compiled into the libs. I have just re-compiler the whole Qt repository but get the following error message while linking connectivity module:

/home/lauri/android-qt-mobility/src/connectivity/android/jni_android.cpp:58: undefined reference to `QApplication::platformNativeInterface()'

I'm so lost in the structure - anybody have a good idea?

Lauri



----- Original Message -----
From: "BogDan" <bog_dan_ro at yahoo.com>
To: "Lauri Laanmets" <lauri.laanmets at proekspert.ee>
Cc: necessitas-devel at kde.org
Sent: Monday, October 17, 2011 9:58:10 PM
Subject: Re: Java rework

Hi Lauri,



>
>Hello
>
>Yeah, seems it would be quite difficult (read "impossible") to have an
>Android specific class in Qt main repo and have it's header public in a
>way that it could be used also from other libraries like mobility and so on.
>
>

>OK, I looked around in the Qt repo structure and probably, in the
>beginning, BroadcastReceiver is not need for any other lib than
>mobility. So I will commit it as a /android subfolder in mobility repo.
>Still, one problem exists:
>

I think we can use QPlatformNativeInterface::nativeResourcesForWidget for that job ...
e.g. QPlatformNativeInterface::nativeResourcesForWidget("BroadcastReceiver",0).


>
>I need Android main activity object pointer in mobility lib to be able
>to register the receiver. But as far as I understand, you would like to
>rename "eu.licentia.necessitas.industrius.QtApplication.mainActivity()"
>to another scope and etc. I believe also current mobility C++ part is
>hard-coded to it. How should that work in the future?

Currently Qt platform plugin and Mobility java implementations are in the

same package (.jar file) but on next release I'm planning to create separate packages.
Who it's working:
 - the application connects to ministro service and ask for required modules.
 - ministro replies with .jar files which the application needs to load.
 - the applications loads all .jar files create an instance of loader class, and class loadApplication method

 - this method will instantiate extra classes and calls setActivity method.

Check "unstable" branch src/android/java and src/android/jar folders.



>
>Regards
>Lauri
>

Cheers,
BogDan.


>
>On 14.10.2011 14:40, BogDan wrote:
>> Hi Lauri,
>>
>>
>> We decide to redesign the java part because we want to be able to modify it without breaking the existing applications (e.g. to improve keyboard support, mobility,  etc.).
>>
>> Answers:
>> 1) we plan to create a .jar package which contains all java<=>  jni communication logic, this package will be managed by Ministro as any .so file, and it will be loaded by qt applications at runtime, then the application will forward all its notifications to this package.
>> 2) *ONLY* if is *absolutely* necessary and *ONLY* if is no other way to do it! Remember we are seeking to merge everything with upstream and AFAIK they don't like this kind of things.
>>
>>
>> Cheers,
>> BogDan.
>>
>>> Hi
>>>
>>> I was about to commit my BroadcastReceiver when I noticed that you have changed the Java package part from eu.licentia to org.kde and so forth. I'm so lost in the remake of this. Could you explain it a little:
>>>
>>> Questions:
>>>
>>> 1. Is the plan to .jar all Java files together into ministro or keep them in the users's project?
>>> 2. Would it be OK to make one public android header in Qt repo (in plugins/platforms/android) so that it can be included in building Mobility and so forth? For that reason I think I need to change the "bin/syncqt" script that doesn't have any android specifics at the moment.
>>>
>>> I would very much like to have a meeting in Munich because I have no idea what other people think or do.
>>>
>>> Regards
>>> Lauri
>>>
>
>
>
>


More information about the Necessitas-devel mailing list