[Development] Android port - Why do we need Ministro?

[Felipe Crochik]

With my very limited experience on the subject I have to say that "the
current flow" is probably good enough for "controlled distribution" but
pretty bad for mass market apps.

Having the application download the libraries after "being downloaded" is
bad enough for the average user but figuring out the "installing ministro
step" requires a level of commitment that I think very few "average/casual"
users will show for a "random application they found in the store".

Why do you think incorporating ministro code into each application is bad?
Unless there is some technical limitation to install shared libraries this
way the only drawback I can imagine is that we will need to update
applications that depend on it with any "improvement on it" is made because
of new devices - what is a pretty reasonable problem to work around.

Note that I am only talking about "the Qt shared libraries" - not any other
third party libraries.

just my 2ct.

On Fri, Jan 11, 2013 at 10:07 AM, Eskil Abrahamsen Blomfeldt <
eskil.abrahamsen-blomfeldt at digia.com> wrote:

>  On 01/11/2013 03:36 PM, Felipe Crochik wrote:
>
> Are there plans to change this flow? I have to assume there were good
> reasons to do like this but without actually looking into the code it seems
> that would make more sense to combine the ministro code with the java
> wrapper generated for each application, no?
>
>  I understand ministro plays an important part and donwloads the right
> version of the libraries for each device and that we would have to
> duplicate its code with every application but it seems like a very
> reasonable price to pay if that would actually make the "first install"
> experience better. Are there any other technical reasons why this approach
> would not work?
>
>
> Hi,
>
> We need alternative deployment mechanisms for the use cases that are not
> covered by Ministro, but there are issues with this for deploying imports
> and plugins and Ministro also makes it easier to deploy to different
> devices, as it downloads the correct version of the platform plugin for
> you. I think this is all solvable somehow, but I don't think the solution
> is integrating Ministro in each app, because each app would still have to
> download their own libraries if there's no central repository on the
> device. I think it would be better to make a secondary deployment method
> which allows you to put everything you need into the apk so that the app
> works out of the box and you have full control over the Qt libraries it
> uses and when these are updated. I'm not 100% sure what that would require
> at the moment, though. It could mean building statically, or it could mean
> something else.
>
> So the bottom line: I do think we need support for this, but I think we
> should spend the time to find the right solution, so it's not likely to
> happen for the experimental version of the port we're planning to release
> with Qt 5.1. Since Ministro is well-tested and provides both a simple and
> working way of deploying and updating the libraries, imports and plugins we
> need, and it allows several apps to share the same binaries, so you avoid
> bloating the size of your app (which might a problem depending on how large
> your app is to begin with), I think it's a good solution for the first
> version of the port.
>
> -- Eskil
>
>
>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130111/483f91d4/attachment.html>