Modifying settings without the Eclipse Plugin

Be sure to look at the "New Developer FAQ" stickies at the top of this forum, as the basic answer is you need to use Eclipse to do it if it's not in the store. There's also somethings there to look out for/guard against with using settings from a phone (it's in the 2nd FAQ)

What's often done is that to test with a phone or GE, submit it to the store, but include "DO NOT APPROVE" in the title. Garmin won't approve it, and you're the only one that can download it. Once you're happy, remove the "DO NOT APPROVE", it will get approved, and be available to everyone.

Ah thanks, that's what I feared.

I'd prefer to obviously test all my settings prior to submission - but I'd love to know how this is done via the Eclipse tool.

I can see a binary .SET file is created via the Simulator.

Does anyone know the format of this file? Is it just a dump of a struct?
Maybe I'll tinker around and build a simple tool to edit it :)

From a submission process perspective, it seems like a hacky workaround, but hey, I'm perfectly comfortable with that :)

So, I was able to directly manipulate the hex within my apps SET file, as follows:

xxd APP.SET > dump.txt

Then manually edit the hex dump with a text editor, and re-save;

xxd -r dump.txt > APP.SET

Obviously, this is a major hack, and no onSettingsChanged() event is called.
However on a Ui.requestUpdate(), the settings did indeed update as expected :)

It's actually simple to do this with the App Settings Editor in Eclipse (I'm curious - why don't you want to use it?)

When running in the sim, you can modify the settings, which actually updates the .set for your app in the sim's temp directory with those settings. You can then just copy that .set to your watch and see how things look with a sideload. (less chance of breaking something in the .set)

As things changed for you with an onUpdate() (by way of the Ui.requestUpdate() ), you must be reloading the settings each time onUpdate() is called. You really don't need to do that, and you are running code you don't need to (and quite often). What I do is read the settings in initialize() for the view and set vars to what I see, and the only other time is based on onSettingsChanged() being called by the VM and I change those vars for the new settings. So during most times, I only read the settings once at startup, but if you do it with onUpdate(), you could be doing it every second. Just a suggestion!

Pc lions campoy

Actually, this is what I ended up doing - editing the SET and side loading it on my Fenix. However, I just noticed you can set properties in your app! This would have been much easier.

As for the onUpdate() - yes, I am reading the properties here into a global variable. I originally had read the properties only once within onLayout(), but could not figure out how to trigger an onLayout redraw event in my base app. The onUpdate() method was borrowed from one of Garmin's own examples on GitHub :)

As for Eclipse, well, I'm not really a fan of bloated IDEs. I'm using vim, and my own build scripts to test, and package my apps :)

I just looked at the ObjectStore sample, and yes, that does read things on every call to onUpdate().

It was originally written for the ObjectStore, and then app settings was added to it when app settings came out in the 1.2.0 SDK (that's when onSettingsChanged() came about and it's only for app settings and not the OS, and in fact, the sample doesn't use onSettingsChanged() at all.. It probably should be updated, as the OS vs app settings parts also aren't really pointed out)

The OS and app settings are actually two different things, and even stored in different files (The OS is in the .str, and settings in the .set), and you can change the OS from the sim (File>Edit ObjectStore) so that is probably why it's checking the settings every onUpdate(). The OS is your apps local persistent storage, and can only be changed by way of the app itself.
----
onLayout isn't called on a regular basis, but as you see, onUpdate() is, and can also be forced with Ui.requestUpdate(). So what you can do is set the globals in onSettingsChanged(), and do a Ui.requestUpdate() from there, so once the new settings have been read, the screen gets updated with the new settings right away. (it's nice if you're changing your current watch face from a phone, because as soon as you click "done" in settings on GCM, the watchface changes and you can see how they look, and adjust things if you don't like it right away.

I'm looking for answers on the same subject.
I have sideloaded my app to the watch and can see the {app}.SET file in the F:\GARMIN\APPS\SETTINGS folder on the watch, but I can't work out how to edit the settings on the watch.
In Eclipse, running the simulator I use the Connect IQ/App Settings Editor, but how do I access that when the app is running on the phone?

Unfortunately, you can't test app settings on an actual device without publishing the app to the app store and downloading it from there. Normally this doesn't matter as the simulator does a pretty good job of allowing you to change settings.

If you want to test app settings without making your app available to the public, you can publish it to the app store and put DO NOT APPROVE in the app title. You can test and update the app as you see fit. When you are ready to publish it, you can remove the DO NOT APPROVE from the app title and upload a new version. That should get approved according to the normal process.

If, after you've published the app publicly, you discover you want to do more testing it is probably best to create a dummy app (just modify the manifest and upload your app as if it were a new one), putting DO NOT APPROVE in the app title. Once you've got your changes verified, revert your manifest, rebuild, and upload to overwrite the public version of the app.

It isn't really a great process, but this is what is available at this time.

Travis

Thanks (again) Travis.
I suspect if you publish with DO NOT APPROVE and download, then side load a revision, the App Settings editor will continue to work?
Wouldn't it be great if stuff like this was published in the Programmers Guide?

Hey,

I have submitted a request to have it formally documented. I did want to mention for anyone who is looking that testing while the app is in pending status is mentioned here in point 7:

https://forums.garmin.com/showthread.php?339891-New-Developer-FAQ

However, this doesn't talk about marking it so it will not be approved yet. We can fix that as well.

Thanks,
-Coleman