Possible Fitbit Studio bug - file transfers

[rc26]

Within the last week or so I've noticed that running my clockfaces in the simulator tends to fail because the user defined clockface settings, which are transmitted from the companion to the app using file transfers, either fails to properly transmit to to App or the App fails to receive it. In the simulator, I can launch the clockface repeatedly until it catches - until something finally goes right, and file transfers work again. This is not a problem I've noticed on the watch itself, just the simulator, on PC. Just FYI.

[JonFitbit]

Thanks for reporting this, will see what I can find out.

[dsilberg]

I can confirm that I'm seeing the same issue.  I haven't tested on a device/phone, just the simulator.

What's interesting is that I can transfer the files from the device -> phone without issue.  They all complete.  But only the even ones are received.  It appears that the odd transfers are simply ignored as not being there.  Here's some snippets from my logs:

[07:38:57]       App: Transfer of cbor1.txt successfully queued.                                                                                                                    (common/logger.js:33,10)
[07:38:57]       App: Transfer of cbor2.txt successfully queued.                                                                                                                    (common/logger.js:33,10)
[07:38:57]       App: Transfer of cbor3.txt successfully queued.                                                                                                                    (common/logger.js:33,10)
[07:38:57]       App: Transfer of cbor4.txt successfully queued.                                                                                                                    (common/logger.js:33,10)
[07:38:57]       App: File Transfer State: transferred                                                                                                                              (common/logger.js:33,10)
[07:38:57]       App: Transfer of cbor3.txt completed.                                                                                                                              (common/logger.js:33,10)
[07:38:57]       App: File Transfer State: transferring                                                                                                                             (common/logger.js:33,10)
[07:38:57]       App: File Transfer State: transferred                                                                                                                              (common/logger.js:33,10)
[07:38:57]       App: Transfer of cbor4.txt completed.                                                                                                                              (common/logger.js:33,10)

...

[07:38:57] Companion: processAllFiles: received file: cbor2.txt                                                                                                                     (common/logger.js:33,42)
[07:38:57] Companion: processAllFiles: received file: cbor4.txt                                                                                                                     (common/logger.js:33,42)

For what it's worth I'm using basically the stock code provided in the documentation:

In the app: 

export const enqueueFile = async (filename) => {
  try {
    const ft = await outbox.enqueueFile(filename);
    logger.info(`Transfer of ${ft.name} successfully queued.`);
    ft.onchange = () => {
      logger.info('File Transfer State: ' + ft.readyState);
      if (ft.readyState === 'transferred') {
        logger.info('Transfer of ' + ft.name + ' completed.');
      }
    }
  } catch (ex) {
    logger.error(`Failed to queue ${filename}: ${ex.toString()}`);
  }
};

and in the companion:

const processAllFiles = async () => {
  logger.trace('lib.fitbit.fileTransfer.processAllFiles');
  try {
    let file;
    let found = false;
    logger.debug(`file: ${JSON.stringify(file)}`);
      while ((file = await inbox.pop())) {
      logger.info(`processAllFiles: received file: ${file.name}`);
      const payload = await file.cbor();
      fileHandlers[file.name] && fileHandlers[file.name](payload);
      found = true;
    }
    !found && logger.info("processAllFiles: No files found")
  } catch (ex) {
    logger.error(`failed to process file: ${ex.toString()}`);
  }

};


export const init = async (handlers = {}) => {
  logger.trace('lib.fitbit.fileTransfer.init');
  fileHandlers = handlers;
  await processAllFiles();
  inbox.addEventListener("newfile", processAllFiles);
};

I hope this helps.  For now, I'm just going to push a dummy empty file for each file I push.  That should get me past the issue, but I'd love to know what's going on. 

[rc26]

For my clockface projects, one of the first actions is to send the clockface settings to the App using a file transfer. In Fitbit Studio, on PC at least, every-other launch of the clockface in the simulator will succeed. For example: I change the code a little, build, and run, and the settings fail to get transferred to the App. Then, just hit run again, and it works. Weird, but as long as this doesn't happen on the actual watch hardware this is more odd quirk than a show-stopper.

[morningReign]

I had a similar issue until I switched to Google Chrome.

I usually use Edge, and still do for everything else, but as my app got bigger the file transfer failures became untenable.

[dsilberg]

I just realized, thanks to your post, that this is about Fitbit Studio.  I don't use Fitbit Studio, I do all development in WebStorm and use the CLI.

With that said, it's interesting to point out that the bug affects both CLI and Studio users.  I'm pretty sure it's in the Simulator, though I haven't tested it on live devices.  It may exist there as well.

[rc26]

Not a problem on actual watches. I've been actively developing three clockfaces in parallel with a growing user base and lots of real-world testing and I haven't seen this. Just Fitbit Studio, as recently as last night. But I can work around it by just launching the clockface a 2nd time. Overall I'm happy with the real-world performance of these watches. Feels like it is more reliable. My current concern, on a different subject, is the process of "updating" an existing clockface installation. If the code change is significant it feels like the update process leads to a corrupt or problematic install. The solution is to install a different clockface, and then go back to install the updated version. Just speculating, just a feeling. Last thing, can we get a downloads counter in the Fitbit gallery manager?

[rc26]

I think I was sending messages to frequently to the companion and that just screwed things up. It was every 2 seconds in some circumstances...every 5 seconds cleared up the issue, no more double run for me. - Using latest Fitbit Studio with SDK 4

[morningReign]

@dsilberg >> ...I do all development in WebStorm and use the CLI.

Cool. You just reminded me CLI existed. I took a pass at setting it up early on and ran into so many roadblocks I settled on Fitbit studio.

Studio works fine, but I just finished setting up CLI with git, ESLint and a decent minifier and I am just really happy right now.

Thanks,

[morningReign]

@rc26 >>...But I can work around it by just launching the clockface a 2nd time. Overall I'm happy with the real-world performance of these watches. Feels like it is more reliable.

I'm very happy with these watches too. I had the 2nd load problem on simulator too. When I tracked the entry and exit events, I found the app wasn't always exiting after the SVG unloaded. 

I added:

import document from "document"

import {me as device} from "device"

document.mPage.onunload=function(e){me.exit()}    //mPage is the top <SVG> tag in my index.gui file

Now the app always exits and I haven't had to reload a second time since.

Regards,

Reign