Java rework

[Lauri Laanmets]

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 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?

Regards
Lauri


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
>>