<p>Interested but far from what I know about, so I will read your pists but I dont know enough to not just add noise to the discussion.</p>
<p>I'm thinking the same about my post last night too... No one got any ideas for mingw sh.exe being added to the path just because it finds mingws gcc.exe?</p>
<div class="gmail_quote">On Jul 12, 2011 11:03 AM, "Robert Schuster" <<a href="mailto:r.schuster@tarent.de">r.schuster@tarent.de</a>> wrote:<br type="attribution">> 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">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/">http://paste.debian.net/122188/</a><br>
>> <br>>> <br>>> <br>>> <br>>> _______________________________________________<br>>> Necessitas-devel mailing list<br>>> <a href="mailto:Necessitas-devel@kde.org">Necessitas-devel@kde.org</a><br>
>> <a href="https://mail.kde.org/mailman/listinfo/necessitas-devel">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/">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/">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></div>