<table cellspacing="0" cellpadding="0" border="0"><tr><td valign="top" style="font: inherit;"><p>http://wwp.greenwichmeantime.com/time-zone/europe/european-union/central-european-time/<br>
<br><br><br></p>
<p>Sent from Yahoo! Mail on Android</p>
</td></tr></table> <div id="_origMsg_">
<div style="font-family:arial, helvetica, sans-serif:font-size:10pt">
<br />
<div style="font-family:times new roman, new york, times, serif;font-size:12pt">
<font size="2" face="Tahoma">
<hr size="1">
<b>
<span style="font-weight:bold;">From:</span>
</b>
BogDan <bog_dan_ro@yahoo.com>; <br>
<b>
<span style="font-weight:bold:">To:</span>
</b>
necessitas-devel@kde.org <necessitas-devel@kde.org>; Robert Schuster <r.schuster@tarent.de>; <br>
<b>
<span style="font-weight:bold:">Subject:</span>
</b>
Re: Java part rework - concept <br>
<b>
<span style="font-weight:bold;">Sent:</span>
</b>
Thu, Jul 7, 2011 10:53:44 AM <br>
</font>
<br>
<table cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td valign="top" style="font:inherit;"><table cellspacing="0" cellpadding="0" border="0"><tr><td valign="top" style="font:inherit;"><p>CET is GMT+2 AFAIK.<br>
BogDan.<br><br><br></p>
<p>Sent from Yahoo! Mail on Android</p>
</td></tr></table> <div id="_origMsg_">
<div style="font-family:arial, helvetica,;">
<br />
<div style="font-family:times new roman, new york, times, serif;font-size:12pt;">
<font size="2" face="Tahoma">
<hr size="1">
<b>
<span style="font-weight:bold;">From:</span>
</b>
Robert Schuster <r.schuster@tarent.de>; <br>
<b>
<span style="">To:</span>
</b>
necessitas-devel@kde.org <necessitas-devel@kde.org>; <br>
<b>
<span style="">Subject:</span>
</b>
Java part rework - concept <br>
<b>
<span style="font-weight:bold;">Sent:</span>
</b>
Thu, Jul 7, 2011 10:22:12 AM <br>
</font>
<br>
<table cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td valign="top" style="font:inherit;">Hi all,<br>finally I found the time to do a write up of the concept of the Java<br>part rework that Bogdan, Christian and I talked about at QCS in Berlin.<br>Attached is (hopefully) a drawing that shows the individual components.<br>This mail is supposed to be a complete explanation of the whole topic.<br>For a discussion on IRC later this day it would be nice if you've read<br>it. :)<br><br>Base technique: At QCS we found out that it is very impractical to have<br>that many Java classes in sourcecode form in each application. Simply<br>because every class becomes part of the public interface. This will<br>cause a huge maintenance burden. I'd simply say it would not work. We<br>need to move large parts of the code into places that are independent<br>from the application. This however strongly required the need to add<br>classes from a foreign APK or DEX file to the
application's classpath.<br>We were not sure whether Android would allow this but it indeed does. As<br>a proof of concept we wrote a demo[0] application which can load any (!)<br>APK or DEX file and create an instance of any class and call its<br>toString() method. The POC worked in the way we wanted on a rooted but<br>also on a normal locked device.<br><br>With this technique at hand we can do the following:<br>* Move all code that is not really necessary for app startup into<br>separate APK files<br>* Define an interface between App and Loader which can handle updates<br>(that allows for incompatible changes in the App code over time)<br>* Profit! Err, yeah ... ;)<br><br>Let's explain all the little boxes from the drawing:<br><br>App:<br>----<br>This is the source code that is part of each Android-Qt application. The<br>user *may* change little pieces of the code as long as it does not<br>violate the interface to the Loader or Ministro. What
the user
can do is<br>calling any methods of the public interfaces to the loader for example.<br>We will mark the pieces of code that the user *must* not remove or<br>modify otherwise.<br>This whole thing will be as small as possible!<br>Whenever there is the need to change the App code in an incompatible way<br>we need to introduce a new Loader interface. E.g. we will have a<br>LoaderVersion1 interface for now. When it changes the App code will ask<br>for LoaderVersion2. The Loader's reponsibilities will be explained below.<br><br>Loader:<br>-------<br>The Loader connects methods from the App with the Android Activity<br>class. It will implement all available methods in order to gain maximum<br>control over the App code without letting the App decide by itself. The<br>Loader is published by us and can as such be updated over time allowing<br>*us* to fix bugs, introduce new feature to *existing* applications<br>without changing them.<br>There might be
applications with different versions of the starter code<br>in it. Each of those version requires a specific interface in the<br>Loader. The most up to date version of the Loader will understand (=<br>implement) and offer all interfaces. That way old and new application<br>start code is always compatible with the Loader.<br>If a Loader cannot satisfy the requested interface of an application<br>then this means that the current version of the Loader is too old and it<br>will update itself.<br>(The Loader will technically be part of Ministro, when Ministro is<br>installed. If the user is a developer and chose 'use local libs' then<br>the loader will also be copied to a well known directory and directly<br>included into the Apps classpath. As such at runtime of an App the<br>Loader APK will be part of the App's process space!)<br><br>Ministro:<br>---------<br>Ministro does what it does right now: It downloads the libs (if<br>necessary),
provides the
locations of the libraries and tells the app<br>that it can start. I'm actually thinking of putting the 'satisfy a<br>certain Loader interface version' into Ministro, too. Because that seems<br>like the best place for it).<br>Unlike now the interface between App and Ministro will become upgrade<br>compatible. While changes will happen less frequently it is very<br>important that we allow and can deal with incompatible changes to the<br>interface between Ministro and the App.<br><br>Bridge:<br>-------<br>These are all the classes that interact in some way with the C++ code of<br>the Android-Qt port. Unlike now they will be a private interface.<br>Meaning that we can do *any* change we want in them. For each supported<br>Qt version (4.9, 5.0 etc.) there will be an accompanying bridge. The<br>bridge may even consist of multiple APKs if we want to save space (e.g.<br>if QtMobility is not used, then the classes for it do not need to
be<br>available as
well).<br><br>Qt:<br>---<br>These are the native Qt libraries. No change needed. Except that any<br>code can *assume* the existence of certain bridge classes and can<br>resolve class names at will.<br><br>Caveats:<br>-------<br>From a development perspective this is quite a task. The Java code<br>changes are not so difficult (for me at least) but I have no clue how we<br>can modify the Android-Qt build to also compile Java classes, dexify and<br>make an APK out of them. Because this is what we need. When you compile<br>Qt for Android you'll need a Java compiler, the DEX tool and something<br>that creates an APK for you. IOW this is where I need you help.<br><br>The Ministro build also needs to be changed a bit. The Ministro APK<br>could contain the Loader classes. That would not be a problem. However<br>somehow QtCreator needs the Loader classes too when using 'use local<br>libs' flag. I propose that the SDK installer also downloads the
Loader<br>classes (which might be the same as Ministro but as a library not an<br>application) from a known location.<br><br>I plan to use real Java interfaces in order to define the public<br>interface. An alternative approach would be to rely on reflection only.<br>However that will make the interface very opaque and the code will be<br>difficult to read for anyone with only a small knowledge of Java. Having<br>interfaces however means we will need to share bits of sourcecode<br>between the projects (namely the interface file). I'm still<br>contemplating how to do this properly.<br><br>For tonight I am mostly interested in how to solve the caveats.<br><br>Let me know what you think. If not we'll see each other at 7pm CET/GMT+1. :)<br><br>Regards,<br>Robert<br><br>[0] - <a rel="nofollow" target="_blank" href="http://paste.debian.net/122188/">http://paste.debian.net/122188/</a><br><br>-- <br>tarent solutions GmbH<br>Thiemannstr. 36 a, D-12059
Berlin • <a rel="nofollow"
target="_blank" href="http://www.tarent.de/">http://www.tarent.de/</a><br>Tel: +49 30 5682943-30 • Fax: fax +49 228 52675-25<br><br>Rochusstraße 2-4, D-53123 Bonn • <a rel="nofollow" target="_blank" href="http://www.tarent.de/">http://www.tarent.de/</a><br>Tel: +49 228 52675-0 • Fax: +49 228 52675-25<br>HRB AG Bonn 5168 • USt-ID (VAT): DE122264941<br>Geschäftsführer: Boris Esser, Elmar Geese<br><br></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>