CIQ Development With VSCode - The Gotchas
The Connect IQ Eclipse Plugin is dead! Long live the Connect IQ Eclipse Plugin!
It has been about 5 months since Garmin held their annual developer conference, during which there was an entire breakout session for Connect IQ tools, including the all singing, all dancing, Visual Studio Code extension. Drinking the Kool-Aid, one would have thought Garmin had lowered the barrier to entry for development on the CIQ platform, in their own words
The Eclipse environment isn’t great, the IDE feels outdated, it lacks extensibility
and even the simplest tasks such as changing the default theme has you jumping
through multiple hoops. Frankly, it was such a bad experience that I would only use Eclipse to edit my manifest.xml
file.
I actually went as far as adding a couple of functions to my ZSH profile so that I could avoid opening Eclipse for most everyday development.
|
|
Despite these shortcomings, when it came to setting up Eclipse on your machine, Garmin provided you with a complete set of steps covering how to install and configure your development environment.
In fact, at time of writing, taking at look at Garmin’s getting started and SDK documentation, Eclipse is still the chosen / supported development environment.
Now, it is true that feature parity between the plugin for Visual Studio Code and Eclipse is not quite there, which would explain the reason for downplaying the VS Code side of CIQ development. However, were you to stumble across one of the few buried posts on Garmin Forums or the plugin’s marketplace page you’d be forgiven for thinking you only need to follow the following 5 steps to get up and running
- Install extension
- Download the Connect IQ SDK Manager
- Download an SDK and set it as the current SDK using the SDK Manager
- Download devices using the SDK Manager
- Run the Monkey C: Verify Installation command to ensure the development environment is correctly setup
That, I’m afraid, is not entirely accurate. There are a few gotchas I’ve come across while getting set up with the plugin and I thought it would be worthwhile mentioning them to save others the troubles I went through.
Incorrect documentation is often worse than no documentation.
Gotcha 1: Environment
There is a prerequisite of the Oracle Java Runtime Environment (version 1.8.0 or higher), which applies to any Connect IQ development you want to do. You’ll hit this roadblock pretty quickly if you tried to run any projects after setting up your plugin. If I was being completely honest, this gotcha isn’t unique to the Visual Studio Code plugin, but then this goes back to my original point that when a user is setting up Eclipse you’re told of this requirement, kind of…
You see, this little nugget of information is present within the getting started guide on the Garmin Developer website, but not readily surfaced during SDK or plugin download 🤷♂️
Anyways, onto the solution. For those on MacOS, assuming you use the Homebrew package manager, you can install the Runtime Environment with the following:
|
|
Gotcha 2: Visual Studio Code Workspace Layout Matters
This gem was a joy to unpick…it turns out, that when you try to use the Monkey C plugin from within Visual Studio Code the layout of your workspace will determine if your project runs or not.
This may not matter to everyone, but I’d be surprised if I’m the only one who has fallen foul of this bug(?). I like to keep my things organised, so my code layout is something like this:
|
|
If I’m working on watch faces, I’ll usually open up a workspace in VS Code, which in turn loads my
garmin/faces/*
directories, the workspace is seen as a single parent folder in VS Code
with all project folders available to me in that single tree view.
Take the below screenshots, the first shows a workspace which is made up of a single folder, containing all other folders. This is how I usually use VS Code.
The following screenshot, shows a workspace that is made up of multiple folders.
The net result is largely the same, a view of my watch faces available from one sidebar, crucially however, only the setup in the second screenshot will allow you to run/build any of your applications.
If you try to launch an application from the single folder workspace
You end up with the following error
Same project, same code, but different workspace layout
You get a running application
I’ve lost track of how many hours I spent trying to work this one out or where the issue lies. I cannot say who is to blame for it, Garmin, Microsoft or my perverse use of workspaces. Hopefully, I’ve saved someone else the hassle with this…
Gotcha 3: Manifest Editing Became That Little Bit Harder
The manifest.xml
file is used to set metadata components of your application, typically
things like app id, the app type, targeted devices, supported languages and a few
other bits. You know, the bits of information that are only of any importance if you
want to test or release your application.
If you really wanted to, you could create and populate this file by hand, though I don’t think this is advised.
|
|
That comment populates the head of all manifest files generated during project creation. I’m guessing it’s pretty important.
Luckily for us, the Visual Studio Code plugin offers the ability to populate the manifest file automatically. That is, once you’ve completed the song and dance required to access the correct command from within the command palette.
The plugin has several options which can be triggered, the options and their roles are below
Monkey C: Edit Application
- to update the application attributesMonkey C: Set Products by Version
- lets you add all products that meet the minimum SDK version of the applicationMonkey C: Edit Products
- lets you add or remove any productMonkey C: Edit Permissions
- to update permissionsMonkey C: Edit Languages
- to edit your compatible language listMonkey C: Configure Monkey
Barrel - to edit the included barrels
Once triggered, you go on to complete a form like user interface that updates the manifest file as you work your way through it.
So what’s the problem? Well, you see, while the above does work, and the UI/UX is most likely the best that can be done within the constraints of a Visual Studio Code plugin, it just isn’t as streamlined as Eclipse…yes, I said it. Eclipse actually offers a better experience for this task 🤯
The two areas which I think users will feel the impact of this new manifest editing system are:
-
Ease of use - in Eclipse you don’t need to remember several different commands in order to edit different aspects of your manifest file, you simply click on the file itself and are taken to the manifest editor viewport.
It’s not perfect, something could be said about the sheer amount whitespace and the small, almost invisible tabs at the bottom of the screen (which I’ve highlighted). At least everything is accessible in one place and I’m not going to forget which incantation of the command palette I need to edit a particular piece of the manifest file.
-
Missing information - this is particularly pertinent when working with the ever increasing Garmin product list. In Eclipse, you could hover over a product and you’d get some basic information about its screen resolution and shape of a given product.
This may seem to be irrelevant information, but when trying to support some 60+ products having the ability to check if a product is compatible with your application’s screen shape and resolution layouts is up there with knowing the memory constraints and SDK compatibility of each device.
In the below screenshots you can see the Eclipse product list vs the Visual Studio Code product list alongside additional device data achieved by hovering over a product. Hint, only one screenshot shows this additional data, unsurprisingly, it’s also the one I prefer!
Now in all honesty, if your desire is to really understand device compatibility there’s a web page that provides more information about the subject. But surely Garmin could fit a few extra characters somewhere in their Visual Studio Code dropdown?
All in all, the Visual Studio Code plugin is still in development, Garmin have been releasing relatively frequently and I expect as Eclipse gets phased out in favour of VS Code, some of the UI and UX issues I’ve mentioned will get fixed.
Given where I am in my journey developing for the CIQ platform, the VS Code extension has meant I could ditch my ZSH profile functions, instead running and building my application from VS Code directly. However, I’ve not yet uninstalled Eclipse, the experience determining which devices I can or want to support for my applications is simply that much better than the VS Code alternative, which is a frustrating mix of scrolling between VS Code’s product listing and through Garmin’s device compatibility page.
And with that, thanks for reading.