Connect IQ 1.2.0 SDK beta!

This morning we released a public beta of the 1.2.0 Connect IQ SDK! The beta SDK will allow developers to get their hands on the fun stuff we've been putting together lately, and gives everyone a chance to update their apps to take advantage of these new features. In addition to the SDK beta, there are also beta firmware releases for all current Connect IQ devices to include support for the 1.2.0 SDK. You can read about the details, as well as find links to the SDK and firmware downloads, over on our developer blog:

http://developer.garmin.com/index.php/blog/post/announcing-connect-iq-1.2

Just a couple of notes:
  • We've temporarily disabled the ability to build app packages via the App Export Wizard (which creates .iq files) to avoid 1.2.0 beta apps from making their way to the Connect IQ app store until we are out of beta. Developers will be able to create PRG files with the Build for Device Wizard, however, which can be side loaded for testing on devices. If you're planning any updates to apps that are on the store, and the updates don't require 1.2.0 SDK features, build with the 1.1.4 SDK so you'll be able to publish those updates to the app store.
  • If you plan on trying out the 1.2.0 SDK beta, please be sure update your Eclipse plug-in to version 1.2.0 by clicking the Help > Check for Updates menu item.
  • Via the eclipse plugin I am not getting any error. From Finder I get an error telling the Connect IQ app is not a valid app.

    Is also have this with sdk version 1.1.4.sdk version 1.1.3 does not have this problem


    What SDK is being used according to the SDK manager in Eclipse?
  • New icons for alarms and notifications already in place! (I've had the icons for some time, but no way to check the status for them)

  • For the beta vivoactive FW, I've noticed these changes in the firmware (they are NOT problems!)

    1) in "Settings", you can turn on/off vibrations when you lose or re-gain your BT connection to the phone.
    2) for CIQ apps, you no longer get the native lap screen or vibrations when addLap() is called, and no vibrations when you start/stop/save/discard a recording
  • Hi Brandon

    I don't think this is acceptable from Garmin to be doing this. 1.1.3 -> 1.1.4 already ate up memory - which we got was a bug but seems like it's a "feature". 1.2 further eats into memory and with 16kb for a datafield, going to 13.5kb is the max ceiling before out of memory happens.

    fix the memory usage please. Or do like what done for the Epix where it is increased to 1024kb (per the release notes)


    Absolutely agree. By 1.3 there will be no datafields able to run at this rate.
  • Absolutely agree. By 1.3 there will be no datafields able to run at this rate.


    Unless you need the new functionality, why not keep building a datafield with the 1.1.3 SDK? If it works, it will still work....

    In eclipse, it is easy to change what SDK you're using (windows>preferences>CIQ)

    You only need the newest SDK if you want to make use of the newest functions....

    I still have stuff I wrote using the first Microsoft C 32 bit compiler and it runs on Windows 10!
  • Unless you need the new functionality, why not keep building a datafield with the 1.1.3 SDK? If it works, it will still work....

    In eclipse, it is easy to change what SDK you're using (windows>preferences>CIQ)

    You only need the newest SDK if you want to make use of the newest functions....

    I still have stuff I wrote using the first Microsoft C 32 bit compiler and it runs on Windows 10!


    I'm not absolutely sure if the memory bloat reflects the build environment or the firmware you run under, but in my case datafields that run under 1.1.3 and are built with that FW do not work on devices with 1.1.4. In either case Garmin have announced that they will up-compile apps to use the latest version of the firmware available.
  • In either case Garmin have announced that they will up-compile apps to use the latest version of the firmware available.


    Un, No.. Garmin did NOT announce this! Unless they have your source code, they can NOT "up-compile" your code.

    What they said is if you support the F3, they will mark it so it's available for the D2 (basically the same device).

    There is still stuff in the app store that was built using a pre-1.0.0 SDK that hasn't changed.
  • Un, No.. Garmin did NOT announce this! Unless they have your source code, they can NOT "up-compile" your code.

    What they said is if you support the F3, they will mark it so it's available for the D2 (basically the same device).

    There is still stuff in the app store that was built using a pre-1.0.0 SDK that hasn't changed.


    That makes sense thanks. Still leaves the issue I have with 1.1.3 working datafields not running under FW1.1.4. Like: https://apps.garmin.com/en-US/apps/0f1c230f-7c4b-402a-a71b-b3a0b03ffd3b
  • That makes sense thanks. Still leaves the issue I have with 1.1.3 working datafields not running under FW1.1.4. Like: https://apps.garmin.com/en-US/apps/0f1c230f-7c4b-402a-a71b-b3a0b03ffd3b


    And like I said, so only build it using the 1.1.3 SDK! If you build it with 1.2.0, more stuff is "bound" in the .prg, which pushes your memory usage. It's NOT the VM in the FW that causes you problems, it's how you build it. You'll always have 16k for for .prg and data... (but with new "stuff", in a new SDK, your "stuff" will grow!)
  • And like I said, so only build it using the 1.1.3 SDK! If you build it with 1.2.0, more stuff is "bound" in the .prg, which pushes your memory usage. It's NOT the VM in the FW that causes you problems, it's how you build it. You'll always have 16k for for .prg and data... (but with new "stuff", in a new SDK, your "stuff" will grow!)


    I'll test again thanks.