Developing on wearable platforms is new and challenging. An app developer is asked to make dynamic user experiences that compare to what customers see on their mobile phones and web pages on small screens. If content is too dynamic, the device’s battery drains faster; if the user is charging the device, they are not using your app.
Connect IQ combines three W’s:
Connect IQ products provide the best of what Garmin has to offer like beautiful design, location awareness, and efficient power management with the Connect IQ app system. Using the Connect IQ SDK, developers can create apps for Connect IQ devices and distribute them via the Connect IQ Store.
Monkey C is an object-oriented language built from the ground up, designed for easy app development on wearable devices. The goal of Monkey C is to round the sharp edges of making a wearable app, letting developers focus more on the customer and less on resource constraints. It uses reference counting to automatically clean up memory, freeing you from focusing on memory management. In addition, the resource compiler helps you import fonts and images to easily convert them between devices.
If you’ve worked with dynamic languages in the past like Java™, PHP, Ruby, or Python™, Monkey C should be very familiar.
The problem of API Fragmentation is a challenge for app developers. If a developer takes advantage of new APIs, newer devices with less customer penetration may be targeted. If only established APIs are used, apps may not take advantage of new capabilities.
Unlike cell phones, Garmin devices are all wildly different from each other: round screens versus square screens, touch screens versus buttons, and a different array of sensors depending on device purpose. While the Java philosophy of “write once run anywhere” is a notable goal, creating a universal API that crosses every Garmin device would inevitably become a lowest common denominator API.
Rather than attempting to abstract away differences in devices, Connect IQ APIs are tailored to the devices they run on. If a device has a magnetometer, the device should have available the Magnetometer API. If two devices each have a magnetometer, the API should be the same between them. If a device does not have a magnetometer, it will not provide that API.
There is a rhyme and reason behind Monkey C to make it easier for developers to support the Garmin ecosystem of products:
The developer chooses what devices to support
Connect IQ apps can run across multiple devices, but the intended devices are up to the developer. Not every device will be aimed at the markets the developer wants to target or provide the experience the developer wants to provide. The developer should not be forced to support devices they don’t want to.
The developer tools should help developers support multiple devices
The developer tools lessen the weight of supporting multiple devices. The Resource Compiler hides device specific palettes and orientations from the developer. It also allows per device override of resources, allowing different images, fonts, and page layouts to be specified in the resources XML. The simulator needs to expose only the APIs a particular device supports so the developer can test device support.
Similar devices should have similar APIs
Not all devices will be equal, but there is often commonality between them. Two different watches may have different display technologies, but they both support bitmaps, fonts, user events, ANT/ANT+, and BLE. A developer writing a sports app should not have to completely rewrite their app to support multiple devices.
At runtime, the developer can ask what the system ‘has’
Connect IQ applications are dynamically linked to the system. If an app makes a reference to an API that does not exist on a particular system, the app will fail at runtime when the app references the API, not at load time like C++. This allows an app to avoid making the call by taking advantage of the ‘
There are four main use cases for third party developers to interact with the watch: