Complete
11 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
  • 11 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.

  • 11 months ago in reply to myaro

    Understand this wasn't a change in the SDK, and the doc will just note that it's no longer available from the firmware.  You won't see the location name in the native weather widget either.  

    I saw it go from a valid name to null on a device without any changes to my app, including using a different SDK.  This a result of something outside the SDK or CIQ.

    Brandon did pass this on in this thread:

    "Without getting into too much detail, the location names we were receiving were often incorrect, so the product team has dropped support for the location name in firmware."

  • 11 months ago in reply to jim_m_58

    Agreed.  But as Daisy famously said in the Great Gatsby, "It takes two to make an accident".

    While it's true that developers should be prepared to handle all values the SDK sends (and it's a shame so many are so careless), it is also true that the SDK publisher  (Garmin) can improve the end customer's experience by notifying developers when some part of the SDK is going to start behaving very differently than it used to.  

    Beyond the crashes, there are so many watch faces that depend on getting that location string as a crucial part of the UI.  (None of mine do, but I feel bad for those developers getting blindsided)

    In another life, I build integrations for software like Salesforce, and they treat their developers very well by communicating changes well in advance.  It's delightful that they really treat developers as partners.  After all, if the integrations break, it is Salesforce customers that suffer.

    That brings me back to my main point: 

    We're all in this together go provide a great customer experience for the end users.

    That means developers should heed the SDK.  And Garmin can make this all better for the end user by communicating even more proactively about changes to the SDK.

  • 11 months ago in reply to myaro

    If this is causing apps to crash, that could indicate a bigger problem in the app.  Per the API doc, anything in currentConsitions can be null, so you want to null check everything.  For example, this has been in the doc for a long time:

    observationLocationName as Lang.String or Null

    This could vary based on where you are, time of day, date, etc, but the thing I see most often is the "feels like"  temperature is null

  • 11 months ago in reply to Shent-Aurkhan (SHN)

    We're all in this together go provide a great customer experience for the end-users.

    I just wanted to add another voice to:

    • Customers appreciate knowing the location where their weather comes from (to know how relevant it is), so fixing this vs. deprecating it would be ideal.
    • Devs would really benefit from getting notified by email of support dropping for parts of the API.  There are so many reports of crashed CIQ watch faces on Garmin reddit lately.  Perhaps this is why?

    I signed up to receive developer emails and I can' really remember receiving anything useful like information about API changes.  Am I missing something?