On 21 January, 2017 - Lubomir I. Ivanov wrote: > On 21 January 2017 at 20:44, Lubomir I. Ivanov <[email protected]> wrote: > > hello, > > > > On 21 January 2017 at 13:01, Anton Lundin <[email protected]> wrote: > >> On 20 January, 2017 - Dirk Hohndel wrote: > >> > >>> On Fri, Jan 20, 2017 at 05:06:40PM +0100, Tomaz Canabrava wrote: > >>> > > >>> > Other option is to try to make next Subsurface the Subsurface 4.7: > >>> > > >>> > Continue duplicating code for the Mobile version (that has a small > >>> > userbase > >>> > but will probabbly gain an increase of usage over the years) and > >>> > cleaning / > >>> > improving the Desktop version, changing things on the core as little as > >>> > we > >>> > need. > >>> > >>> Or, how about option 3: > >>> > >>> Forget about Subsurface-mobile. Wait a year for Kirigmi 7 that uses QML3 > >>> and and Qt.Slow.Conniptions.4 and then revisit if we want to waste another > >>> year of our time on something that more or less no one is interested in > >>> using. > >>> > >> > >> I'm still tempted to revive the branch where I bult subsurface-core as a > >> library with jni wrappers and build a UI in Android native java. > >> > >> There are enough competence and tutorials out there so almost anyone can > >> hack on a Android java app, and the "core" parts of subsurface, we > >> already know. > >> > > > > i haven't followed the mobile app much (+all the troubles surrounding > > it) expect that i filed a report of one nasty QML GridLayout bug at > > the Qt bugtracker at one point; it was a pretty bad showstopper. i've > > also found some more bugs in QML elements later. maybe QML and the > > frameworks for it are still not ready...but hmm, it has been at least > > 3 years since QML started advertising itself for mobile, so not sure > > what's going on that front. maybe Kirigami was bad choice here... > > > > other than that, i can help as much as time permits with the native > > Android UI as i've been doing exactly that the past couple of years. > > that native Android also has it's perks here and there, but it's quite > > good and easy to get into...of course, so as many probably know > > already - not a single UI toolkit is optimal. > > > > and i guess a native Android UI, would mean that a native iOS UI has > > to be written. > > > > above typos aside, i would like to quickly point out something about > multiplatform mobile development and the horror story it is. > > after many trials with my employer, trying pretty much everything from > A to Z which is available out there, free or payware to be able to > target both iOS and Android at the same time with a single UI toolkit, > in a sane matter, good programming language, without bugs etc, i've > come to the conclusion that - multiplaform mobile development is > (still) a myth. > > Xamarin, Adobe AIR, Qt + QML, Codename1, JS toolkits etc...all of them > are either buggy, awkward to use or have major limitations. > so for me ATM, the only sane way to approach mobile development is to > develop native UI.
I've bin playing with https://home-assistant.io/ a bit, and they are using a modern web-app as their frontend. It works okay-ish on mobile, and thats good enough for those needs, so I'd say for more limited applications, html5 / service-worker / manifest.json is a viable cross-platform option, but if you'd like butter smooth and great, native is the way to go still. //Anton - somewhat off topic but anyhow... -- Anton Lundin +46702-161604 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
