Made some progress on publishing complications!

Ok, I'm again trying to get Complications working on here, but I'm afraid I'm missing some things. At he moment I'm seeing: 

ERROR: com.garmin.connectiq.common.manifest.ManifestException: Invalid permission provided: ComplicationPublisher

I would think the beta SDK is not set correctly, but it's definitely using it in the command. I've also rebooted VSCode, my machine,... Also removed the beta SDK and installed it again, no luck. 

Any clues? Do I need something else in the manifest or monkey files?

I'm using the 4.2.0 beta 1 sdk, and the f7 System 6 preview device in the sim.  Also, my app type in the manifest is watch-app.  And VS Code, not Eclipse.

Here's the permission I'm using:

That's all the same as mine, except for permission name. I followed the docs on this:

The docs missed an S in the permission name, that's why it was failing for me. 

Anyway, I still see another error now:

ERROR: fenix7system6preview: Error occurred while generating app resources: Problem validating a resource file: cvc-elt.1.a: Cannot find the declaration of element 'complication'.

How are you setting up the xml files of the complications? I have a separate /complications folder next to /drawables etc. In the folder is complication.xml, with almost the same code as the example in the docs.

The doc has typos, and the slides at the GDVC too.

I have a folder with the XML as well as the svg I use for the icon.  Here's my xml.  I'm publishing 3 in this app:

<resources>
    <complications>
        <complication id="0" access="public"
            longLabel="@Strings.longComp"
            shortLabel="@Strings.shortComp"
            icon="@Drawables.iconComp"
            glancePreview="true">
            <faceIt defaultText="@Strings.longComp" />
        </complication>
        <complication id="1" access="public"
            longLabel="@Strings.longComp1"
            shortLabel="@Strings.shortComp1"
            icon="@Drawables.iconComp"
            glancePreview="false">
            <faceIt defaultText="@Strings.longComp1" />
        </complication>
        <complication id="2" access="public"
            longLabel="@Strings.longComp2"
            shortLabel="@Strings.shortComp2"
            icon="@Drawables.iconComp"
            glancePreview="false">
            <faceIt defaultText="@Strings.longComp2" />
        </complication>
    </complications>
</resources>

_psx_ said:

if 2 devs publish complication with the same ID how subscriber distinguish them?

I haven't tried this stuff myself, but reading between the lines of the docs:

- The complication "ID" in a given app's resource file is a number from 0 to 255 which is only unique to that app

- Toybox.Complications.Id, which is used to subscribe to complications, is probably a combination of at least: complication type (one of the native types or CIQ), CIQ app UUID (when applicable), and complication "ID" within a CIQ app's resource file (when applicable)

I would question the wisdom of calling both of those things "ID", but whatever.

Note that when you manually construct a Complications.Id, you can only specify one of the native types. In order to access a CIQ complication, you have to iterate through the installed complications on the device. Therefore, app devs don't have to know the precise details of Complications.Id.

Thanks Jim, I'm getting somewhere now with this information. Hope they fix the docs for the final release.

The way I'm using complications I publish in a WF is this.  As I said, the doc has errors, so this was trial and error.  the id in the xml is for that app, so I publish based on 0,1,or 2.

In the watch face, I use the iterator to go though the complications, and check complicationId.getType() looking for Complications.COMPLICATION_TYPE_INVALID.  (ok, this is a really bad name, as they aren't INVALID, just not a native complication.  I think Complications.COMPLICATION_TYPE_CIQ or something would be a better name).

jim_m_58 said:

So the 0,1,2 is used when publishing, no UUID is used when getting data from a complication. just the strings.  I use longLabel right now, but shortLabel may work. 

I think my point flew over your head. My comment was in reply to this:

_psx_ said:

if 2 devs publish complication with the same ID how subscriber distinguish them?

My point was that the ID in the resource file (0-255) is obviously not the same as the Toybox.Complication.Id.

I didn't claim that a UUID is directly used when a CIQ app subscribes to a complication, I just meant that for CIQ complications, Toybox.Complication.Id probably incorporates both the app uuid and the complication "id" within the app resource file (assuming that Toybox.Complication.Ids are globally unique.) Therefore, if a CIQ app subscribes to another app's complication, the complication's app UUID is very likely *indirectly* used. I don't see how else it could possibly work. (Seems to me that the firmware itself needs to know the complication's app UUID in order to get data from it.)

This was to clarify the apparent confusion where about whether the ID in the resource file and the Complication.Id are the same thing.

I also pointed out that that since you can't subscribe to CIQ complications directly (you have to iterate through the installed complications), you don't have to know the details of what goes into a Complications.Id (and indeed it's an opaque data type -- you can get the type but not any other details.) Yes, I know there's a long label and short label available when you iterate - this is obviously available so that CIQ apps can display a user interface for selecting complications. But crucially: there's apparently no *programmatic* way to get the exact complication you want from a *specific* app. How do you know some other dev didn't publish a complication with the exact same shortLabel and longLabel? We already have apps in the store with near-identical or identical names.

FlowState said:

Note that when you manually construct a Complications.Id, you can only specify one of the native types. In order to access a CIQ complication, you have to iterate through the installed complications on the device. Therefore, app devs don't have to know the precise details of Complications.Id.

EDIT: Of course, if Complications.Ids are only *locally* unique, instead of the app UUID, they could incorporate some local index to the app on the device. My point was a Complications.Id has to refer to the complication's app *somehow* -- it can't just consist of the complication ID in an app's resource file.

My post is based on how this works today in both the sim and on real devices.   As I said, the id in the xml file is only actually used when publishing.  The point YOU missed is today, neither the id nor the UUID is used when getting data from a complication, and the only way to find one is to compare strings (the stings in the complication.xml)

Here I'm using complications I published with a WF in the sim.