Support mobile platform (Android, iOS)

Issue #702 new
Former user created an issue

Do we have plan for support on mobile platform(Android, iOS ...) I see QML from 5.6 have support high-DPI scaling, so i think it possible to support on mobile platform where screen dimension is different.

Comments (12)

  1. Pol Welter

    We are not using QML, so this does not affect us.

    SC is not built for mobile platforms (neither from a technical stand point, nor usability-wise). SC is intended to be used via keyboard, not via touchscreen. There are mobile apps that do a much better job than what a SC port could possibly hope to do.

    @heldercorreia If you agree, maybe we should make this a 'won't fix'.

  2. Helder Correia repo owner

    I have double feelings about this. A mobile port has been in my head for 10 years now, way before all the mobile hype and cool modern devices. Also, porting the existing UI code to QML has also been in my horizon (something like Telegram Desktop), which would render a mobile port close to trivial. OTOH, @polwel is right about the main goal of SpeedCrunch. However, I can also see the value in having it available on a tablet, at least. This requires further thinking, I don't want to close the door to a mobile port as of yet.

  3. Mikko Syrjä

    Well, the mobile version exists. Sort of. Problem is that it is not made for Android or iOS, but Sailfish OS: https://openrepos.net/content/syrja/speedcrunch

    Application was originally created back in 2014 by other Sailfish user @qwazix. It was little bit primitive, worked well only in original Jolla phone and did not receive any updates for next four years.

    Few months ago I decided to learn QML/QtQuick programming. I had Sony Xperia X running with Sailfish, needed a good calculator application and liked SpeedCrunch. So, I forked the code and started changing code lines to see what happens. You know how this learning process works.

    I'm still novice with QML and QtQuick, but the application is already usable and users seem to like it. It does not support all desktop version features yet, but progresses quite nicely.

    Now, about Android. The original code written in early days of Sailfish OS was quite generic QML. It used some Sailfish specific things, but not too many. It may be possible to eliminate those parts and create initial Android port.

    So, I installed Android SDK with QtCreator and forked the code: https://github.com/mikkosyrja/speedcrunch-android

    It compiles, but displays currently just blank screen. QML code needs work. Probably lots of work. I may continue with it, but I don't have Android phone, don't know much about Android and, to be honest, have not much interest of it. OS and API versions seem to be quite mess.

    Anyway, that may work as a starting point. All we need is some adventurous person taking the challenge.

  4. qwazix

    I had also created a BB10 version of the app that IIRC did use only plain qml (I faked the appearance of BB10 in plain QML because cascades was wildly incompatible with meego components).

    I suppose that should be easier to adapt to android. I'm off base atm but I can have a look to find that source code.

  5. Mikko Syrjä

    Some kind of Android version exists now.

    I ended up taking C++ sources from Sailfish version and writing the QML part from scratch. SpeedCruch sources are from version 0.12.

    UI is based on Sailfish version with some modifications. For example, Sailfish version uses system popup notifications and label below edit field for messaging. These are not available in Android. Instead desktop-like popup field is used for for autocalc results and error messages. Menu implementations are also somewhat different.

    Application does not need any permissions and is self signed. So, it should work in most Android devices. It is build and packaged with with API level 16. As a Sailfish OS user myself, I don't have real Android phone. However, I have Nexus 9 tablet (Nougat) and old Jolla 1 phone with Alien Dalvik (Jelly Bean). These are only platforms tested, but everything above their versions and between their sizes (4.5 - 9 inches) should be fine.

    Does not work nicely in landscape mode. Landscape and portrait modes should have different keyboards. Currently portrait keyboard is just scaled to landscape mode. Also, because of bundled Qt libraries, it is unreasonably large package for a simple calculator application.

    Sources and some instructions: https://github.com/mikkosyrja/speedcrunch-android

    APK package download: https://github.com/mikkosyrja/speedcrunch-android/releases

  6. Helder Correia repo owner

    @syrja Just tried it out. Quite strange to use SpeedCrunch with such a UI, but a very good effort. Thanks!

  7. qwazix

    It's nice to see the mobile speedcrunch UI again :-) Already installed it and using it regularly.

    Thanks a lot.

  8. Mikko Syrjä

    I just added new release 0.2.

    This version contains localization support and there is now Transifex project for it.

    Current languages in project are en_GB, fi_FI, de_DE, it_IT, fr_FR, es_ES, ru_RU and sv_SE. Language selections are based on Sailfish version download statistics. Base language is en_GB and only fi_FI is currently translated.

    Few technical notes. I stole function and constant name translations from the desktop version. Android APK and Sailfish RPM packages contains full renamed desktop qm-files (speedcrunch.de_DE.qm, etc.), but only FunctionRepo and Constants context namespaces are actually used.

    All UI strings come from separate localization file. This is because some mobile version UI strings differ from desktop strings and because desktop translations are bound to source file names. Also, because Android and Sailfish source file names are currently different, I had to use id based translations ("id-insert-item" instead of "Insert Item").

    This Transifex thing is something new for me and I have no idea what kind of operations it supports. Would it be somehow possible to separate desktop UI strings from engine strings without too much manual work? Instead of single monolithic de_DE.qm there could be engine.de_DE.qm and desktop.de_DE.qm. I could then use just engine translations in mobile versions.

  9. Helder Correia repo owner

    @syrja > Would it be somehow possible to separate desktop UI strings from engine strings without too much manual work

    From the top of my head, I can't think of an existing way to do that. It may be possible with some QMake magic around the TRANSLATIONS variable, but I've never seen that before.

  10. Log in to comment