Connect IQ 1.1.2 SDK Available!

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.

Can you PM me your OSX version, Eclipse version and CIQ plug-in version. We had a report internally a long time ago that was similar to this but we could not reproduce the issue.

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.

Just checked the User Experience Guide, didn't really see much guidance here, am I missing something? http://developer.garmin.com/connect-iq/developer-tools/user-experience-guide/

I'm in the same boat as planetscooter, I'd love to add unicode support to my app.

Because of the lack of unicode literals, I've basically had to strip non-ASCII characters and replace them with a '?'; letting them go through causes some truly, truly weird bugs (stack traces involving the ANT module oddly enough!).

The way I see it, it's two separate problems. There's the transport problem, and then the rendering problem.

Right now transport is broken because you can't even ship unicode strings onto the device without it crashing (you need to use the layout strings to avoid it).

Once we can get unicode strings onto the device, the next step is how to render the appropriate characters. This is where I get much more confused on the best approach...

Since full unicode support will probably be a ways off, I've been contemplating a work-around that uses a funky custom encoding to 'hide' non-ascii characters in the byte-stream, and then a custom renderer that uses a white-list approach to display those white-listed characters (think: loading just those characters from layout strings, yuck, but should work).

Just checked the User Experience Guide, didn't really see much guidance here, am I missing something? http://developer.garmin.com/connect-iq/developer-tools/user-experience-guide/

Check <1.1.2 SDK root>/Connect IQ User Experience Guide.pdf for the most up-to-date information. We're working on getting all the pages of the website.

Please give us umlauts and other extended characters

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.



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.

Apparently I expressed my complaint in an ambiguous way. So let's try again:

Of course I don't care (and for good practice I never would) whether I can use extended characters for variable names. But I do care whether I can display them on screen. And not through odd workarounds like creating a dedicated font or even define strings in resources just because they contain an "ü" instead of an u.

What I'd like to do is

dc.drawtext(x,y,Gfx.FONT_TINY, "München, ø HR, ∑ km 45 °C", Gfx.TEXT_JUSTIFY_CENTER | Gfx.TEXT_JUSTIFY_VCENTER );


without getting question marks displayed.

This limitation is really hard to understand and hard to live with. The F&#275;nix cannot even write its own name, as it seems.

I am not requesting full unicode, but in the good old times between 7 bit ASCII (127 different characters) and unicode we had 8-bit ASCII (256 characters) which contains at least those characters that are accessible on normal keyboards (depending on your localization, possibly only with the use of modifiers such as ALT and CTRL or CMD). See http://www.ascii-code.com.
I really think those characters should be directly supported, and should have been since day 1.

Check <1.1.2 SDK root>/Connect IQ User Experience Guide.pdf for the most up-to-date information. We're working on getting all the pages of the website.

Hi Ken

I checked the most recent PDF that came with the SDK. For the Fenix it shows "Available characters" as a bitmap with lots of extended white letters on a black background, giving the impression that hose characters would be "available". But the still don't get displayed when used in a string in the dc.drawtext statement.

But this is what I would expect. Treating "ä" differently than "a" is a big oversight, in my view.

The characters listed in Appendix B of the UX guide are what's available in the font files for each device. I'll admit that the bitmap isn't ideal (I'd eventually like to put together an ASCII table instead), but it was the best way to get the information published now with the tools I have available.

The way you can use these characters is limited right now by the way the compiler works, as Ken explained:

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.

So don't worry, we'll get this fixed up soon. :)

The characters listed in Appendix B of the UX guide are what's available in the font files for each device. I'll admit that the bitmap isn't ideal (I'd eventually like to put together an ASCII table instead), but it was the best way to get the information published now with the tools I have available.

The way you can use these characters is limited right now by the way the compiler works, as Ken explained:



So don't worry, we'll get this fixed up soon. :)

That's great to hear that y'all are working on this. As you're doing this can you keep makeJsonRequest in mind as well? In other words, I'd like to be able to pass unicode characters (UTF-8 encoded) back via JSON and then render them correctly on the watch.

Right now, if for example an em-dash character is passed back, the JSON parser crashes hard, leading to some crazy tracebacks that look like they're coming from the Ant module:

Here's the bug from my TODO list:
- Embedding an emdash in a note causes this traceback when swiping around on the list-view
in d:\projects\smartwatch\venu\TVM\api\Ant.mb (initialize:74)
in d:\projects\smartwatch\venu\TVM\api\Ant.mb (initialize:74)
in d:\projects\smartwatch\venu\TVM\api\Ant.mb (initialize:74)
in d:\projects\smartwatch\venu\TVM\api\Ant.mb (initialize:74)
in d:\projects\smartwatch\venu\TVM\api\WatchUi.mb (handleEvent:245)
TVM ERROR:
Unexpected Type Error
Failed invoking <symbol>

Offending string is:
>>> 'onment—originall'
'onment\xe2\x80\x94originall


I'll make sure that gets looked into. The Ant module errors you're seeing can usually be considered a generic error. It's what gets printed when the compiler doesn't really know what the exact error is.

Usually when the callstack shows Ant.mb all the time it means you're running a release version of the PRG. Is this happening in this case?

Usually when the callstack shows Ant.mb all the time it means you're running a release version of the PRG. Is this happening in this case?

Yeah I think I tried that on a release build. I'll give it a shot on a debug version this weekend and see if the stacktrace is more useful.