What controls the index assigned to an imported image?

Watchapp/Face Developers Corner
1

I added 12 images for the 12 hours I want to display. I added them in number order. They showed up under resources in that order. For some reason calling the image for the number 1 rendered the number 3 after I had added all of them, but I tested 1-3 before adding the rest and they came up as expected.

At some point the image files got re-indexed or whatever. Maybe hitting Save a second time for one or more of the images caused this?

I deleted everything and started over. Checked each image showed up matching the hard coded hour value I put in until I had all images in and they showed up as expected.

Any idea what happened in my first attempt?

When the upload screen asks for a C appropriate identifier, is that what it uses to call up an image?

I had assumed the order the image files were displayed under resources would be the index, but that is not the case.

1 Like
2

Resource key order is not guaranteed. Store the keys in an array and index into that array instead.

1 Like
3

If it works right after I’ve redone it, is that necessary? They aren’t likely to change without further changes to the main.js file are they?

Is there an example somewhere of how to do what you suggest?

Just in case, I’m doing this all in CloudPebble and not C with associated software tools.

1 Like
4

Hi. More deets on making this happen (or any other examples of possible solutions) would be really appreciated.

All the Alloy tuts and examples seem to reference resources by their hard-coded numbers, but that doesn’t seem feasible for wider-scoped stuff (especially since the resource order likes to re-shuffle at compilation :smiling_face_with_tear:).

1 Like
5

No, you’re absolutely right. I just assumed there was a way to reference resources by their name instead of index, but apparently there’s not. You can only reference message keys by name. Sorry about that :sob:

1 Like
6

They are deterministic so “re-shuffling” cannot happen. Resource IDs are assigned by the build based on the order of entries in your project’s package.json (under pebble.resources.media). The build literally just enumerates that array and hands out IDs 1, 2, 3, … in order.
waftools/process_sdk_resources.py:

next_id = 1
if has_published_media:
    resource_id_mapping[“TIMELINE_LUT”] = next_id  # id 1 reserved for the timeline LUT
    next_id += 1
for res_id, res in enumerate(resources_list, start=next_id):
    resource_id_mapping[res.name] = res_id

That mapping is then emitted into resource_ids.auto.h as RESOURCE_ID_X = i in the same order.

Which means that IDs are stable as long as you only append new entries to the end of media[]. They will shift if you:

  • insert a new resource in the middle (everything below it shifts by +1)
  • remove a resource (everything below shifts by -1)
  • reorder entries
  • add publishedMedia for the first time (the timeline lookup table takes id 1, everything else shifts by +1)
2 Likes
7

Sorry, I kinda didn’t do a great job of articulating. Let me put it this way:

Does CloudPebble have reliable way for users to check an Alloy project’s resource ID numbers?

Correct me if I’m wrong about any of this, but as I understand it:

  • Resources can’t be referenced by filename or identifier, only the numerical ID
  • Resources are assigned numbers in the order they’re added to the project (?)

The problems:

  • CloudPebble doesn’t let you view or edit package.json unless you download your project as a local .zip file and take a peek inside (which kinda puts a damper on the “cloud” aspect)
  • CloudPebble’s sidebar automatically re-organizes its Resources section alphabetically each time you close and reopen a project, so it no longer matches the order in package.json.

Is there any other way to keep track of resource ID numbers when using Alloy in CloudPebble? Other than manually (like a naming convention, and being sure NOT to ever delete any resources)?

I feel like I gotta be missing something here. (Maybe I should just learn C?? lol)

1 Like
8

That really just sounds like a cloudpebble issue :sweat_smile: but also switching to C would avoid that issue in cloud pebbles since the order doesn’t matter

1 Like