Hi Dirk I didn't want to hurt anyone's feelings. I just asked and volunteered to spend time on this. More below
Regards, Guido +41 79 3217739 > Am 12.10.2015 um 19:05 schrieb Dirk Hohndel <[email protected]>: > > On Mon, Oct 12, 2015 at 01:56:49PM +0300, Miika Turkia wrote: >>> Does that mean that the dives I imported from my computer will never make >>> it into the iOS app? It sounds like as the workflow is >>> Log in iOS with gps >>> Sync with ssrf >>> Add meta data >> >> This is what we currently have. The iOS app only logs the GPS data and >> that is it. >> >>> Sync back >> >> This is currently not possible and it was never intended to occur with >> the existing iOS app. >> >>> Does not make sense to me at all and is not user friendly. >> >> Well, it depends. The current app is designed to only collect the GPS >> information and nothing more. For that it is easy enough to use, but >> it seems that most of the people are actually expecting more from it >> and thus the concept is hard to grasp. > > Yes - I learned that this amazingly useful app that I use on every single > dive trip appears to make no sense to a lot of people who simply have > convinced themselves that the app SHOULD be doing something else and then > when I try to explain the really cool thing that it does they don't even > listen and all they think is "but it doesn't do the thing that I WANT - > that's STUPID"... :-) I used it myself and it is useful but also misleading for someone that doesn't have all the details yet. > >>> Apparently I don't understand this.. Hence will try to find the >>> documentation and don't bother you guys any longer. >> >> Basically you should forget about the current iOS app for what you are >> thinking. Current one only logs GPS data, it is not the app you are >> thinking of :D > > Yes. Forget the COMPANION apps. We have a companion app for Android, we > have one for IOS. Neither are the ones that you are looking for. > >> We already have a prototype for Android of a mobile app that is able >> to sync the dives and display them on a phone/tablet. And this is what >> we are now discussing for iOS as well. If you want to take a look at >> the Android app, there are emulators on Android SDK where you can run >> the app. > > And that is the app we should use for IOS as well. > > The way this works is (roughly) like this: > > We run a big subset of the full Subsurface application on the mobile > device including a QML based mobile UI. Qt/QML are supported both on > Android and IOS. > > There's a little "glue" layer that integrates that native app into the > mobile OS. And THAT is the first step of what you should do and it makes > perfect sense to do that right now. Figure out how to create an IOS > wrapper for a native Qt/QML app. Send patches to add this to master. > > For Android we have a build script that allows you to build all the > dependencies using the android tool chain. My guess is we need this as > well as the "wrapper" or "glue" around Subsurface to make it launch on > IOS. > > I'd start reading here: http://doc.qt.io/qt-5/ios-support.html > > Did this make more sense and explain the direction I think this should be > going in? If not, keep asking... I'd hate for you to waste time staring at > the companion app and trying to figure out how to extend that to be what > you want it to be and I'd hate for you to waste time developing a new UI > when we already are working on a mobile UI in a framework that should > allow us to reuse the vast majority of that work on IOS as well. All makes sense. I would not have used the companion app btw, I would have started something from scratch. Now as I got all this useful replies I am glad I had asked and not started already. Using the android ground and the glue layer, would that not conflict with GPL? > > Thanks > > /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
