<p>Thanks. Was going to ask for a log but this is better.</p>
<div class="gmail_quote">On Jul 8, 2011 10:45 AM, "Robert Schuster" <<a href="mailto:r.schuster@tarent.de">r.schuster@tarent.de</a>> wrote:<br type="attribution">> Hi guys,<br>> here is the write-up of yesterday's meeting. If you miss something feel<br>
> free to add it as a reply to this mail. Interestingly the last meeting<br>> took place *exactly* a month ago. :)<br>> <br>> necessitas meeting 2011-July 6 - 7pm (GMT+2)<br>> <br>> location:<br>> #<a href="mailto:necessitas@irc.freenode.org">necessitas@irc.freenode.org</a><br>
> <br>> attendees:<br>> BogDan Vatra - bog_dan_ro<br>> Ray Donnelly - mingwandroid<br>> Robert Schuster - rschus<br>> pcspets<br>> thp<br>> <br>> The meeting began a few minutes after the scheduled time and its sole<br>
> purpose was to discuss and exchange ideas about the upcomming rework of<br>> the Java part. Prior to the meeting Robert Schuster had already<br>> posted[0] a drawing and an explanation of the Java part design on the<br>
> project's mailinglist.<br>> <br>> Bogdan mentioned that he was generally OK with the approach and Robert<br>> just explained parts of the idea more in detail.<br>> <br>> pcspets wanted to know why the suggestion to write the activity<br>
> completely in C++ is not being considered. While the approach is<br>> technically possible it automatically increases the minimum supported<br>> Android version to API level 9 (Android 2.3)[1] which at the moment a<br>
> rather steep increase. At the time of this writing the market share for<br>> Android 2.2 is 59.4% and 17.5% for Android 2.1[2]. In other words, we<br>> would could ourselves of off most of our userbase. Robert remarked that<br>
> changing to a complete native App wrapper has the potential to simplify<br>> the Application build process a bit but it must be made the sure that<br>> calling Android services works from the native side.<br>> <br>
> There was also a question about the module called 'Bridge' in the<br>> description of the Java part design. pcspets wanted to know whether this<br>> is what needs to be implemented. Robert answered that this part indeeds<br>
> needs to be implemented by the necessitas project but that most of it<br>> already exists and that that code only needs to be moved and made part<br>> of the Android-Qt build.<br>> <br>> The discussion then went on to the viability of implementing with as<br>
> little Java as possible meaning that there might be quite a few JNI<br>> functions to be called. Robert explained that the Java and the C++ part<br>> should be considered like two sides of the same coin and that it is up<br>
> to the person implementing both to find a design which is both efficient<br>> and maintainable. It was reiterated that future compatibility between<br>> the Java and C++ side is no concern with the proposed redesign because<br>
> it becomes effectively an internal interface that we (= the project)<br>> have full control over.<br>> <br>> There was a discussion about using a very generic Java base class for<br>> all things QtMobility and how this can be used to call different native<br>
> code. After finding out that the Java class contains a pointer to a C++<br>> object that we can cast to a known base class and then call a virtual<br>> method (which makes it call the most-specific variant) nobody saw a<br>
> problem with implementing the 'general base class' idea. Robert said<br>> that in that case one only needs to register the class' native method<br>> once and do the arbitration via the C++ virtual method call.<br>
> <br>> Robert and Bogdan agreed that the build process of Android-Qt needs to<br>> learn to:<br>> * compile Java classes against Android API<br>> * dexify the Java classes and create APK files<br>> For this to work the build will depend on a JDK and an Android SDK<br>
> (*added by editor*: and a chosen acceptable minimum Android API level).<br>> <br>> Bogdan suggested the creation of a Wiki page[3] for the Java part rework<br>> effort. Robert agreed on putting all known information into this page.<br>
> Work will begin July 8th.<br>> <br>> At the end of the meeting everyone had the impression that<br>> implementation problems do not exist anymore and that talking about the<br>> used techniques helped finding this out.<br>
> <br>> A specific date for another meeting was not made. It is expected to be<br>> announced on the mailinglist when the need arises.<br>> <br>> A log of the meeting was posted here[4].<br>> <br>> References:<br>
> [0] - <a href="http://mail.kde.org/pipermail/necessitas-devel/2011-July/000246.html">http://mail.kde.org/pipermail/necessitas-devel/2011-July/000246.html</a><br>> [1] - <a href="http://developer.android.com/guide/appendix/api-levels.html">http://developer.android.com/guide/appendix/api-levels.html</a><br>
> [2] -<br>> <a href="http://developer.android.com/resources/dashboard/platform-versions.html">http://developer.android.com/resources/dashboard/platform-versions.html</a><br>> [3] - <a href="http://community.kde.org/Necessitas/Java/Redesign">http://community.kde.org/Necessitas/Java/Redesign</a><br>
> [4] - <a href="http://paste.debian.net/122237/">http://paste.debian.net/122237/</a><br>> <br>> ---<br>> <br>> Hope you liked the write-up. :)<br>> <br>> Regards,<br>> Robert<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>> <br>> <br></div>