Complete
2 months ago

Cannot get location of GARMIN weather for fenix8 series devices

Hi:

When I tried to get the location of GARMIN weather for fenix843mm, it seems that cc.observationLocationName is null. Both the simulator and real fenix8 devices reported the same issue. The SDK is 7.3.0.

Moreover, Users with other devices reported that they'd encountered the same issue after they upgraded their system of the watch.

Can somebody help on it? Thanks.

for example:

if(Toybox has :Weather) {
var currentConditions=Weather.getCurrentConditions();
if (null != currentConditions) {
// city
var cc = currentConditions as Weather.CurrentConditions;
var city;

if (null != cc.observationLocationName) {
var index = cc.observationLocationName.find(",");
city = (null != index) ?
cc.observationLocationName.substring(0, index) :
cc.observationLocationName;
} else {
city = "unknown";
}
}
}

yp
Parents
  • 2 months ago

    jim_m_58 I think you’re needlessly splitting hairs here, and in a way that wouldn’t make much sense if it were applied consistently to everything in the SDK / API (see below).

    I think everyone here already read what you quoted from Brandon.ConnectIQ and I think that they understand that the ultimate value is coming from the firmware, not literally from the SDK.

    Come to think of it, how many functions and members in the CIQ API are literally implemented in the SDK and only the SDK? If we use common sense, anything that would have zero dependency on firmware code or device state (as returned by firmware code) would not be very useful (it would pretty much have to be a constant or a no-op, right?) That’s not to say that there isn’t specific code that literally lives in the SDK and not the device firmware, just that nobody thinks the SDK exists in a vacuum with zero interaction with the devices.

    When ppl say that the SDK is behaving differently, they just mean that a existing function call or method in the API (as provided by the SDK) that used to work one way will now work another way. They don’t literally mean that the SDK and only the SDK has changed, or that the change was literally in the SDK (such that it worked one way in version X and a different way in version Y.) 

    It’s just like when a function or member is “deprecated in the SDK”, usually that means that the corresponding functionality is also going to be deprecated in the device itself as well.

Comment
  • 2 months ago

    jim_m_58 I think you’re needlessly splitting hairs here, and in a way that wouldn’t make much sense if it were applied consistently to everything in the SDK / API (see below).

    I think everyone here already read what you quoted from Brandon.ConnectIQ and I think that they understand that the ultimate value is coming from the firmware, not literally from the SDK.

    Come to think of it, how many functions and members in the CIQ API are literally implemented in the SDK and only the SDK? If we use common sense, anything that would have zero dependency on firmware code or device state (as returned by firmware code) would not be very useful (it would pretty much have to be a constant or a no-op, right?) That’s not to say that there isn’t specific code that literally lives in the SDK and not the device firmware, just that nobody thinks the SDK exists in a vacuum with zero interaction with the devices.

    When ppl say that the SDK is behaving differently, they just mean that a existing function call or method in the API (as provided by the SDK) that used to work one way will now work another way. They don’t literally mean that the SDK and only the SDK has changed, or that the change was literally in the SDK (such that it worked one way in version X and a different way in version Y.) 

    It’s just like when a function or member is “deprecated in the SDK”, usually that means that the corresponding functionality is also going to be deprecated in the device itself as well.

Children
No Data