Java part rework - concept

[Robert Schuster]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 729 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20110920/4879f52f/attachment.sig>