Eclipse plugin: show only relevant content assist

Former Member over 10 years ago

Hello everyone,

It seems like the Eclipse plugin's content assist feature doesn't only show the relevant properties/methods/constants for objects or instances, but that it rather shows everything there is to find in the entire Connect IQ SDK:
see screenshot

To me, that makes it rather useless...
To illustrate, I just started checking out the Connect IQ SDK and I wanted to simulate and capture some sensor information.
The API docs tell me there is a Sensor.Info object that has the following attributes: altitude, cadence, heading, heartRate, power, pressure, speed, temperature:
see screenshot

The "Positioning & Sensors" documentation however omits the "power" attribute:
see screenshot

So is it available? The only way to know for sure is to test:
see screenshot

Great! No compilation errors; it seems that the "power" attribute is indeed available for the Sensor.Info object and that the documentation fails to mention it.
But wait... something is still wrong here... I'm building an app for the vivoactive watch, and that watch doesn't have a barometric sensor. Yet, I have a line reading "System.println("Pressure (Pa): " + sensorInfo.pressure);" in my code, and it doesn't give me a compilation error!? My app will reference an attribute that never gets populated and I won't know until I notice it myself, bummer!

Another thing that would be nice, is knowing which sensor triggered and update. Unfortunately, the only way to do that now it seems is to store the last value for every sensor at the end of the onUpdate function, and match these values with the new values when entering the onUpdate function the next time to see which values have changed. It would be much simpler & more efficient to retrieve the function caller and write some conditional code, but the SDK doesn't provide a way to do so.

Any chance the plugin will receive some love soon, or that it will be open sourced so that the community can help out improving it?

Best regards,
Sven

Former Member over 10 years ago

I would love this too. I just figured it wouldn't be possible since nothing is statically typed in the language. (ie, you don't define a variable as Position::Info type, it's just inferred by the value set)

Dynamically typed languages are a pet peeve of mine, but it's the only choice I've got to develop for my watch :(

Former Member over 10 years ago

It seems like the Eclipse plugin's content assist feature doesn't only show the relevant properties/methods/constants for objects or instances, but that it rather shows everything there is to find in the entire Connect IQ SDK:
see screenshot

You are correct. All available variables/classes/modules in the SDK (as well as all variables/classes/modules defined in your code) are included in the content assist. pmprog is also correct in that the we don't provide specific suggestions based on the context because the language is dynamically typed (if you've ever used Pythons IDE you might notice a similar behavior). To that extent we tried to name things (in particular enum values) so that you could start typing a base keyword and the matching symbols would quickly be narrowed down to useful values.

The API docs tell me there is a Sensor.Info object that has the following attributes: altitude, cadence, heading, heartRate, power, pressure, speed, temperature:
see screenshot

The "Positioning & Sensors" documentation however omits the "power" attribute:
see screenshot

There are several instances where documentation needs to be updated. It's been noted and it's in progress. For now I would recommend referencing the docs that Travis mentioned in the other thread as those are generated when the compiler is built.

But wait... something is still wrong here... I'm building an app for the vivoactive watch, and that watch doesn't have a barometric sensor. Yet, I have a line reading "System.println("Pressure (Pa): " + sensorInfo.pressure);" in my code, and it doesn't give me a compilation error!? My app will reference an attribute that never gets populated and I won't know until I notice it myself, bummer!

I would recommend writing your code to check for null values in any information that's returned from the API as that would make your code more easily portable to other devices which might have those values available. :)

Another thing that would be nice, is knowing which sensor triggered and update. Unfortunately, the only way to do that now it seems is to store the last value for every sensor at the end of the onUpdate function, and match these values with the new values when entering the onUpdate function the next time to see which values have changed. It would be much simpler & more efficient to retrieve the function caller and write some conditional code, but the SDK doesn't provide a way to do so.

I filed a request to add this but I can't promise it's something that will be added. What you're doing sounds like a good way of going about it.

Any chance the plugin will receive some love soon, or that it will be open sourced so that the community can help out improving it?

Updates and improvements to the plug-in are also on the list of things to do. We'd love to hear specific requests for the plug-in so we can prioritize what we work on.

I don't suspect the code will be open sourced but it might be possible to write your own plug-in to share with the community to fill in a functionality that you feel is missing. A lot of the information that is shown in the plug-in can be found in the api.debug.xml file in the SDK and the debug.xml file created during compilation. TONNY.MADSEN did just that; you can check it out here.

Former Member over 10 years ago

Hi Ken,

Thanks for such a fast and elaborate response!

(...)(if you've ever used Pythons IDE you might notice a similar behavior). To that extent we tried to name things (in particular enum values) so that you could start typing a base keyword and the matching symbols would quickly be narrowed down to useful values.

Yes, I have used (the) Python IDE indeed, and while I absolutely love the elegance and the efficiency that the language offers in certain domains, I have sworn against the disadvantages of it's non-statically typed nature more than once... That being said, it's not impossible to create an IDE that is able to offer reasonable code completion, but it's not an easy task.

There are several instances where documentation needs to be updated. It's been noted and it's in progress. For now I would recommend referencing the docs that Travis mentioned in the other thread as those are generated when the compiler is built.

Cool! I'll use the API docs as my primary reference then, thanks!

I would recommend writing your code to check for null values in any information that's returned from the API as that would make your code more easily portable to other devices which might have those values available. :)

Yep, goes without saying... but not if you haven't been programming for too long. For novel programmers in particular, real time or at least compile-time code checking will avoid a lot of mistakes (possible by validating the manifest file to see whether the code to be compiled is valid for the target devices); and for more experienced programmers, runtime polymorphism would allow for writing "universal" apps that work across all Garmin devices and that offer specific functionality depending on the device. This would also facilitate writing shared library code for Garmin devices.

Updates and improvements to the plug-in are also on the list of things to do. We'd love to hear specific requests for the plug-in so we can prioritize what we work on. I don't suspect the code will be open sourced but it might be possible to write your own plug-in to share with the community to fill in a functionality that you feel is missing

I respect that, although I don't immediately see a reason why the eclipse plugin code should be closed-source. What do you have to lose that outweighs what you have to gain by open-sourcing that code?

. A lot of the information that is shown in the plug-in can be found in the api.debug.xml file in the SDK and the debug.xml file created during compilation. TONNY.MADSEN did just that; you can check it out here.

Yes, I came across that post by scouting the forum today. Thank you for mentioning it, and thank you for pointing out the info comprised in the debug.xml files! Like I said... it is by no means an easy task writing a perfect Eclipse plugin, and I don't expect myself nor Tonny Madsen to do so quickly by ourselves, but many hands make light work.

Best regards,
Sven

tonny.madsen over 10 years ago

Like I said... it is by no means an easy task writing a perfect Eclipse plugin, and I don't expect myself nor Tonny Madsen to do so quickly by ourselves, but many hands make light work.

I actually started a new editor in the Christmas holidays based on XText, but as I don't have the full grammar for Monkey C and it seems to still be under development, I want to wait a little before I start on that again. I have worked with dynamically typed languages before, and it is actually possible to deduce a fair bit about the possible types given just a little more information about the SDK. And, as most Monkey C programs are going to be relatively small - due to the limitations of the runtime platform - you can actually do a very complete analysis in real time.

For open source references as to what can actually be done in Eclipse based on XText, have a look at Xtend, or without XText, look at TCL and Ruby.