• Replies 22 replies
  • Subscribers 18 subscribers
  • Views 2770 views
  • Users 0 members are here
Options
Related

CIQ Tools

dbrobert
8 months ago

In an effort to contribute more to our Connect IQ developer community, with the hope of making it easier and faster to make better apps, I have been spending a considerable amount of time working to extract useful code from my various projects and turn them into shareable barrels. In some cases it has been easy as they are my projects and in many cases I have had to work with clients to get permission. Regardless, I now have half a dozen barrels in various states of readiness that I am going to release on GitHub. I am also working to make public some useful API endpoints. I have decided to group these barrels and APIs collectively under the name "CIQ Tools".

The barrels will all be licensed under the MIT License, which will allow for the most flexible use and the API endpoints will all be available for free (and hopefully without the need for any kind of API key).

In all cases right now, the published code will not be anywhere near to feature complete, so if there are suggestions then please create an issue within GitHub on the repo. Or, even better, provide more functionality or fixes by contributing via a GitHub's pull request.

Barrels

The source code for all barrels is in separate repos within GitHub. Because you don't need the actual source code for the barrel to include it in your project, I have made the barrel (and associated debug.xml) available in the releases sidebar section.

API Endpoints

  • 8 months ago in reply to dbrobert

    Ok, but why testing for notEquals(result, anArbitaryWrongValue)? It is possible that there's a mistake in the arbitraryWrongValue and the test passes. Why not testing for what it does need to equal to?

  • 8 months ago in reply to flocsy🤠
    flocsy🤠 said:
    Why not testing for what it does need to equal to?

    It does; that's why immediately before the edge case (of 65536) there is a test for 65535 -- that covers both sides of the "edge", making sure that it's correct at the maximum and that it doesn't wrap or overflow when it's over the maximum.

  • 8 months ago in reply to dbrobert

    But this makes no sense:

    Test.assertNotEqual(packNumber(65536), [0xCD, 0x01, 0xFF, 0xFF]b);
    Test.assertNotEqual(packNumber(65536), [0xCD, 0x00, 0x00]b);

    Why not also:

    Test.assertNotEqual(packNumber(65536), [0x42]b);

    ?

    You know what it is supposed to be, so check for that.

  • 8 months ago in reply to flocsy🤠
    flocsy🤠 said:
    Test.assertNotEqual(packNumber(65536), [0x42]b);

    Why would it ever be that value? 0x42 would be a highly unlikely potential result. If you read through the MessagePack spec you will see why both those tests make sense. Packing the number 65535 should result in three bytes but 65536 requires a 32-bit number so there should be 5 bytes. But if the code is wrong, it may wrap and/of overflow which is why we test for it not being equal to those wrap/overflowed values.

  • 8 months ago in reply to dbrobert

    So why do you check it with a 4 byte value? Slight smile 42 is always the answer. Maybe it should be: 0x2A :)

    It's not easy to write good tests. But to test for 2 "arbitary" values for notEquals, without any explanation why testing them makes not much sense. Not that with explanation it would make much more. Why don't you test for what it is supposed to be?

  • 8 months ago in reply to flocsy🤠
    flocsy🤠 said:
    Why don't you test for what it is supposed to be?

    There is a test for that; in the test for 32-bit unsigned integers.

    If you have a better way to write the tests, feel free to read the spec for MessagePack and submit a pull request. But all the tests that are currently there ensure things don't happen that either did happen or could have happened during development, which means that they are useful. I didn't add any comments because the test names are self-documenting and the values make perfect sense if you read the spec and are familiar with min/max values of signed/unsigned integers of various bit size and buffer overflows.

  • 7 months ago

    I've now added deserialization (unpacking) to the MessagePack barrel, and released version 0.2.0 (on GitHub).

    And for anyone anticipating the release of the other libraries, the two pickers (number and text) will be cleaned up and released next. Graphing could be released but only has line graph support right now (and isn't all that robust either).

  • 6 months ago

    The graphing code is now publicly available on GitHub as a barrel -- github.com/douglas/ciqtools-graphing

    I have only had time to clean up (somewhat) and add the code for line graphs but it's a start. With the barrel as stands now, you can produce graphs that are basically indistinguishable from the native line graphs on the newer Garmin devices.

    UPDATE: the repo was still set to private; I've updated the config now so that it is publicly visible.

  • 6 months ago

    I've added the code for the number picker now to GitHub as a barrel. This code is still rather rough, and the documentation is still lacking but I wanted to release it for use (see this thread). I will work on the documentation over the next few days, but in the meantime for any help required on using it see the fore-mentioned thread.

  • 3 months ago
    dbrobert said:
    Device Lookup - api.ciqtools.com/.../{part_number} -- eg. Fenix 7 Pro lookup

    Any plans for updating the devices in the device look up API.  Looks like a number of the newer devices don't show up yet.  For example I am seeing product codes for the Edge 1040 and 1050 not returning any information.