<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Hi Robert,</span></div><div><span><br></span></div><div><span>I'm more than </span>interested in all your explanations ! :)</div><div>Sadly this days I don't have too much time for Necessitas, I promise I'll be back very soon !</div><div><br></div><div>Cheers,</div><div>BogDan.</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "><font size="2" face="Arial"><hr size="1"><b><span style="font-weight:bold;">From:</span></b> Robert Schuster
<r.schuster@tarent.de><br><b><span style="font-weight: bold;">To:</span></b> necessitas-devel@kde.org<br><b><span style="font-weight: bold;">Sent:</span></b> Tuesday, July 12, 2011 1:00 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: Java part rework - concept<br></font><br>Hi everyone,<br>is actually anyone interested in all these explanations? ;)<br><br>Anyway I finished the Proof-Of-Concept implementation and also its<br>description. If anyone has a question about the Java part rework it is<br>all on:<br><br><a href="http://community.kde.org/Necessitas/Java/Redesign" target="_blank">http://community.kde.org/Necessitas/Java/Redesign</a><br><br>I'd suggest those who are concerned to actually look at the PoC and the<br>comments within.<br><br>I'm now starting with an actual Android implementation of the ideas.<br>I'll refine the information on the website as soon as I see that this is<br>necessary.<br><br>Happy
hacking!<br>Robert<br><br>Am 07.07.2011 12:22, schrieb Robert Schuster:<br>> 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 href="http://paste.debian.net/122188/" target="_blank">http://paste.debian.net/122188/</a><br>> <br>> <br>> <br>> <br>> _______________________________________________<br>> Necessitas-devel mailing list<br>> <a ymailto="mailto:Necessitas-devel@kde.org" href="mailto:Necessitas-devel@kde.org">Necessitas-devel@kde.org</a><br>> <a href="https://mail.kde.org/mailman/listinfo/necessitas-devel" target="_blank">https://mail.kde.org/mailman/listinfo/necessitas-devel</a><br><br><br>-- <br>tarent solutions GmbH<br>Thiemannstr. 36 a,
D-12059 Berlin • <a href="http://www.tarent.de/" target="_blank">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 href="http://www.tarent.de/" target="_blank">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><br><br>_______________________________________________<br>Necessitas-devel mailing list<br><a ymailto="mailto:Necessitas-devel@kde.org" href="mailto:Necessitas-devel@kde.org">Necessitas-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/necessitas-devel" target="_blank">https://mail.kde.org/mailman/listinfo/necessitas-devel</a><br><br><br></div></div></blockquote></div></div></body></html>