Does the patch number of the SDK align with the watch CIQ patch number?

Former Member
Former Member

Hey guys,

I'm new to the Connect IQ scene, so please forgive my ignorance here. I'm somewhat confused by the structure of the documentation on Garmin's site, it seems difficult to navigate, so it might just be my lack of experience with the documentation that has led me to ask this question.

I'm looking to develop watchfaces for Connect IQ that use version 3.2, and in the SDK manager I see there are three different patches (.1, .2, and .3). I was wondering, if I used CIQ SDK 3.2.3, would the user need to have the equivalent Connect IQ version on their watch?

If this is the case, would using 3.2.1 allow me to reach the most amount of devices since the other two patches are newer? Or is it only the major/minor numbers that affect software updates on the watch?

Thank you!

Edwin

  • The SDK version actually has little to do with the version of CIQ on a device.  With 3.2.3 you can build for all CIQ devices, be they  version 1, 2, or 3.  I use 3.2.3 to build for (literally) every CIQ device.

    You typically want to always use the latest SDK, as there are general bug fixes, and more.  There's a readme in the root of the SDK, with the change log of every version going back to the 0.0.1 SDK if I recall.

    With eclipse, there is a plugin, and that may or not match the SDK version (not all SDKs have a new plugin), but the current one is also version 3.2.3.

  • Former Member
    0 Former Member over 4 years ago in reply to jim_m_58

    Ah alright, that's great. 

    What drove me to this decision primarily was the weather API being available in 3.2. Since you can support every CIQ device with the latest version of the SDK, does that mean that I still need to do availability checks for the weather API within my code? If so, is there any way to prevent CIQ <3.2 devices from installing our software?

  • It's actually not that complex.

    In mc, you can do something like

    hasWeather=(Toybox has :Weather);

    and at runtime, see if you can use the 3.2 weather.

    You can also use jungles to define which of your code is used at compile time.

    I always find it interesting when someone uses "our". Is that like the royal "we"? Slight smile

  • Former Member
    0 Former Member over 4 years ago in reply to jim_m_58

    Yeah, that is what I was concerned about. We want to make weather a headline feature of our watchfaces, but we don't want to write our own weather implementation because we are concerned about connection reliability issues. I'd trust a Garmin API more than I would trust my own code getting through to the mobile app.

    I assume that this means I have to worry about every CIQ version equal to or above that of the lowest I am supporting, based on my supported devices list. Yikes for me!

    As for "our", I'd love to be royal, but it's actually just because we are a team of two. I am the developer (my name is Edwin) and my business partner is the designer (his name is Philipp). We've been developing faces since 2015, originally for Pebble, now for Fitbit. You can check our stuff out at www.Lignite.io

    Thanks for your help, by the way! You seem to be a legend of sorts on this forum. At the top of the Pareto distribution for biggest contributors, I'm sure ;)

  • There is a learning curve with CIQ, and it's more complex than pebble/fitbit, based on people I know that did both and now CIQ.  I started CIQ in early 2015 and may have forgot more than some people know!

    Start simple. as weather is a very basic thing.  For watch faces, there's much more, like custom fonts and 1hz. Weather (from an external source) is really not a big deal (a background service).  I've been doing it for years.  There are forum threads about these things.

    Also understand the environment.  You got a bunch of apps in the 1-2 million download category that are not only really full featured, but free.  Charging for an app can lead to bad reviews for no other reason, and based on the conference last week, it sounds like pay app will soon get a special mark that they are not free.

  • Former Member
    0 Former Member over 4 years ago in reply to jim_m_58

    There definitely is a learning curve, especially given the fact that the documentation is very scattered, and much of the information I have gotten has actually been from you or other users on old forum posts, lol.

    As for paid watchfaces, while we're making ours paid, we're not worried about the market already having competitors. That's part of what makes it fun! We'll have our own competitive edge in the market, just as we have had in the Pebble days and now in the Fitbit days. Regardless, I do appreciate the advice.

    Also, Fitbit made similar changes to their app gallery some time last year. Originally, you couldn't tell that a watchface/app was paid, and then one day they made everyone update their listings and displayed a clear payment banner on each paid listing (along with a required sentence or two about your cost in the description of your app).

    Despite all of that, them adding a clear indicator and the cost to each description made no impact whatsoever on our sales. 

    Not long after that, they made everyone put splash screens on all paid watchfaces which force the user to tap a button on their watch verifying they understand that they are using a paid watchface/app. We thought this would destroy sales. We were completely wrong - it seemed to have done nothing, or the change was so minuscule that it was not noticeable in regular day-to-day fluctuations of sales.

  • 1hz. (period, new sentence) weather!

    Your statement kind of proves how little you know about the Garmin app environment.  As I said, I really think you need to understand it better.

  • Former Member
    0 Former Member over 4 years ago in reply to jim_m_58

    Certainly, I know very little, just like I said in the beginning of my post. I don't really appreciate your snarky tone - it's sad to be starting a new venture only to be talked down to. 

    In any case, I'll see you around the forums mate. Thank you again for your help.

  • Former Member
    0 Former Member over 4 years ago in reply to jim_m_58

    Thank you, I already read through that post earlier today, including you blaming Kristof for using/manipulating his KiezelPay developers for his financial gain. I've known Kristof for years, and this isn't how he operates. 

    As for developers spamming the store: the same thing happens on Fitbit as well, so it's not new to me. In fact, it might even be worse on Fitbit given that their documentation is clean and simple and their apps are easier to build. We have to fight spammers on Fitbit too, and I'm up for the challenge yet again.

    To be frank with you, it almost comes across as though you want to discourage developers from building paid apps on the Garmin App Store. The negative messaging about us not being able to fit into the market, the snarky tone in your earlier message, and your first external link being to a discouraging post about spam on the store, all appears to be to be someone who doesn't want other developers to enter the market. 

    I only say this because you may not be aware with how your messages are coming across. I am not trying to attack you, I mean it with the best of intentions. Just my thoughts.