Java part rework - concept

[BogDan]

Hi,

I'm planning to begin the redesign stating with next week, so if you have time to join it will be great !

Cheers,
BogDan.




>________________________________
>From: Robert Schuster <r.schuster at tarent.de>
>To: Espen Riskedal <espen at cutehacks.com>
>Cc: necessitas-devel at kde.org
>Sent: Tuesday, September 20, 2011 10:19 AM
>Subject: Re: Java part rework - concept
>
>Hi Espen,
>first of all: Sorry, for the delay. I did not see this post until now
>and was on vacation last week.
>
>Am 31.08.2011 14:54, schrieb Espen Riskedal:
>> I've been reading throught this and have some questions.
>Cool!
>
>> The Bridge code is obviously tied to a spesific Qt release and
>> promises no compibility. But what about the Loader code?
>The Loader code interacts with a the Bridge, that's right. However the
>interface
>between the two is under our control.
>
>> As I understand the app will ask for a minimum version of the Loader,
>> and if the Loader is of a later version that Loader will still promise
>> backward compatibility for earlier Loader versions?
>The App will ask Ministro for a minimum version of the Loader and Ministro
>will provide an implementation that fits. For the moment I suggest we
>bundle our Loader with Ministro (packaging it as a raw resource). The
>Loader is very small and we can easily put 3 or more of them into
>Ministro's APK. If we want more flexibility we put the Loaders in an
>online repository and let Ministro download them when requested. When we
>do that we gain two more things:
>a) we can update the Loader implementation under the hood (e.g. when a
>change of the Loader-Bridge interface was necessary)
>b) the Loader levels Ministro supports is dependent on what is in the
>repository not on Ministro itself.
>
>> But, is there not a connection between the Loader code and the
>> Bridge/Qt Qt code as well? When looking at
>> https://github.com/thebohemian/necessitas-android-poc/blob/master/loader/src/eu/licentia/necessitas/loader1/Activity4.java
>> I guess these stubs calls something in the end? Also, how is a newer
>> version of a Loader created - as a subclass of the previous version or
>> as a parallelle subclass implementing an Interface or?
>This depends solely on us. The App only sees the Java interface that we
>defined
>not how it is implemented. Subclassing sounds reasonable to me when the
>new Loader just implements more methods. If it works radically different
>I'd go for a new class.
>
>> Another general question I was thinking of - does this add more
>> complexity to debugging an app with gdb etc?
>Not at all.
>
>> And another question - will this setup make it harder for developers
>> to add their own Java code to an app?
>Yes and no.
>
>The Android PoC contains two variants of an App. One of them is the
>generic app template that all programs should use. It does the minimum
>of what is necessary do interact with Ministro and the Loader. But there
>is also 'appv1'. This one was my initial code for the app and it
>contains code which logs the things happening during the Ministro and
>Loader interaction. One could see that as a major modification of the
>normal app-template code. In other words, if some rules are followed
>there is room for custom Java/Android code.
>
>> It's pretty complex stuff :)
>So is the qt-port for me. :)
>
>Regards,
>Robert
>
>-- 
>tarent solutions GmbH Niederlassung Berlin
>Thiemannstr. 36 a, D-12059 Berlin • http://www.tarent.de/
>Tel: +49 30 3187969-999 • Fax: +49 228 54881-314 (Bonn)
>
>Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
>Tel: +49 228 54881-313 • Fax: +49 228 54881-314
>HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
>Geschäftsführer: Boris Esser, Elmar Geese
>
>
>
>_______________________________________________
>Necessitas-devel mailing list
>Necessitas-devel at kde.org
>https://mail.kde.org/mailman/listinfo/necessitas-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20110921/3f189df1/attachment-0001.html>