what we learned from the iOS testers so far...

[Dirk Hohndel]

> On Mar 25, 2016, at 9:11 AM, Robert Helling <helling at atdotde.de> wrote:
> 
> Hi,
> 
> my experience so far with the iOS version is twofold:
> 
> On my iPhone 6plus, where I installed the first version yesterday at the office, it works great (and now also the location does not save a fix every second).

We still get a fix every second, but I fixed the broken check that only SAVED the fix every <interval>. Yet Qt allows you to set the interval at which you GET the fix. But that isn't correctly implemented for iOS. Sadly that part of Qt is of course written in ObjectiveC. I've been staring at this module for the past 45 minutes and my eyes are bleeding, but I'm seeing several mistakes already. So I just kicked off a local Qt for iOS build from source so I can try and fix those bugs (and then submit those fixes for Qt 5.6.x)

> On my older iPhone 4s, I installed it only today. But now we are at the in-laws for the easter weekend, somewhere in the German countryside where the internet exists only in the 1Mbit/s variant. There I can start the app and it checks my credentials but then get stuck forever in downloading my divelist (I have no idea why it takes so long).

So you are experiencing the same things many people (Miika most vocally) have complained about. libgit2 does NOT appear to be as smart and fast when it comes to low-bandwidth situation as the git client. One of the key reasons why I picked git as the storage protocol was that the protocol itself tries to be super clever. This needs analysis by an expert. Thankfully I am taking an expert to a place that promises mediocre internet speed (Cozumel) next week, so there is hope that we can get some insights here...

> I should also mention that in order to compile the iOS version myself I upgraded my Qt from 5.5 to 5.6 (took several hours) and now I am in the situation that I cannot build at all (needs some more care to fix some paths).

Excellent. Not. So it seems that the desktop version is unhappy with Qt 5.6 because it requires webkit (but you can just turn of the manual and FB support for now).
If you have more specific questions about the magic it took me to create an iOS build... oh my. Yeah, that was a major pain. I'll try to document it better. It would help if you could tell me where you get stuck.

>> On 25.03.2016, at 16:47, Dirk Hohndel <dirk at hohndel.org <mailto:dirk at hohndel.org>> wrote:
>> 
>> More importantly, though, Qt 5.6.0 / qtlocation seems to have a number of issues on iOS: 
>> - regardless of the available hardware on the device, it always reports that satellite positioning is available - but then on devices without GPS / GLANOSS it just times out when trying to acquire a fix

OK, so there are two different issues at play here.
a) corelocation does indeed not tell you if it has a satellite source - so Qt simply claims all sources; but that's bogus - it could get a fix and look at the accuracy claimed and then make an educated guess
b) the bigger problem is that Qt does not check if it got access to location services at all. It requests them but then never checks. BAD Qt developers... this is one of the issues I'm intending to fix

>> - it doesn't respect the reporting interval that you set (so you get a new fix every second or even faster)

Still looking into this one. I know it's supported. And even better, corelocation supports "significant change" mode where everything stays asleep until you move more than a certain distance. That's definitely something I want to play with (even though there is no Qt API to use that at this point).

>> - even if you request position updates while the app is not in the foreground, you don't get those at all.

Another bug in Qt I believe. The corelocation mentions a specific API call you need to make in order to enable that and so far I haven't found that call in the sources, so this may be an easy fix. 

>> With all that, obviously on iOS Subsurface-mobile currently is not fit as a replacement for the iOS Subsurface companion app :-(
>> 
>> I'll look at the Qt sources to see if I can spot any issues, but we may need help here from some Qt experts. I posted on the Qt "interest" list, but based on the traffic there, iOS is not a platform that a lot of people work on :-(
> 
> I only now that there was a policy change recently regarding obtaining locations while in the background: Off the shelf, apps don’t get the permission but the user has to agree to it by clicking ok in some modal dialog.

Yes, that part I have implemented (it's basically an Info.plist setting where you state that you want this - and the request to get location data at all already works). It's the secondary permission to keep running in the background that requires two parts, one in the Info.plist (I have that) and one API call - and Qt isn't doing that call as far as I can tell.

I'll keep working on this... but my guess is this will take a while to get all sorted out.

/D

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160325/e215c1a4/attachment.html>