Dumb newbie compilation question

Former Member over 8 years ago

Hi

I thought I would see what is involved in writing code for the Garmin fitness trackers. I downloaded the latest ConnectIQ SDK (2.4.2) and installed on Ubuntu. I tried to compile one of the sample programs using the command-line tools, but I couldn't get anything to work. I'd be happy to explain the various ways that various things didn't work, but I don't really have the first idea how to build the sample applications.

I kind-of thought it would be as simple as

$ cd samples/Analog
$ monkeyc -o analog.prg -f ./monkey.jungle -y my_key
$ monkeydo analog.prg fenix3 (or whatever)

But all this gets me is:

Failed invoking <symbol>
Invalid value in onLayout

As I said, I tried many different ways to compile the sample and none worked; but the fact is that I don't have the faintest idea how to build the samples, and I'm probably doing something daft.

Thanks in advance,
Lars

jim_m_58 over 8 years ago

I never use the command line (I use Eclipse), but it kind of looks like your missing somethings on the compile line. like parameters for the resources and which device you are compiling for

Former Member over 8 years ago

jim_m_58 I'm sure you're right. But what? I tried specifying the resource files and source files explicitly rather the ,jungle file, and I got an error message about a missing font. The font is actually in the fonts/ directory and referred to in the XML file in the resources/ directory so I'm not sure what else is required.

If nobody ever builds this stuff from the command line, or it's just impossible, then fair enough; but I won't be using IDEs -- not at my time of life :) It was only a casual interest, anyway; I had nothing particular in mind to develop. Nice watch faces, by the way.

Anshul.ConnectIQ over 8 years ago

LarsTheBear

Your compile command looks good except you also have to mention the device id while compiling. Please try this command and let me know if you are still running into problems.

$ monkeyc -o analog.prg -f ./monkey.jungle -y my_key -d fenix3
$ monkeydo analog.prg fenix3

Anshul

Former Member over 8 years ago

Anshul.ConnectIQ Thanks, that worked fine.

But...

Does this mean that I would have to compile a different version for each device?

Also (if you have a minute): how to I copy the compiled code to a device for testing? Can I just copy the .prg file to the device over USB? Or is there more to it than that?

Anshul.ConnectIQ over 8 years ago

Does this mean that I would have to compile a different version for each device?
For that reason it is recommended to use the eclipse plugin, However if you want to continue the command line path then I would say YES and also NO.
Yes for the cases

if your app is deigned to run on devices with different screen sizes.
if your app have app has excludes based on the screen size or device family type (where you exclude a file compilation for a specific device )
if your app has conditions for compilation based on the device.

No for the cases

If your app is designed to run on same family or same screen devices.
if your app doesn't have any device dependent compile conditions.

Take the analog sample it doesn't have any device specific code or conditions for compilation. Analog sample built for fenix3 might run without an issue on fenix5, 5x, 5x but that may not be the case for a more complex app.

Also (if you have a minute): how to I copy the compiled code to a device for testing? Can I just copy the .prg file to the device over USB? Or is there more to it than that?

Yes you can copy the generated *.prg file to GARMIN/APPS directory on the watch through usb and the app should show up in the device.

jim_m_58 over 8 years ago

Not sure if you's seen this, but there is a new developer FAQ.

When you build a .iq (it's now you publish to the app store), it actually contains device specific .prg files, so the "build for all supported devices" is done there. They are also "release builds".

When you command line compile, there's probably an option for release vs debug builds (I just use a checkbox in Eclipse for sideloads). When testing a sideload, you likely want a debug build with symbols, so you get more info if your app crashes.

Former Member over 8 years ago

Thanks. Copying the compiled .prg over USB worked fine. I'm a million miles away from building anything for distribution, but I would be interested to know how to build a .iq tool without using an IDE, if that is possible.

Incidentally, I've noticed that the monkeyc compiler does not seem to detect invalid function names at compile time. I entered "printf(...)" like C, and assumed it was OK because the compiler didn't complain. It fell over at run-time as well.

Is there some compiler option to make checking more strict? It seems exceptionally dangerous to have an error of this sort not detected until your app crashes on the device. Or am I just missing something?

jim_m_58 over 8 years ago

I think building a .iq is just a compiler option.

I would recommend trying eclipse. There are some things you can't do from the command line (like the app settings editor, so you can change the settings in an app, like can be done from a phone). And things like building a .iq, is just a menu selection, as is building a .prg right to the watch.

Former Member over 8 years ago

Sure, I understand. But I've been writing software for over 30 years, and I have ways of doing it that are productive for me. Sometimes I have to use IDE tools, including Eclipse, but I prefer my own ways. My work frequently requires me to write and maintain code on the other end of a dumb terminal, and I've become reasonably good at making use of command-line and text-based environments over the years. If I have no alternative to using an IDE, then I will, but I can't imagine it will ever be my first choice. Each to his own, of course.

Former Member over 8 years ago

Is there some compiler option to make checking more strict? It seems exceptionally dangerous to have an error of this sort not detected until your app crashes on the device. Or am I just missing something?

The compiler does not currently track the information required to detect this type of error at build time. You should certainly be testing your code before deploying, so I'm not sure I'd agree that runtime errors are somehow more dangerous that build time errors.