Connect IQ 2.3.2 is here! This version adds support for the D2™ Charlie aviation watch. With a rich array of color mapping, weather, waypoint reference and flight logging features, D2 Charlie sets the standard for on-wrist situational reference and backup navigation in your cockpit. The device is CIQ compatible with the fēnix® 5X, so make sure to support both devices.

Get the SDK today!

Simple Darksky! Waiting for approval right now, but here it is on the #fenix5

A post shared by Jim M (@jim.m.58) on Jul 7, 2017 at 7:30am PDT

This guest post was written by Jim Miller, a Connect IQ developer in Phoenix, AZ.

One of the new features in Connect IQ 2.3.x is background services, or the ability for a Connect IQ application to have a service that runs even if the main application isn’t running. Background services have different abilities than the main process; a watch face or data field that can’t do communications itself, but the background process can! The most common example of this right now is a watch face that displays weather information from the internet. When something happens in the background, that process can optionally prompt the user if they want to start the main application, or the background can just collect data for the next time the main application runs.

I’ll be talking about background services that take advantage of temporal events. In simple terms, it’s a process that’s time driven: it runs every “x” minutes, or can be set to run at a certain time. Temporal events can fire at most every 5 minutes, and will run at most 30 seconds each time it runs. The focus here will be on background processes that don’t try to start the main app when something happens, but just collect data for the main process.

I’ve created a very basic watch face with a background service on the developer forum and included a .zip of the project in the first post so you can see the code and try it out yourself. The watch face itself displays the time, and the last data seen from the background service (plus a counter, etc). And all the background does is return a string with an “hh:mm” timestamp. While it isn’t useful, it does show the basics of backgrounding with a temporal event. In this case, there’s really isn’t much in the View class, but the things to look at are in App class and the file with the background process - the ServiceDelegate.

When doing an app with backgrounding, there are a few things that come into play. In the sample project, you’ll see how these pieces all fit together.

The Background Annotation

To save memory, each time the background service runs only the necessary code is loaded. Background services have a 32 KB heap, so things can get tight! The (:background) annotation is used to indicate what classes, modules, and variables need to be available when the background service runs. The main App class is loaded by default, but you want to use the annotation on things like the ServiceDelegate and any things it may use or reference.

(:background)
class BgbgServiceDelegate extends Toybox.System.ServiceDelegate {

Using it doesn’t mean that it’s only in the background service; classes, modules, and variables will be available in both the main process and background process.

Service Delegate

A background service can be triggered by different kinds of system events: step goal achievement, sleep/wake times, and temporal events, which are discussed below. The ServiceDelegate allows you to define what your app should execute when these events occur. The AppBase.getServiceDelegate() is how the service delegate in your code is found. Use the methods in the Toybox.Background module to register your service to fire on given triggers.

Temporal Events

Background.registerForTemporalEvents() is used to set how often the background temporal event runs. In the sample code, I do it as part of AppBase.getInitialView() after doing a check to make sure the app is running on a device that supports backgrounding.

        //register for temporal events if they are supported
    	if(Toybox.System has :ServiceDelegate) {
    		canDoBG=true;
    		Background.registerForTemporalEvent(new Time.Duration(5 * 60));
    	} else {
    		Sys.println("****background not available on this device****");
    	}

Background.deleteTemporalEvent() can turn off the background process if desired. With a combination of those calls, you can get a bit of control over when a temporal event runs. For example, you can do things like not starting the temporal event until there is a connection to a phone, deleting the temporal event when your app no longer needs it, etc. Note: Normally when you have started a temporal event process, it will run even when the parent app isn’t running. With watch faces only the temporal event for the currently selected watch face will run.

With some temporal events, you may want to pass an error status back to the main process instead of data. A good example of this would be a background service that does communications. In many cases, you will be passing back the data you received (I often just pass back the dictionary from the callback), but in the case of an error, I just pass back a Number representing the error. Then in AppBase.onBackgroundData(), I use instanceof Number to check if I got data or an error, and handle the error or data as needed. Here’s a simple example of that:

function onBackgroundData(data) {
    if(data instanceof Number) {
        //indicates there was an error, and “data” is the error code
    } else {
        //got good “data”
    }
}

Interprocess Communication

You pass data from your background service to the main process using Background.exit() in your ServiceDelegate

    function onTemporalEvent() {
    	var now=Sys.getClockTime();
    	var ts=now.hour+":"+now.min.format("d");
        Sys.println("bg exit: "+ts);
        //just return the timestamp
        Background.exit(ts);
    }

AppBase.onBackgroundData() is how the main process gets the latest data from what the service returned by Background.exit(). In the main process, when it first starts, I’ll see if data is in the object store, and if so, then you display that as a “last known value”. If you don’t do something like this with a watch face, each time you leave the watch face and come back, there wouldn’t be any data until the background runs again.

    function onBackgroundData(data) {
    	$.counter++;
    	var now=Sys.getClockTime();
    	var ts=now.hour+":"+now.min.format("d");
        Sys.println("onBackgroundData="+data+" "+counter+" at "+ts);
        bgdata=data;
        App.getApp().setProperty(OSDATA,bgdata);
        Ui.requestUpdate();
    }

You can’t use AppBase.setProperty() in the background process to pass data in the object store or settings; if you try, an exception is thrown. You also can’t pass information between the main process and the background with global variables. The word “process” is important here: global variables are per process, so the same global is only global for that process. A variable defined globally exists in both the main process and background process, but each maintains its own copy and they’re never synced.. That been said, the only way to pass data from the main app to the background service is as a property. Your ServiceDelegate can retrieve it with AppBase.getProperty(). It can be something in the object store or from settings. Make sure to handle the case where the background may not have the data it needs here, as there are things that may not yet have valid values.

The background can run more than once before the main process sees it in AppBase.onBackgroundData(). The main process only sees the last one, not all of them, but in the background process you can use Background.getBackgroundData() to get what’s currently queued for the main process, but not yet delivered. You can combine that with what the background process has that’s new, and return it all.

Other Points

• Watch Faces - Watch faces are a bit different than other app times when it comes to if/when a background service runs, and this is by design. The background service for a watch face will only be run if that watch face is the “active” watch face (the one currently selected to be used). Think of the case where you have two watch faces installed, that both get weather data from the same source, with a limit on requests per day. There’s no reason for the background service for the non-active watch face to run, as it would just use up the quota of requests per day.
• Size of response to makeWebRequest() calls - If you are doing Communications.makeWebRequest() calls in your background process, one thing to keep in mind is the size of the response you get back. The background process has limited memory. When a response is received, there must be enough memory to contain both the response and to build the dictionary passed back to your callback.

• Notes about the Simulator: - You can test backgrounding in the simulator. In the case of temporal events, they will occur as scheduled, but under the “Simulation” menu, you can trigger the background process to run.

  There is a known issue with the simulator with background apps: the simulator will run the background services of apps you’ve tested in it, even if it isn’t the “active” app being tested. So if you are testing “app a” and then switch to “app b”, the background for “app a” will run as well as the background for “app b”. Even if your current target doesn’t have a background service the simulator may attempt to start it. The Connect IQ team is aware of the issue and will address it in a upcoming release

A Few Examples of Backgrounding

I currently have two watch faces in the app store that use backgrounding to get weather info from DarkSky.net -

• Simple Big - This is basic Simple Big, but it will also display the latest temperature if the API key is set (and the phone connection exists)
• Simple Darksky - In this case, it’s a watch face all about the weather. With the API key set, it will display the temperature, the humidity, and barometer, as well as a summary of the weather condition, and a timestamp as to when the data seen was obtained.

Here are some other apps that are using background services:

• DS Weather Widget - It’s not just for watch faces! The DS Weather Widget, uses backgrounding on watches that support it, but also runs on watches that don’t. Since Communications can be done in any widget, when the user runs the widget, if there’s no data, a request for that data is made in the main process using the same code as the background process uses. On watches that support backgrounding, there is a background process, so that current data is available as soon as the widget is run, with no delay! If needed, the main process will also turn on GPS long enough to get a location if the widget hasn’t learned the location yet or if the user has changed locations and would like to start getting data for that new location (requires a button press).
• HermoT’s TidalFace - This watch face is a unique one due to the data source: you can get tide data right on your watch face!

As you can see, background services are a powerful new addition to the Connect IQ toy box. They allow your app to periodically poll the internet for information, including watch faces and data fields. What can you use them for?

About The Author Jim Miller is a Connect IQ developer in Arizona. “In early 2015, I had a forerunner 15, and liked the GPS and step tracking. Then the original vívoactive was announced, and I pre-ordered it, and downloaded the CIQ 1.0.0 SDK the same week!” You can see his apps on the app store and find him on Instagram, his Connect IQ Facebook Page, or on the Connect IQ forums.

The Approach® S60 is a beautiful golf watch, complete with 40,000 pre-loaded golf courses, AutoShot game tracking, and touch screen display. The device is a great addition to the Connect IQ device lineup, and is worthy of porting your app to. There’s another great reason you should consider porting your app to the Approach S60, but we just can’t tell you.

Yet.

Look; this is killing us. Maybe we can hint at it: remember “square watch” and “round watch” from the preview SDK’s, and how they turned into the vívoactive® and the fēnix® 3? Maybe it’s like that, maybe it isn’t; like we said we can’t tell you. Or how about this: eviceday ompatibilitycay.

Ugh, this is frustrating.

In summary, if you haven’t ported your app to the Approach S60, you should think about it; first because it’s a great Connect IQ wearable, and second because…. nope, we can’t say. But we want to.

Connect IQ 2.3.3 is here! This releases adds support for the exciting new products Garmin introduced this week:  the vívoactive® 3 and the Edge® 1030. Get excited - these devices are hot.

The vívoactive 3, which we eluded to in a previous post, re-invents the vívoactive family. All of the features you love from the vívoactive - long battery life, Garmin Elevate™ wrist heart rate, Connect IQ - are now in a beautiful round body that looks appealing on men and women. Your apps will look stunning on its round 240 x 240 pixel touch screen. The user interface has been revamped to be more touch-centric; in fact, the device now only has one button. While a lot has changed, it is still very much a Connect IQ compatible product. Look for an upcoming developer post about how to adapt your app for the vívoactive 3.

The Edge 1030 is the most powerful Edge yet. It features a 3.5” capacitive touch display, GPS/GLONAS positioning, altimeter, and supports ANT+ and BLE sensors. The product also steps up the navigation capabilities, including the introduction of on-device popularity routing. This is the top of the line device for your cycling apps.

You know you want your apps on these devices. Get the SDK today!

While the vívoactive 3 is a complete revamp from the vívoactive HR, it is still a Connect IQ device through and through. Here are some tips and tricks for adding vívoactive 3 support to your Connect IQ app.

Round is the New Black

If you are seeing a pattern with the fēnix® family of products, the Forerunner® 935, the Approach® S60, and now the vívoactive 3, it is not coincidence: Garmin likes round watches. We like them because they look like watches instead of “wearable technology”. Yes, a rectangular display can hold more information, and yes, our devices capture and display much more information than a traditional wrist watch, but if it does not look good on the user’s wrist none of that matters.

Watch Faces

Watch faces work the same on the vívoactive 3 as they do on the fēnix 5 and the Forerunner 935. The vívoactive 3 supports always active watch faces as well, meaning your custom watch faces can stay always on and update every second while still having industry leading battery life.

Data Fields

When using three or more data fields on the vívoactive 3, the top and bottom fields are much smaller and designed for metrics that can be represented in simple terms, and the vívoactive 3 will not allow users to place Connect IQ data fields into the top/bottom areas. Otherwise, your data field should run just fine on the vívoactive 3.

Device Behaviors

The vívoactive 3 is our first one button watch. The button is used for start/stop, and there is no physical “back” button. The BehaviorDelegate will map a number of screen actions to behaviors:

• Right swipe is now Back
• Hold on the screen is now Menu
• Swipe up and down is now Previous and Next page

If your app currently overrides the above actions (right swipe, hold, or swiping up and down), they will interfere with the native actions of the vívoactive 3. If you are using the BehaviorDelegate to capture menu and back behaviors, your app will work without modification on the vívoactive 3.

Use Selectables, Menus, and the Picker

Make sure to take advantage of Menus and the Picker. These will always adapt to the native look and feel to the device and take advantage of input changes.

The vívoactive 3 has a capacitive touch screen that you can take advantage of. The Selectables and Buttons framework, introduced in Connect IQ 2, makes it easy to design an interface that can be used by both touch and button products. At the Connect IQ Summit we gave a presentation about how to use Selectables and Buttons when designing your user interface.

This is a guest post written by Achim Seufert.

You probably have already seen them all over GitHub; these fancy little badges indicating among other things that a project’s build-process is or . Check Bootstrap‘s main-page for example:

They’re pretty much becoming a standard for projects using build-tools like Maven, Gradle, npm, etc. The badges actually aren’t a feature of GitHub itself, but originate from services like TravisCI, AppVeyor, or David. The README files of GitHub projects, usually plain Markdown-files being rendered to HTML, simply point to automatically generated images provided by these services.

In this tutorial I’ll show you how to use TravisCI to build and track status of your Connect IQ project.

Getting Started

TravisCI is a free-of-charge continuous-integration-service for open-source projects that seamlessly integrates with your GitHub repository. Whenever you push some changes to your repository, TravisCI will fire up a fresh VM which can run a set of tasks which usually include compiling your code, executing unit-tests, packaging, and so on. Furthermore there’s a wide variety of options that let you define notifications being sent from TravisCI in case one of these tasks will fail or behave in an unexpected way. Our goal should be to have TravisCI build and package a Connect IQ-app and visualize the outcome of these tasks with either passing or failing.

Building via the Command Line

At this point I’m assuming that you already have created a GitHub repository containing your Connect IQ project. The most important task is getting our app built and packaged via command line instead of using the Eclipse Plugin. This can be achieved by invoking the Monkey C compiler through the monkeybrains.jar library which can be found in the bin-folder of your Connect IQ SDK. We also have to keep in mind that this should run on a UNIX-based console, since TravisCI starts a Linux-VM for us. As a side note it’s good to know that TravisCI is stateless, meaning you don’t have to worry about cleaning up your environment after a build; you’ll get a fresh VM every time a build gets triggered.

Our compile/package command should look something like this:

java -jar "${MB_HOME}/bin/monkeybrains.jar" ${PARAMS} ${SOURCES}

 
We basically just use Java and execute the JAR’s main-class, passing in some params and sources. In order to make things a bit more generic and convenient, I’ve created a shell-script (mb_runner.sh) which wraps the calls to the monkeybrains.jar. Place it in your project root alongside the manifest.xml. The params are built automatically; source and resources will also automatically be found and passed over. Finally, the script can also be used to package the app. Compiling and packaging an app requires a “Developer Key” (see the Getting Started in the Programmer’s Guide).

The three things the script needs in order to run are:

1. The MB_HOME environment variable to be set and pointing to your Connect IQ SDK
2. The MB_PRIVATE_KEY environment variable to be set and pointing to your private key
3. A file called mb_runner.cfg, also residing in your project-root, which contains a few details specific to your app. Check out the mb_runner.cfg.sample and adjust the settings to fit your needs.

If you want to see more details about mb_runner read the README.md. Running the following will build and package your app:

./mb_runner.sh package

Prepare the Project/Repository for TravisCI

There are three more things to do:

1. Create the .travis.yml config file in your repository-root
2. In your repository root you’ll need to create a simple shell-script travis.sh in which we’ll be preparing/invoking the mb_runner script
3. Link your repo with TravisCI

The .travis.yml file should look like this:

language: java

jdk: oraclejdk8

before_script:
    - sudo apt-get install -qq dos2unix
script:
    - ./travis.sh

Here we simply tell TravisCI to use a default Java environment (with Oracle’s JDK8 installed), install the required dos2unix package, and run the travis.sh shell script shown below. This will prepare our freshly created VM-environment so we can run our actual MonkeyC-compile-job:

#!/bin/bash
# travis.sh script to

SDK_URL="https://developer.garmin.com/downloads/connect-iq/sdks/connectiq-sdk-win-2.2.4.zip"
SDK_FILE="sdk.zip"
SDK_DIR="sdk"

PEM_FILE="/tmp/developer_key.pem"
DER_FILE="/tmp/developer_key.der"

###

wget -O "${SDK_FILE}" "${SDK_URL}"
unzip "${SDK_FILE}" "bin/*" -d "${SDK_DIR}"

openssl genrsa -out "${PEM_FILE}" 4096
openssl pkcs8 -topk8 -inform PEM -outform DER -in "${PEM_FILE}" -out "${DER_FILE}" -nocrypt

export MB_HOME="${SDK_DIR}"
export MB_PRIVATE_KEY="${DER_FILE}"

./mb_runner.sh package

As you can see, we’re downloading/extracting the Connect IQ SDK, generating a new private key for compilation/packaging, and setting the environment variables accordingly before running the mb_runner script.

After committing/pushing the three new files (mb_runner.sh, mb_runner.cfg, .travis.yml) to your repo you can finally link it to TravisCI as a final step. Just head over to the TravisCI homepage and log in using your GitHub credentials. Navigate to your account-settings and simply select the repository you want to activate.

And that’s it!  From now on every new commit/push to your repository will trigger TravisCI and compile/package your app. If any build errors occur when committing a change you’ll get notified about it.

Adding Badges to the README

As a reward for our hard work we now can decorate our repository’s main page by adding the status-banner. Replace `[username]`, `[reponame]`, `[branchname]` with values that fit to your project:

![Build Status](https://travis-ci.org/[username]/[reponame].svg?branch=[branchname])](https://travis-ci.org/[username]/[reponame])

Of course you can put up an extra banner for each branch (master, development, etc.) you have.

Including a Companion App

If you happen to have an Android or iOS companion app along with your Connect IQ app, you could easily combine the build-process of both apps. If you’re having an Android app for example, then you’ll want to have it built by TravisCI as well. Since you’re already booting up a fresh Java-environment for this, you can just run your Connect IQ app build immediately afterwards. TravisCI will then return a combined result of both jobs meaning, if one fails then it will be an overall failure.

For such a case, the .travis.yml file could look something like this:

language: android

jdk: oraclejdk8

android:
  components:
    - tools
    - platform-tools
    - tools
    - build-tools-25.0.2
    - android-25
  licenses:
    - android-sdk-license-.+
    - '.+'

before_install:
    - mkdir "$ANDROID_HOME/licenses" || true
    - echo -e "\n8933bad161af4178b1185d1a37fbf41ea5269c55" > "$ANDROID_HOME/licenses/android-sdk-license"
    - echo -e "\n84831b9409646a918e30573bab4c9c91346d8abd" > "$ANDROID_HOME/licenses/android-sdk-preview-license"

# the following part will be used to perform a compile-/package-run for the ConnectIQ-app;
# afterwards we change into the "android"-subfolder and continue with the standard Android Gradle-build
before_script:
    - sudo apt-get install -qq dos2unix
script:
    - cd ciq && ./travis.sh
- cd ../android && ./gradlew build

mb_runner Submodule

Instead of manually adding the mb_runner script to you project root, you also can include it as a Git submodule by running the following in your project root:

git submodule add https://github.com/4ch1m/mb_runner.git

This will create a mb_runner subdirectory, containing the mb_runner.sh file. You will still have to add/create a mb_runner.cfg file in your project’s root and adjust it to your needs.

Conclusion

Continuous integration has become a necessity of modern software project. Having TravisCI watch over your sources - ensuring that everything is still in a “buildable” state - makes commiting/pushing your code to the repo less frightening. Using the above techniques you can bring continuous integration to your Connect IQ GitHub projects.

Achim Seufert is a developer in Würzburg, Germany. Check out his GitHub and website.

Barrels, Jungles, and ANT, oh my!

Connect IQ 2.4 beta is here! Connect IQ adds new features to the Connect IQ SDK and some new device features.

Barrels

One of the most requested features from our developer summit was the ability to package code so it can be shared between projects, a la Ruby Gems or Python Packages. Monkey Barrels are the new Monkey C packages. They allow code and resources to be packaged into a shareable bundle that can easily be imported into other projects. Now you can put your shared libraries into their own projects, and make them easily available for others to use. We have added sample barrels to our github account for you to see how they work.

Jungle Boogie

Jungles are a domain specific language for managing build configuration through lazy evaluation of properties; easier put, it is Monkey Make. Unlike make tools that managing build dependencies, Jungles provide a tool for managing build configurations of multiple Garmin devices.

Here is a simple, but relevant, example. Remember that time when Garmin turned the
fēnix® Chronos into the fēnix 5s? Now there were two round 218x218 products unlike the others. If you wanted to support all round 218 x 218 products you needed to create and manage three resource directories; two of them are duplicates.

resources-round-218x218/layouts.xml
resources-fenix5s/layouts.xml
resources-fenixchronos/layouts.xml

With Jungles, you can rectify the situation with one line.

fenixchronos.resourcePath = $(fenix5s.resourcePath)

Now building for the fēnix Chronos will use the fēnix 5s resources. You can use resources-round-218x218 for fēnix 3, and resources-fenix5s for fēnix 5s and fēnix chronos.

One more example - lets say you are writing a wearable app that has different code for round versus semi-round versus rectangle layouts. Before you had to use build resources to specify the build paths, but with Jungles you can configure it in one place.

# Configure paths based on screen shape
round.sourcePath = $(base.sourcePath);source-round
semi-round.sourcePath = $(base.sourcePath);source-semi-round
rectangle.sourcePath = $(base.sourcePath);source-rectangle

Now round products will automatically add the source-round path, semi-round the source-semi-round, and rectangle the source-rectangle. Jungles can control source path, resource paths, excludes, annotations, and barrels. Barrels include Jungles inside for their own build configuration, allowing them to have separate build configuration from the parent project. Jungles make it much easier to manage project build configuration in one place.

Running Dynamics and FE-C

Connect IQ 2.4 adds access to the Running Dynamics ANT+ profile for the Forerunner® 735xt, Forerunner 935, quatix® 5, and fēnix 5 family; and the FE-C profile to the Edge® 520, 820, 1000, and 1030.

Getting Started

To get started with the new beta, follow these instructions:

1. Because we have a beta version of the Connect IQ Plug-in, we encourage developers to download a fresh installation of Eclipse Oxygen for Java Developers. This separates your beta and production Connect IQ environments.
2. In the top menu, go to Help > Install New Software
3. Use the Add… button to add https://developer.garmin.com/downloads/connect-iq/beta/eclipse/
4. Check the box next to Connect IQ in the list and hit Next
5. Dependent plug-in modules may need to be downloaded and installed. When this is complete, restart Eclipse to complete the installation.
6. Use the steps from the Programmers Guide to configure the plug-in
7. Use Connect IQ > Open SDK Manager to get the latest SDK

We have betas available for the following devices:

• fēnix 5
• fēnix 5s
• fēnix 5X

We are excited to see what you think! We’ll be updating the blog with firmware betas for Connect IQ 2.4; check back to see if we’ve added support for your device.

Connect IQ 2.3.5 is here! This SDK adds support for the upcoming Descent™ Mk 1 dive watch. The Descent is the first watch-sized dive computer to offer surface GPS navigation with full-color onscreen mapping and location reference. Note that for user safety, Connect IQ functions are not available while diving, so we can ensure that all dive capabilities are functioning as they were designed.

Get the SDK to make your app available for the Descent!

We have already discussed the big features in Connect IQ 2.4, but we didn’t stop there; there are some other enhancements we made under the hood. These tweaks address some long-standing Connect IQ design decisions that have been holding back developers since version 1.0.

More Objects

Because Connect IQ devices may not have a memory management unit, the Connect IQ heap is designed to be self contained within a contiguous region of memory, and uses memory handles to track of addresses in the heap. What’s a memory handle you ask? You mean you never had to use GlobalLock to lock your Win16 memory handle? No? Well never mind then; if you need me, I’ll be crying about my wasted youth.

In previous versions Monkey C had a maximum of 512 memory handles. Any created object (except numbers, floats, booleans, and symbols) would count against both memory handles and heap space. This meant that on an Edge® 1000, which has 1 MB heap for Connect IQ apps, you could run out of memory handles well before you ran out heap memory. The 512 handle limit also meant we generally discouraged developers from using objects for pretty much anything.

In Connect IQ 2.4 the virtual machine will dynamically allocate handles when you are running low. Now new is your friend! Make everything a linked list! Now you just have to worry about running out of actual memory and not bookkeeping memory!

More Storage

Before we begin, it might help to have a refresher on what kinds of content are persisted to the file system.

• Properties are constant values defined at build time in the resource property block. They are useful for product specific constants that shouldn’t be defined in code.
• Settings are values that are user-editable through Garmin Connect Mobile
• Storage are values that the application wants to persist across execution. They are written to disk

Since 1.0, application storage has been implemented as a dictionary, and this had a double cost to the developer. First, the dictionary lived at run time inside the developer heap, so storing any content would cost against your available heap. Second, the dictionary has a serialized size limit of 8 KB, and if the storage crossed over that limit it would not be written to disk. Double-whammy!

In Connect IQ 2.4 we introduce the Application.Properties and Application.Storage modules. Application.Properties provides an interface for accessing the values of properties and settings. Storage provides a new interface for persisting keys and values. Values persisted using Storage use a new on-disk database. Keys and values in the database are limited to 8 KB, and storing a value no longer costs against your heap usage! Even better, you now have 128 KB of storage - more memory than I could have imagined in my childhood!

If you are developing on a 2.4 compatible device, Storage offers a superior solution for persisting application data. It is important to note that this API will only be on Connect IQ 2.4 devices and above. If you’re trying to maximize the number of supported devices, use a Toybox.Application has :Storage check to see if the Storage API is available. Data stored using Storage will not be auto-migrated from data stored using AppBase to retain backwards compatibility.

You’re now free to create more objects and store more data!

Since its launch in 2015, the Connect IQ store has grown from ten apps to thousands, and has users around the world downloading content. We know that the store is an important place for featuring your brand, and we are excited to give you a preview of what will be coming next year.

Improved Discoverability	Native Mobile Experience	Localized Hero Images
The front page of the app store has been reworked to improve discoverability for your apps. New categories will highlight apps, and real estate at the top of the page will feature apps for every device.	The app store is being upgraded from a web view to a native experience. Navigating the store will be smoother than before, and your content will look better than ever.	The app store will let you have hero images for your apps. These hero images can be tailored for each locale, allowing you to get your message out in every language. If you choose not to create hero images, the app store will use a default treatment for your app icons.

The app store will be accepting hero images with app descriptions in the near future. Along with these changes, we are publishing new guidelines for creating icons and hero images for your apps. These guidelines are to help you create great looking apps for the store. The store will be launching in Q1 of 2018, so now is the time to get your assets ready for launch.

It’s here! It’s here! Here is a quick summary of the new features:

• Barrels - Our new mechanism for packaging, sharing, and importing code libraries
• Jungles - Our new build tool to simplify build configuration across multiple products
• FE-C - New AntPlus classes for reading FE-C on Connect IQ compatible Edge® products
• Running Dynamics - New AntPlus classes for reading running dynamics information on Connect IQ compatible wearable products
• More Objects - Dynamic memory handles allow more objects in your apps
• More Storage - New mechanism allowing more persisted storage for your apps

Many of these changes come from feedback we heard at the Connect IQ developer summit. These features give developers powerful new tools to make apps for the ever growing list of Connect IQ devices.

Get the SDK today! While you are at it, check out some of the upcoming changes to the Connect IQ store.

Simple Darksky! Waiting for approval right now, but here it is on the #fenix5

A post shared by Jim M (@jim.m.58) on Jul 7, 2017 at 7:30am PDT

This guest post was written by Jim Miller, a Connect IQ developer in Phoenix, AZ.

One of the new features in Connect IQ 2.3.x is background services, or the ability for a Connect IQ application to have a service that runs even if the main application isn’t running. Background services have different abilities than the main process; a watch face or data field that can’t do communications itself, but the background process can! The most common example of this right now is a watch face that displays weather information from the internet. When something happens in the background, that process can optionally prompt the user if they want to start the main application, or the background can just collect data for the next time the main application runs.

I’ll be talking about background services that take advantage of temporal events. In simple terms, it’s a process that’s time driven: it runs every “x” minutes, or can be set to run at a certain time. Temporal events can fire at most every 5 minutes, and will run at most 30 seconds each time it runs. The focus here will be on background processes that don’t try to start the main app when something happens, but just collect data for the main process.

I’ve created a very basic watch face with a background service on the developer forum and included a .zip of the project in the first post so you can see the code and try it out yourself. The watch face itself displays the time, and the last data seen from the background service (plus a counter, etc). And all the background does is return a string with an “hh:mm” timestamp. While it isn’t useful, it does show the basics of backgrounding with a temporal event. In this case, there’s really isn’t much in the View class, but the things to look at are in App class and the file with the background process - the ServiceDelegate.

When doing an app with backgrounding, there are a few things that come into play. In the sample project, you’ll see how these pieces all fit together.

The Background Annotation

To save memory, each time the background service runs only the necessary code is loaded. Background services have a 32 KB heap, so things can get tight! The (:background) annotation is used to indicate what classes, modules, and variables need to be available when the background service runs. The main App class is loaded by default, but you want to use the annotation on things like the ServiceDelegate and any things it may use or reference.

(:background)
class BgbgServiceDelegate extends Toybox.System.ServiceDelegate {

Using it doesn’t mean that it’s only in the background service; classes, modules, and variables will be available in both the main process and background process.

Service Delegate

A background service can be triggered by different kinds of system events: step goal achievement, sleep/wake times, and temporal events, which are discussed below. The ServiceDelegate allows you to define what your app should execute when these events occur. The AppBase.getServiceDelegate() is how the service delegate in your code is found. Use the methods in the Toybox.Background module to register your service to fire on given triggers.

Temporal Events

Background.registerForTemporalEvents() is used to set how often the background temporal event runs. In the sample code, I do it as part of AppBase.getInitialView() after doing a check to make sure the app is running on a device that supports backgrounding.

        //register for temporal events if they are supported
    	if(Toybox.System has :ServiceDelegate) {
    		canDoBG=true;
    		Background.registerForTemporalEvent(new Time.Duration(5 * 60));
    	} else {
    		Sys.println("****background not available on this device****");
    	}

Background.deleteTemporalEvent() can turn off the background process if desired. With a combination of those calls, you can get a bit of control over when a temporal event runs. For example, you can do things like not starting the temporal event until there is a connection to a phone, deleting the temporal event when your app no longer needs it, etc. Note: Normally when you have started a temporal event process, it will run even when the parent app isn’t running. With watch faces only the temporal event for the currently selected watch face will run.

With some temporal events, you may want to pass an error status back to the main process instead of data. A good example of this would be a background service that does communications. In many cases, you will be passing back the data you received (I often just pass back the dictionary from the callback), but in the case of an error, I just pass back a Number representing the error. Then in AppBase.onBackgroundData(), I use instanceof Number to check if I got data or an error, and handle the error or data as needed. Here’s a simple example of that:

function onBackgroundData(data) {
    if(data instanceof Number) {
        //indicates there was an error, and “data” is the error code
    } else {
        //got good “data”
    }
}

Interprocess Communication

You pass data from your background service to the main process using Background.exit() in your ServiceDelegate

    function onTemporalEvent() {
    	var now=Sys.getClockTime();
    	var ts=now.hour+":"+now.min.format("d");
        Sys.println("bg exit: "+ts);
        //just return the timestamp
        Background.exit(ts);
    }

AppBase.onBackgroundData() is how the main process gets the latest data from what the service returned by Background.exit(). In the main process, when it first starts, I’ll see if data is in the object store, and if so, then you display that as a “last known value”. If you don’t do something like this with a watch face, each time you leave the watch face and come back, there wouldn’t be any data until the background runs again.

    function onBackgroundData(data) {
    	$.counter++;
    	var now=Sys.getClockTime();
    	var ts=now.hour+":"+now.min.format("d");
        Sys.println("onBackgroundData="+data+" "+counter+" at "+ts);
        bgdata=data;
        App.getApp().setProperty(OSDATA,bgdata);
        Ui.requestUpdate();
    }

You can’t use AppBase.setProperty() in the background process to pass data in the object store or settings; if you try, an exception is thrown. You also can’t pass information between the main process and the background with global variables. The word “process” is important here: global variables are per process, so the same global is only global for that process. A variable defined globally exists in both the main process and background process, but each maintains its own copy and they’re never synced.. That been said, the only way to pass data from the main app to the background service is as a property. Your ServiceDelegate can retrieve it with AppBase.getProperty(). It can be something in the object store or from settings. Make sure to handle the case where the background may not have the data it needs here, as there are things that may not yet have valid values.

The background can run more than once before the main process sees it in AppBase.onBackgroundData(). The main process only sees the last one, not all of them, but in the background process you can use Background.getBackgroundData() to get what’s currently queued for the main process, but not yet delivered. You can combine that with what the background process has that’s new, and return it all.

Other Points

• Watch Faces - Watch faces are a bit different than other app times when it comes to if/when a background service runs, and this is by design. The background service for a watch face will only be run if that watch face is the “active” watch face (the one currently selected to be used). Think of the case where you have two watch faces installed, that both get weather data from the same source, with a limit on requests per day. There’s no reason for the background service for the non-active watch face to run, as it would just use up the quota of requests per day.
• Size of response to makeWebRequest() calls - If you are doing Communications.makeWebRequest() calls in your background process, one thing to keep in mind is the size of the response you get back. The background process has limited memory. When a response is received, there must be enough memory to contain both the response and to build the dictionary passed back to your callback.

• Notes about the Simulator: - You can test backgrounding in the simulator. In the case of temporal events, they will occur as scheduled, but under the “Simulation” menu, you can trigger the background process to run.

  There is a known issue with the simulator with background apps: the simulator will run the background services of apps you’ve tested in it, even if it isn’t the “active” app being tested. So if you are testing “app a” and then switch to “app b”, the background for “app a” will run as well as the background for “app b”. Even if your current target doesn’t have a background service the simulator may attempt to start it. The Connect IQ team is aware of the issue and will address it in a upcoming release

As you can see, background services are a powerful new addition to the Connect IQ toy box. They allow your app to periodically poll the internet for information, including watch faces and data fields. What can you use them for?

About The Author Jim Miller is a Connect IQ developer in Arizona. “In early 2015, I had a forerunner 15, and liked the GPS and step tracking. Then the original vívoactive was announced, and I pre-ordered it, and downloaded the CIQ 1.0.0 SDK the same week!” You can see his apps on the app store and find him on Instagram, his Connect IQ Facebook Page, or on the Connect IQ forums.

Connect IQ 2.4.2 is here, with support for the Forerunner® 645 and Forerunner 645M. The Forerunner 645 is the most advanced running watch Garmin has made, featuring advanced running dynamics, Garmin Pay™, and an attractive slim form factor. The Forerunner 645M is our first wearable that lets you download music to the watch, and connects with Bluetooth® headphones (sold separately) for phone-free listening. Leave the phone at home!

In addition to letting you listen to your own music, the Forerunner 645M introduces the fifth Connect IQ app type: the audio content provider. Audio content providers act as plug-ins to the media player, and are allowed to download content to the device over Wi-Fi, serve content to the media playback system, as well as present user interface controls on the wearable for configuration and control. This represents a giant leap for Connect IQ .

Our music SDK is still under development, and is not included with Connect IQ 2.4.2. If you are interested in creating a Connect IQ media apps, please contact the Connect IQ developer program and let us know, or register for the Connect IQ Summit in April.

Get the Connect IQ 2.4.2 SDK today!

At the 2018 Connect IQ Developer Summit, we will be hosting an hour of lightning talks where you can present the cool tricks you use and the use cases you solve to the Connect IQ community. Presenters will have seven minutes per talk. Apply to give a lightning talk by providing your name, email, title, and abstract. You must be an registered attendee of the Summit to present. The deadline to apply is February 28th.

Apply to present a lightning talk today!

This guest post was written by Peter De Decker, a Connect IQ developer from Belgium. Peter is the author of several Connect IQ apps, he also wrote a set of Connect IQ tutorials and maintains the Garmin Connect IQ Fans Facebook fan page.

Garmin devices come in different shape and sizes, have different memory constraints, and have different levels of Connect IQ compatibility.  To be able to maintain different Connect IQ devices you can use the has functionality to test whether a certain feature is present on the device, but applying this technique too much makes the code unmanageable. You could also set up a Connect IQ project per device and copy/paste your code across your projects, but this is very labor intensive to keep your code in sync and is prone to mistakes.

Using one code base to handle all Garmin devices compatible with Connect IQ is easier than you think.  All you have to do is combine two core features of the Connect IQ framework: inheritance and jungles. Let’s see how these features help you to solve the issues that held us back.

Screen Geometry

One way to solve different size/shape issues is to use the layout system. This works perfect for watch faces as you have a lot of memory available there. In data fields, the memory budget is usually tight and as the layout system has a higher memory requirement, I got used to opting for using direct drawing on the dc object instead. I want to have the same benefits as the layout system though, as I might want a different layout on each device.

So how do we do this?

 
• Define a base class CommonLogicView where we handle all logic that we have to do on each device.
 
• Define a class called DeviceView for each device that we want to support. This DeviceView inherits from the CommonLogicView and implements the layout specifics for each device by drawing to the dc
 
• Define a jungle that picks up the right files for each device.

Let’s say that you’re trying to build for the original vivoactive and the Forerunner 735XT. These two products have different screen geometry and support different versions of Connect IQ. The picture below shows how the project will look like after this has been set up:

We create dedicated folders for each device family and configure the monkey.jungle in such a way that the right source files are picked up for each device:

project.manifest = manifest.xml

# fix autobuild to be a specific device
base.sourcePath=$(fr735xt.sourcePath)

# define the actual sourcePaths
vivoactive.sourcePath=source;source-vivoactive
fr735xt.sourcePath=source;source-semiround

The CommonLogicView is the base view. Here we handle all code that we can use in all the device implementations. It’s a pretty easy class, the main entry point into this class is the onUpdate function:

class CommonLogicView extends Ui.WatchFace {
    ...

    // this is called whenever the screen needs to be updated
    function onUpdate(dc) {
        // Common update of the screen: Clear the screen with the backgroundcolor.
        clearScreen(dc);

        // We can also do common calculations here, in this case we'll just get the current time
        determineClockTime();
    }

    // clears the screen and stores the width & height in global variables
    function clearScreen(dc) {
        ...
    }

    function determineClockTime() {
        ...
    }
}

The DeviceView is where we implement the specifics of the device, so for the Forerunner 735XT we could have something like this:

class DeviceView extends CommonLogicView {  // inherits from CommonLogic
    function initialize() {
        CommonLogicView.initialize();  // important to call the initialize of your base class, even when you have nothing to add…
    }

    function onUpdate(dc) {
        CommonLogicView.onUpdate(dc);

        dc.setColor(Gfx.COLOR_WHITE, Gfx.COLOR_TRANSPARENT);
        dc.drawText(width / 2, height / 2, Gfx.FONT_NUMBER_THAI_HOT, timeString, Gfx.TEXT_JUSTIFY_CENTER | Gfx.TEXT_JUSTIFY_VCENTER);

        dc.setColor(Gfx.COLOR_BLUE, Gfx.COLOR_TRANSPARENT);
        dc.drawText(width / 2, 140, Gfx.FONT_SMALL, "I'm Peter's favourite!", Gfx.TEXT_JUSTIFY_CENTER);
    }
}

For the vivoactive we have a similar file, but then implementing the specifics of the vivoactive:

class DeviceView extends CommonLogicView {
    function initialize() {
        CommonLogicView.initialize();  // important to call the initialize of your base class, even when you have nothing to add…
    }

    function onUpdate(dc) {
        // call the parent function in order to execute the logic of the parent
        CommonLogicView.onUpdate(dc);

        dc.setColor(Gfx.COLOR_WHITE, Gfx.COLOR_TRANSPARENT);
        dc.drawText(width / 2, height / 2, Gfx.FONT_NUMBER_THAI_HOT, timeString, Gfx.TEXT_JUSTIFY_CENTER | Gfx.TEXT_JUSTIFY_VCENTER);

        dc.setColor(Gfx.COLOR_PINK, Gfx.COLOR_TRANSPARENT);
        dc.drawText(width / 2, 110, Gfx.FONT_MEDIUM, "I'm a cool watch!", Gfx.TEXT_JUSTIFY_CENTER);
    }
}

When we run the code this results in the following in the simulator:

Full source code

Memory Constraints

The Forerunner 235 and Forerunner 735XT are both semi-round, but they have different memory limitations. For instance, in data field mode, the FR235 allows for 16K of memory, while the FR735XT has 26K of available memory to play with. That means we can pack 10K more goodies in the 735XT data field!

To do this we apply the same technique of combining inheritance and jungles:

In my Peter’s (Race) Pacer app I’m taking this technique to the extreme and have 4 layers of inheritance defined: CommonLogic, LayoutLowMemory,  CommonHighMemoryLogic, and LayoutHighMemory. All layers inherit from each other so that I don’t have to write a single letter of duplicate code. This allows me to support all combinations of Connect IQ 1.x and 2.x devices from a single code base, while getting the max out of the available memory for each device! 

Connect IQ Version Compatibility

We are treated with more and more features being added to the Connect IQ framework. Older devices can not be upgraded to Connect IQ 2 because they don’t have enough processing power and/or memory available. Luckily we can apply the same technique of combining inheritance and jungles to be able to use new Connect IQ 2 features in our projects while simultaneously also retaining support for users that have Connect IQ 1 devices.  Cool, eh?

Let’s demonstrate this with a sample project. I’m going to extend the watch face with the ability to pull “to do” lists from a web-service via a background process, while at the same time we continue to support Connect IQ 1 devices. Of course the functionality on the Connect IQ devices will remain the same as before the changes as there is no alternative to background services in Connect IQ 1.x.

We open our project from before and add the Connect IQ abstraction layer, this is the one I’ve defined for Connect IQ 1:

class CiqView extends CommonLogicView {
    hidden var message; // I could add this variable to the CommonLogicView class, this is to show that you can define class instance variables at any level in the inheritance tree…

    function initialize() {
        CommonLogicView.initialize();
        message = "I'm a CIQ1 device!";
    }
}

A very similar class we add for the Connect IQ 2 devices, looks quite similar, only difference being that we’ll pick up the message from the application class:

class CiqView extends CommonLogicView {
    hidden var message;

    function initialize() {
        CommonLogicView.initialize();
    }

    function onUpdate(dc) {
        CommonLogicView.onUpdate(dc);
        message = App.getApp().backgroundMessage;
    }
}

In addition we change the DeviceView to show the message variable. In the jungle file we either pick the source-ciq1 folder or the source-ciq2 folder. Our jungle file looks like this:

project.manifest = manifest.xml

# fix autobuild to a specific device
base.sourcePath=$(fr735xt.sourcePath)

#ciq1
fr235.sourcePath=source;source-ciq1;source-semiround
vivoactive.sourcePath=source;source-ciq1;source-vivoactive

#ciq2
fr735xt.sourcePath=source;source-ciq2;source-semiround

Notice that with little effort we also added support for the Forerunner 235.

We’ve also duplicated the application layer level. The Connect IQ 1 version is pretty straightforward (you can have a peek at the source on github). The Connect IQ 2 version is slightly more complex as we’ll implement a background service to fetch from a webservice here (trimmed for readability):

(:background)
class PetersWatchfaceApp extends App.AppBase {
    var backgroundMessage = "What should I do?";

    function initialize() {
        AppBase.initialize();
    }

    function getInitialView() {
        // register for temporal events, we don't need to check whether this is supported, we know we have a Connect IQ 2 device here!
        Background.registerForTemporalEvent(new Time.Duration(5 * 60));
        return [ new DeviceView() ];
    }

    function onBackgroundData(data) {
        // store the data from the background event in a class level variable
        backgroundMessage = data;

        // we received a new todo item, invoke a request to update the screen
        Ui.requestUpdate();
    }

    function getServiceDelegate(){
        return [new BackgroundServiceDelegate()];
    }
}

The service delegate is the main entry point for the background service, inside we’ll fetch a random to do item from the web-service.

(:background)
class BackgroundServiceDelegate extends System.ServiceDelegate {
    function initialize() {
        System.ServiceDelegate.initialize();
    }

    // this is called every time the periodic event is triggered by the system.
    function onTemporalEvent() {
        Comm.makeWebRequest(
            "https://jsonplaceholder.typicode.com/todos/" + (Math.rand() % 100 + 1),  // get a random number between 1 and 100
            {},
            { "Content-Type" => Comm.REQUEST_CONTENT_TYPE_URL_ENCODED },
            method(:onReceive)
        );
    }

    // receive the data from the web request
    function onReceive(responseCode, data) {
        if (responseCode == 200) {
            Background.exit(data["title"]); // get the title part of the todo list…
        } else {
            Background.exit("Error " + responseCode);
        }
    }
}

Full source code

Hope you’ll like this technique!
Happy coding!

Cheers,
Peter.

In April of 2016, the EU Parliament passed the General Data Protection Regulation (GDPR), an act that was designed to harmonize data privacy laws across the European Union (EU). The GDPR provides requirements for the lawful processing of EU Personal Data, including requirements related to data privacy, consent, and digital services, and goes into effect on May 25th, 2018.  GDPR generally applies to the processing of EU Personal Data, and it may apply to you or your company even if you are not in the EU.  Data protection authorities may issue fines up to 4% of annual global turnover or €20 Million, whichever is greater, for non-compliance.  Garmin wants to share this information, including the reminders of developers’ obligations, with our developer community as a courtesy.  This isn’t legal advice - this is a developer blog after all - and we encourage you to consult with your legal counsel for guidance. 

Connect IQ is a global platform, and, as stated in the Connect IQ license agreement, developers are responsible for their apps’ compliance with all applicable laws, including those related to data protection and privacy.  Specific responsibilities related to privacy can be found in Section 2 of the Connect IQ license agreement.  Developers should review the GDPR to determine what obligations they may have under the GDPR.  These obligations may include the following:

• Asking for consent for collection of Personal Data
• Providing access to information on what Personal Data concerning them is being processed, where, and for what purpose
• Providing access to any Personal Data collected from them free of charge
• Ability for a user to erase their identity, including the ability to halt third party processing of Personal Data

If your solution collects Personal Data in any way, including using the Communications permission to collect or retain Personal Data (potentially in conjunction with Sensor, Sensor History, or Position permissions) or using any other mechanism, you are responsible for ensuring that your solution is in compliance with the GDPR on or before May 25, 2018.

You may now resume your regularly scheduled programming.

Connect IQ 2.4.3 is now available for download. This updates our supported devices tables and provides some bug fixes. Get the SDK today.

The 2018 Connect IQ Developer Summit is coming up soon, and you won’t want to miss it! Here are some of the agenda items you can look forward to:

• Keynotes by Garmin CEO Cliff Pemble as well as by leaders and managers who will tell you about the latest products and the newest features of Connect IQ
• Guest talks by HERE, Nordic Semiconductor, and Ray Maker
• Lightning talks bydevelopers
• Evening social events with Garmin team leaders, other developers and industry experts
• Workshops and breakouts covering wireless, health, music, sensors, and advanced Connect IQ topics
• Complimentary registration in the Garmin Marathon (full, half or 10K distance) on April 21, 2018
• A free Connect IQ compatible device is included with registration

We look forward to meeting you at the event, but act fast; registration closes on March 16th so register today!

Have you been looking for ways to make your Connect IQ more location aware? Richard Süselbeck of HERE Technologies has written an extensive post on how to integrate the HERE API to create a points of interest app that combines the Places and Routing APIs . It is a great read with tips any Monkey C developer can take advantage of.

HERE is a leader in location technology, and the HERE developer platform offers numerous tools including geocoding, points of interest, routing, and traffic. Richard will be talking more about his solution and the HERE platform at the Connect IQ Developer Summit in April.

Check out Richard’s post and register today for the summit.

Connect IQ 3.0 is here! This is the largest update to Connect IQ we’ve made in a long time, and has many new core features to the platform.

 
• Music – In CIQ v3.0, we have opened the audio/music APIs so any third party can create and upload an audio or a music app to the CIQ app store. iHeartRadio & Deezer are the first of hopefully many providers to create experiences. The audio/music API allows a user to download up to 500MB of music on their wearable from their music account (initially iHeartRadio and Deezer) and to play music directly from the wearable without a phone.
 
• Maps – CIQ v3.0 allows developers to integrate Garmin’s onboard maps into their apps. The developer can present the map to the user, overlay routes or points, and have UI elements on top of the map.
 
• Messaging – For select developers, we are opening the potential for their CIQ apps to get actionable notifications. These developers will be able to push content from their service to a specific device using Garmin’s new push notification service.

We’ve expanded the developer tools, too:

 
• Menu2 – A greatly expanded menu framework that allows titles, subtitles, icons, and branded title bars.
 
• Byte Arrays – Useful for getting the most out of memory, byte arrays are one fifth the size of regular arrays.
 
• Cryptography – Connect IQ adds numerous hashing and encryption algorithms to the Toybox.
 
• Beat to Beat Intervals – Discover deep user information by reading the timings between heart beats.
 
• Bike Radar – Integrate bike radar information into your apps and data fields.
 
• Symbol Checking – The new Automatic Symbol Check (ASC) checks to make sure your methods, member variables, and objects exist at compile time while still staying true to Monkey C’s dynamic nature.
 
• More – Many bug fixes and small improvements as well.

We’re excited to share Connect IQ 3 with you. Today you can download the first SDK and a beta for the Forerunner® 645 Music. In May, we will be releasing Beta 2, which adds the mapping features, notifications features, and wider device support. Finally, we’ll be releasing Connect IQ on all devices mid-June.

One more thing—we talked about app trials last year, and now we are ready for you. Please contact the developer program to get the integration guide.

Get the Connect IQ 3.0.0 Beta SDK and Forerunner 645 Music beta firmware today!