Simulator Bug when making web requests

Hi,

Not sure whether this is a known issue with the simulator (or perhaps the devices if you look at it that way), or if there's an item to fix this on the backlog, but the simulator does not behave in the same way as all the hardware when making web requests. Specifically, on the simulator, a request with params:

var params = {
"sort" => "date-desc",
"deviceid" => deviceId.toString(),
"formatForDevice" =>true
};

will generate a query string with

GET /api/routes/?deviceid=<mydeviceid>&sort=date-desc&formatForDevice=true HTTP/1.1" 200 922 "-" "Mozilla/5.0" "80.229.6.38"

on the simulator. It does the same on the vivoactive 3. On the physical Fenix it generates:

GET /api/routes/?sort=date-desc&formatForDevice=1&deviceid=<mydeviceid>

Note the 1 versus 'true' for the formatForDevice.

This may seem like a tiny bug but I just spent 2 days and various back and forth with a user trying to determine this was the cause of my app crashing on the Fenix. It also meant I had to pull the latest version of my app from the store while I worked it out.

It's not possible to detect this in testing because the simulator and the Fenix (at least) diverge and so without a physical device I can't prevent this.

Has anyone else seen this, and is it something that could be looked at by the team? I imagine it's a matter of the web library toString() having a different implementation on different devices. At the very least, could you replicate this behaviour in the simulator for the devices this affects so others aren't caught out. I could easily do this again without noticing.

Clearly the fix for my code is trivial (pass "true"); it's just knowing it's there that is tricky.

Worst case, is there a 'common pitfuls' document somewhere that could be shared?

Thanks

David

Travis.ConnectIQ over 3 years ago

Yes, there is an issue in the backlog about this. The keys and values in the params dict need to be String to work properly on all platforms/devices.

Dresbo over 3 years ago in reply to Travis.ConnectIQ

Thanks for confirming.

It might seem small but cost me 4-5 hours to unrelease the version, track it down by pestering someone with a real device to run it and test it for me. Then fix and release it, of course.

It obviously reflects badly on me with users as well as it looks like I can't release working software.

If I hadn't known someone able to test it for me I would have been totally stuck and left scratching my head. I'm honestly not sure what I would have done other than post it here.

If someone is able to advocate for fixing it I'm sure it will be much appreciated as it will prevent others from spending that time (and me from doing the same stupid thing again).

Alternatively, if you'd like to send me one of every device I can happily share my address with you

David

Dresbo over 3 years ago in reply to Dresbo

To be clear, just fixing the simulator behaviour would be enough. We could at least then recreate.

jim_m_58 over 3 years ago in reply to Dresbo

When Travis said it was in the "backlog", that to me indicates it's a known problem, just a lower priority. It could be a while.....

Have you looked into what he posted?

"The keys and values in the params dict need to be String to work properly on all platforms/devices."

The sim is a simulator, not a device emulator. There are things you won't see in the sim you'll see on a real device.

There can be things that also differ on a real device when it comes to Android/iOS/Wifi/LTE.

Do you have any Garmin devices to test with, or are you just using the sim?

Dresbo over 3 years ago in reply to jim_m_58

I would consider anything not in the current sprint(s) in the backlog? Is that not your take?. I agree that the only way to get it fixed is to have someone prioritise it.

There are lots of things to remember when writing software, and trying remember where your code is untestable is just more cognitive load. It's a little like not being able to compile it and having to spot your own syntax errors. Any divergence between the simulator and a real device is a pretty serious issue imo.

I have a vivoactive 3 and it doesn't exhibit this behaviour. The app works fine if you don't use strings. The Fenix behaves differently and diverges from the simulator. I agree It would be less of a problem if I could test and detect it on any device.

jim_m_58 over 3 years ago in reply to Dresbo

What you're seeing is very likely a difference between GCM on Android and GCM on iOS. When you do a makeWebRequest GCM is involved, unless you're using a Wifi connection (which is very common on Edge devices.

GCM on iOS has been the trickiest over the years (I've been doing CIQ for 6 years now).

You'll find a number of things that differ in the sim than on real devices. For example, widgets don't time out in the sim as they do on real watches. And for watch faces, you can stay in high power mode for days in the sim, where on real devices, they return to low power mode after about 10 seconds. I wouldn't consider either of these sim bugs, because if they ran like the real devices, it would be harder to test/debug.

As far as backlog, take a look at the bug report forum. You'll see bugs that have been open for many months. It's that they never get priority. The way to bump priority is to vote there.

Dresbo over 3 years ago in reply to jim_m_58

Interesting that it isn't the sim but the phone. I didn't consider that, but it makes sense because the person I got to test for me has an iPhone.

I do agree what you've highlighted are differences; I could accept that type, but crashing the watch is quite different.

Is there any way to simluate IOS versus Android connectivity. I wonder what the simulator uses under the hood. Do you know?

I'll take a look at the bug forum and upvote/report it.

jim_m_58 over 3 years ago in reply to Dresbo

post your code for the makeWebRequest call, including the params and options. One common error is trying to include params in the URL.

Dresbo over 3 years ago in reply to jim_m_58

I wasn't clear. It crashes the watch because it sends '1' rather than 'true' and it prompts a response that isn't correct, crashing the watch. Small issue with a significant result