Hacker News new | past | comments | ask | show | jobs | submit login

The actual apk can be as small as 5-6mb, but yes it's too big. Ideally common files to all Kivy applications (the python runtime and libraries) would only exist once, but that's a problem people can't quite agree how to solve. https://github.com/kivy/python-for-android/issues/202



I'm pretty sure apps can have dependencies, so that looks like the best solution. Yes, users will be annoyed, but I think it's still better than various other "hacks".


QT has tried that on Android and it's an exceedingly poor solution. Almost no user will click to download additional files -- they've been (rightfully) conditioned to view this as a suspicious technique.

As long as you blacklist unneeded libraries on Kivy, you can get the size down to 5 - 10 MB. I personally don't believe this download size is such a problem for users (many native Java apps are upwards of 5 MB).

What is a problem is the start-up time and battery usage, both much harder problems to address. Because they require the Python interpreter, Kivy apps take significantly longer to start-up, and use significantly more battery power than Java apps. I have some hope that Micropython may eventually offer a solution to this for Python on Android, although porting Kivy to Micropython will be a major task.


I think startup time has good for very annoying, with android devices of 3 years go, to nearly forgettable, with more modern, high-end devices. I've witnessed nearly instant startups, with devices as the Note 2, not saying it's a solved problem, the cpu speed and even more the read/write speed of the internal storage will have a lot of impact especially on the first start (unpacking python and deps).

For battery usage, i'd love to see data for this, i think drain will come from the amount of action you put in your interface, as well as background processing you'll do, kivy itself, being opengl and cautious about what to update when changes happen, shouldn't add a lot of overhead on this.

I don't think porting to micropython is considered an option, usually, when we want more efficient code, the solution is to do less python, more C, we have a nice integration with Cython, and don't hesitate to go with it as soon as needed.


"has gone from" >_<.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: