Confusing feedback during GAM submission

[MadderHatter]

Greetings all,

I recently (well... somewhat recently) submitted my open source clockface (https://github.com/matthewwardrop/fitbit-agenda-arc-clockface) to the GAM, but received some confusing feedback that I don't know what to do with about the reviewer being unable to access the settings app. The settings app works fine on my device, and I cannot imagine how it would fail to operate during the review. I'd love a review of the code so I can understand what might be causing the issue :).

You can see the app in the GAM here: https://gallery.fitbit.com/details/46bc1328-c480-4927-b94f-6693088fd661

The review:

-----

Published 06/21/2020 7:11 PM

Rejected 06/29/2020 6:25 AM

Uploaded 06/21/2020 7:11 PM

Reviewer Feedback

Due to the fact that your CLOCK has functionality issues, we regretfully inform you that we have declined your submission. Please find the issues uncovered during testing below:

- #cannot access the settings in order to complete the testing process.

Please consult the following link for more information: https://dev.fitbit.com/legal/app-gallery-guidelines/

[Gondwana · Accepted solution]

Settings can fail to load if you try to access an uninitialised setting; eg,

JSON.parse(props.settingsStorage.getItem('calendars'))

This could try to parse an undefined setting, fail, and result in a white Settings screen.

Even if you try to initialise the calendars setting in companion code, the settings page can sometimes run before the companion code.

Before submitting, test your settings on a fresh install (ie, with no settings previously defined).

I could be way off base here; I only took a quick look.

[MadderHatter]

Ah! That could well be it. I think I assumed (and saw in my test runs) that the companion app ran first, but it could be that `calendars` had not yet been populated. I'll try catching that and see what happens.

[Gondwana]

I think it's actually a race condition. The companion usually runs first, but not always.