Connect IQ 1.1.2 SDK Available!

We recently released version 1.1.2 of the Connect IQ SDK today!

You may also download through the Connect IQ SDK Manager in Eclipse, by clicking the Connect IQ menu, selecting Open SDK Manager, and then clicking the Download button for Connect IQ SDK 1.1.2 released June 16, 2015.

It is also available for download here: http://developer.garmin.com/connect-iq/sdk/

v1.1.2

Fixed issues with Exceptions so that user implemented try/catch blocks will now work.
Add call to saveProperties after onStop so any properties updated by an app after onStop are preserved.
Fixed memory leak when receiving messages via the Communications module.
Increase reliability of transmitting messages via the Communications module.
Correct Moment's initialize() routine never getting called automatically.
Add two new API's to the WatchUI::InputDelegate class:
- OnKeyPressed(evt)
- OnKeyReleased(evt)

These routines are used to detect when a hard key is pressed and subsequently released, allowing applications to access this type of input schema in additionto the basic key action.

Add CLOCK key support for Fenix3/Epix, remove power and light key from devices.xml (since they are not supported by any devices), and correct key behaviour mappings for a number of devices in the simulator.
Add D2 Bravo, Japan Fenix3, and APAC Epix device support.
Prevent sending input to view without a defined input/behaviour delegate.
Fix device crashes when reading corrupt PRG files.
Fix bug that truncated FIT session names.
Fix issues with rapid key presses causing key messages to hit a view after a push or pop had already occurred.
onStop() will now always be called when a data field exits.
JSON request URLs are now percent-encoded so that any special characters are replaced by their identifying hex pair. Adds a new routine encodeURL(url) to the Communications module which allows the application to do this as well.
Add deprecation tags to the GeometryIterator methods/class, which will not be supported in the ConnectIQ 2.0 release.
Add interface to simulate GPS quality which allow the simulator to control the accuracy of the current GPS for testing.
Fix several memory leaks that occurred under specific error-recovery conditions.
Activity Monitoring times now use UTC as the standard format.
Circular memory references are now detected and after an app is shut-down, an error will be written out to the ConnectIQ log file (device only).
Prevent processing view push/pop messages from applications that have already closed.
Add HTTPS support to CURL requests in the simulator.
Properly handle condition where jsonRequest returns an array by default instead of an object.
Fix palette bitmap padding offset on the FR920XT, and ellipse border offset on all devices.
Re-add support for Escaped Characters to String Resources.
Add four menu items to control settings in the simulator:
- Battery status
- Force onShow
- Force onHide
- Phone connected

Battery status allows the user to set the level of the battery currently, phone connected is a toggle for whether a phone is connected or not, and force onShow/onHide forces those methods to run for the current view.

Allow Spaces in Project and SDK Paths.
Remove the extra menu for toggling low power mode and creates a checkbox for low power in the settings menu. All apps now start up in low power mode by default and exiting an app resets the menu. Also adds in a menu option for toggling sleep mode for ActivityMonitor.
Support memory tracking which adds a new window available at File->View Memory. This window shows a snapshot of the current allocations as well as any circular references. When the app starts to shut down, a snapshot is taken and if any circular references exist after the app is shut down, the snapshot is shown to the user along with a message about circular references.
Add activity history editing support to the simulator.
Update Epix simulator data field layouts and fonts to match the on-device experience.
Fix issue with converting coordinates to GEO_MGRS.
Improve general ConnectIQ stability across devices.
Various other minor bug fixes, performance improvements and documentation updates.

Known Issues:

If an Exception is thrown from a catch block, the finally block of the current try/catch/finally will not be executed.

Top Replies

JensDuttke over 2 years ago in reply to Brandon.ConnectIQ +2

Brandon.ConnectIQ

I have confirmed that there are some caveats you'll need to be aware of when using dict = {} in Monkey C to empty a dictionar. We'll definitely need to add a clear() method after all…

All Replies

Kyle.ConnectIQ over 10 years ago

But an update button, or even better, having it update in real time would be even better.

But alas, I found out that the values in this page are static, they are not updated in "real time" and thus cant be used to determine the array values or whatever values in real time. We still have to do the Sys.println()

This is something Ken brought up be we didn't have time to implement before the release. There are other improvements to make to it as well, such as displaying the class of each object.

View memory is awesome, but seems to be crashing quite frequently on me.

That shouldn't be happening, even with a bunch of circular references. We'll investigate the issue.

Former Member over 10 years ago

Update on the new onKeyPressed and OnKeyReleased events

All observations are for the fenix 3:

I tried both new events out, trapping both for the "up" button. I observed:

- if onKeyPressed is intercepted, the usual onKey() is not fired anymore (which is good!)
- if onKeyPressed is intercepted for the "up" button, there WILL be an onKey event for the MENU button (which is not so good - depending on what the onKeyPressed event started, the action linked to the MENU key being pressed most likely comes at a bad moment
- if one creates and pushes a new view as a response to the onKeyPressed() event (which works beautifully), the corresponding onKeyReleased() event is sent (correctly) to the freshly pushed view. One must keep this in mind if one wants to clean up here. I intercept the onKeyRelease() event and pop the view right away. This allows the user to call up some information which is displayed as long as he/she presses the button. Nice. But make sure that the MENU (or CLOCK for the down key) onKey() event doesn't come in the way.

Thank you, Garmin! Nice move.

I still wish you would have given me access to the Light key :cool:

Former Member over 10 years ago

The API website mentions that it would become available with 1.1.3.

This is a typo. Ironically it will be fixed in the 1.1.3 release to the correct value of 1.1.2.

Former Member over 10 years ago

I am still a bit confused and I probably have to set up my own little playground to get clear. I wonder:
- when I handle onKeyPressed(), is there still the normal onKey() event raised in between onKeyPressed() and onKeyReleased()?
- will onKeyPressed() also be raised for the MENU and CLOCK key?
- what can I do in onKeyPressed()? Can I, for example, push another Ui.View() here? If so, which View object gets the onKeyReleased() event then?[/

The normal key events will always be raised, and should always occur between the pressed and released events.

The key pressed and key released events only correspond to the base key functions, and will never occur for held keys like MENU/CLOCK on Fenix 3. For example, if you hold the up key, you will first get a key pressed event for the UP key, then a normal key event for the MENU key, and finally a key released event for the UP key (when it is released).

You already got this one, but the new view will receive the release event.

if onKeyPressed is intercepted, the usual onKey() is not fired anymore (which is good!)

This is not correct. The normal key event should still be sent. It is possible it could be lost if you change views at the same time it was sent.

rconradharris over 10 years ago

Wishlist item for View -> Memory: Would be incredibly useful if the columns were sortable.

Would love to see at a glance which objects are taking up the most memory. Or in the case of 'created At' see all objects created in `onStart`.

Former Member over 10 years ago

Still no foreign characters???

I just recognized - with some disbelieve - that I still can't use any "foreign" (which are not foreign at all where I live) characters like öäü, éèà etc.
Even though my apps are entirely in English, it would still be great to use symbols like ±ø°Ω∑∆¬–…«~≈

This is really getting annoying.

I receive complants from users that my app doesn't show distances in yards. OK, fair enough, even though only 3 countries in the world are still not using the metric system. I'll fix that in my app, to show some respect.

Can we get local character support now, please? 7-bit ASCII was overcome in the 70's of the last century, but here it is apparently back? Or is there a trick I should be using (come on, don't tell me to create my own font...)?

Former Member over 10 years ago

Launching from Mac

It still doesn't seem to work correctly to update via the SDK Manager on Mac. I just tried that and it downloaded the package but the simulator wouldn't launch. I downloaded the SDK directly from your site and the simulator opens just fine. It seem that whatever the SDK manager does in Eclipse doesn't install it correctly.

Nikeow over 10 years ago

it does on mine tho...

Former Member over 10 years ago

It still doesn't seem to work correctly to update via the SDK Manager on Mac. I just tried that and it downloaded the package but the simulator wouldn't launch. I downloaded the SDK directly from your site and the simulator opens just fine. It seem that whatever the SDK manager does in Eclipse doesn't install it correctly.

I'm also on Mac OS and it worked just fine. No issues...

Former Member over 10 years ago

I just recognized - with some disbelieve - that I still can't use any "foreign" (which are not foreign at all where I live) characters like öäü, éèà etc.
Even though my apps are entirely in English, it would still be great to use symbols like ±ø°Ω∑∆¬–…«~≈

Hard coded strings have an issue with using characters outside the A through Z range because the string value itself is used as part of the symbol when compiling. A change is currently under review which allows pretty much any unicode character inside a symbol at the compiler level. Until that change is brought into the project you will have to use string resources for any strings which contain those characters. The good news is that this is not a change that will require a firmware update so we can get it out to the public sooner.

Can we get local character support now, please? 7-bit ASCII was overcome in the 70's of the last century, but here it is apparently back? Or is there a trick I should be using (come on, don't tell me to create my own font...)?

I'm not sure here if the request is to compile with local character support (addressed above) or to display local characters on the screen. If you are using a built in font then you will be limited to what characters the device is choosing to support as far as displaying characters on screen. You can check the User Experience Guide in the SDK to see what characters are supported by each device. If you want to display characters that are not supported by the device you will need to use a custom font.