Make userData bi-directional

[SeaPea]

As I understand it, the framework autosaves the settings into localStorage and automatically reloads the values when subsequently displaying settings. For applications like where passwords need to be entered, I think it would be good to have an option where the application code handles saving settings so that, for example, a token could be stored instead of the password in plaintext when it isn't possible to do this with the custom function.

Could there be a constructor option to turn off autosave and pass the previous settings back to the config page manually so it could show the username and other settings, etc?

[keegan-lillo]

So really what is needed is a bi-directional auxiliary transport of data between the config page and the app.js.

We already do it one way with the userData option. We would just need to include this data when the config closes.

Would also help to have an event fire just before the form is submitted available to the custom function

[SeaPea]

Well with autoHandleEvents set to false there is already the getSettings method for retrieving the settings, but it still has to save its own copy of the settings locally on the phone since there is no default way of passing them back to the constructor. This could lead to passwords, etc being stored in cleartext and an app may not want the password being stored at all.

From what I can tell, userData is made available to the custom function, but I was thinking of something that would disable the automatic saving of settings and accept a dictionary of values to restore settings on subsequent config page loads.

So I was thinking of something more along the lines as below, which would not necessarily require a custom function:

1. An additional constructor option: autoSaveSettings. Defaults to true and setting it to false would only make sense when also setting autoHandleEvents to false
2. An additional constructor parameter: initialSettings. Allows settings in the same dictionary format as returned by getSettings to be passed in when autoSaveSettings is false (not to be confused with default values for the very first time the settings are shown)

[keegan-lillo]

So I'm not sure why the userData object wouldn't be a reliable way of doing this? if you don't set an appKey in the config and only set an id you will be able to still get the value of the field and pass it separately back to the app.js.

So in the custom function it would look something like:

module.exports = function() {
  var clayConfig = this;

  clayConfig.on(clayConfig.EVENTS.BEFORE_SUBMIT, function() {
    var password = clayConfig.getItemById('password').get();
    clayConfig.meta.userData.password = password;
  });
};

Then in your app.js:

Pebble.addEventListener('webviewclosed', function(e) {
  if (e && !e.response) {
    return;
  }

  var password = clay.getUserData(e.response).password
  someCleverThingWithThePassword(password);

  // Get the keys and values from each config item
  var dict = clay.getSettings(e.response);

  // Send settings values to watch side
  Pebble.sendAppMessage(dict, function(e) {
    console.log('Sent config data to Pebble');
  }, function(e) {
    console.log('Failed to send config data!');
    console.log(JSON.stringify(e));
  });
});

[SeaPea]

OK, thanks. That gets the sensitive value from the config into the app.js presumably without Clay doing any auto-saving of the value, but what about the other way around for simplistic round-tripping of such values?

[keegan-lillo]

you can set the meta.userData from the app,js as well.