BUG : Sys.getDeviceSettings().phoneConnected causes crash on vivoActive

Sys.getDeviceSettings().phoneConnected

doesn't work on vivoactive, causes a crash. Running 2.30. And _NO_ my vivoactive doesn't detect a later version!!!!!!

Come on Garmin lets have some bug fixes PLEASE!!!

PLEASE!

Pretty please!

Aw come on!

travis.vitek over 10 years ago

It is not a bug. You need to verify the member of the class is available before you reference it. That member didn't exist on older firmware, and if you run a program that attempts to access it, you'll get the documented behavior.

Have a look at this post and this thread.

Travis

ruperthawkes over 10 years ago

1. tdlr.

2. so cos of the discrepancy between the iq and the firmware I need to check every single class? Really? My code is going to look pretty messy soon! Surely Garmin should give us a chance at competing with Apple etc by giving us the info/sdk updates we need. How the hell can I keep a track of the iq/firmware/hardware matrix?

3. There was a 2.50 firmware for vivoactive but pulled. There is appearently a 2.40 firmware but appearently only available for some devices/regions. So I'm packing 2.30 on my vivoactive. Should I prefix all calls ?!? hmm.

We are in the dark with regards this stuff. My take on it is I am spending my time to help sell Garmin hardware, the very least they could do is give us the tools to help them sell kit.

travis.vitek over 10 years ago

If a some SDK feature was added, should be checking at runtime to see if it exists on the device. You know full well that the phoneConnected member was added in the ConnectIQ 1.1.0 SDK. Since there is a chance some firmware out there didn't have that feature, you have to add a check for it.

ruperthawkes over 10 years ago

You know full well that the phoneConnected member was added in the ConnectIQ 1.1.0 SDK. Since there is a chance some firmware out there didn't have that feature, you have to add a check for it.

Pah! Did I?

And so I now have to code for all discrepancies in the SDK/firmware? Is that how Apple treat their dev community? Perhaps. But is it right?

jim_m_58 over 10 years ago

Maybe this should be a feature request for the SDK folks, as I also didn't know that phoneConnected was just added in 1.1.0 (that's where I started).

What if, in the documentation for something like phoneConnected that's just been added, there be a note to indicate each device and the FW level where the support for it is in the VM? So for right now, it would say "vivoactive - not supported". Again, this is from a newbie perspective, that doesn't know when things get added or things that aren't commonly supported yet

The reason for this would be to avoid using "has" on methods that everything does have.

ruperthawkes over 10 years ago

Maybe this should be a feature request for the SDK folks, as I also didn't know that phoneConnected was just added in 1.1.0 (that's where I started).

What if, in the documentation for something like phoneConnected that's just been added, there be a note to indicate each device and the FW level where the support for it is in the VM? So for right now, it would say "vivoactive - not supported". Again, this is from a newbie perspective, that doesn't know when things get added or things that aren't commonly supported yet

The reason for this would be to avoid using "has" on methods that everything does have.

Exactly! Well said,

jim_m_58 over 10 years ago

feature request 2 - if something is developed needing a specific version of FW for a device, in the request for it to be placed in the app store, this data be used, to prevent someone from downloading an app/watchface/etc with FW that doesn't meet the minimum. Kind of like how google play doesn't allow you to download something to an Android 2 device that needs Android 4.

Brandon.ConnectIQ over 10 years ago

What if, in the documentation for something like phoneConnected that's just been added, there be a note to indicate each device and the FW level where the support for it is in the VM?

We actually have something like this already in place. For example, check out the constant definitions here:

http://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Attention.html

Is it perfect? No. I readily admit that we must do more with this, and it's in the works. One of my tasks is to help maintain which features are supported on various devices, and we're going to do what we can to automate this so it won't require a lot of effort for someone to keep updated. That said, I do think that using "has" is still smart. I understand not wanting to litter your code with checks, but it's hyperbolic to claim you'll have to check every class.

jim_m_58 over 10 years ago

@bandon, again I use a specific example - phoneConnected! As a newbie to the SDK, I have no idea what's been there from the first version of the SDK, or what is new, and what may need a "HAS"! With "phoneConnected", as a newbie, that is a call that should have been flagged, as it's easy to assume that it been there all along. You need to note methods (even just "new in sdk 1.x.0") so coders can look at using "has".