Regarding less docs: okay I see now Shaz, we use the same key names as we have in configurations, and so we defer to the documentation there. Makes sense. Should we then have a separate section/attribute for run-time adjustable config values?
On Mon, Feb 11, 2013 at 2:38 PM, Michal Mocny <[email protected]> wrote: > I'm not sure why a single generic api would mean less docs? We would > still need to document each valid key, wouldn't we? Anyway, I like the > plugin approach suggested, especially since there will likely be very few > configurations that need adjusting at runtime. > > (btw, another adjustable setting might be "set supported orientations") > > -Michal > > > On Mon, Feb 11, 2013 at 2:31 PM, Shazron <[email protected]> wrote: > >> Not sure about explicit methods since we will have more docs (and separate >> ones for the diff platforms). I personally would go with a generic API, >> and >> the setting to use would already be documented in the Project Settings >> doc. >> >> e.g. >> >> navigator.app.setConfigSetting('KeyboardShrinksView', false, win, fail) >> >> or something to that effect. I reckon if the setting is "read-only", it >> would call the fail callback. >> >> >> On Mon, Feb 11, 2013 at 11:07 AM, Andrew Grieve <[email protected] >> >wrote: >> >> > Hmm, yeah, definitely doesn't make sense for the whitelist. Not really >> for >> > BackupWebStorage either... If we're not saving across restarts, then >> > BackupWebStorage won't use the updated settings anyways. >> > >> > Looking through the documentation, I think that most settings wouldn't >> have >> > a reason to change... Only ones are maybe: >> > UIWebViewBounce >> > EnableViewportScale >> > >> > And also the KeyboardShrinksView one I wanted to add. >> > >> > Perhaps another avenue here is to put this in an "App" plugin. Android >> > currently has an navigator.app with methods like "clearCache", >> > "overrideBackButton". >> > >> > We could explicitly have methods such as: >> > navigator.app.setKeyboardShrinksView(true), >> > navigator.app.setUIWebViewBounce(false) >> > >> > I'm not really sure if this would make more sense, or if it even matter >> > which approach we go with :P. >> > >> > >> > >> > >> > On Mon, Feb 11, 2013 at 11:59 AM, Shazron <[email protected]> wrote: >> > >> > > The only case (as Brian mentions) is not allowing the whitelist to be >> set >> > > at runtime. >> > > Also - does the app have to "reset" if a setting that was read at >> runtime >> > > was changed? ie we probably need a "configchanged" event/notification >> or >> > > something. For example, BackupWebStorage in iOS, etc. >> > > >> > > >> > > On Sun, Feb 10, 2013 at 11:01 AM, Andrew Grieve <[email protected] >> > > >wrote: >> > > >> > > > First - I'd like to add yet another setting for iOS: >> > > > >> > > > KeyboardShrinksView (boolean). >> > > > >> > > > It applies to apps that position their elements relative to the >> bottom >> > of >> > > > the webview. When the keyboard comes up, I'd like to shrink the >> webview >> > > > rather than shrink the viewport and have the page scrollable. This >> is >> > the >> > > > default behaviour on Android, and makes a lot of sense when building >> > apps >> > > > as opposed to webpages. >> > > > >> > > > >> > > > But... Reason for this email, is I think it'd be useful to have a >> > > > x-platform API for changing the settings within config.xml at >> runtime. >> > > > Something like: >> > > > >> > > > cordova.setConfigValue(key, value) >> > > > >> > > > An example of the keyboard case: >> > > > app.onPageChange = function(pageName) { >> > > > cordova.setConfigValue('KeyboardShrinksView', pageName != 'help'); >> > > > }; >> > > > >> > > > And I suppose adding a getter makes sense: >> > > > cordova.getConfigValues(successCallback) >> > > > >> > > > I'm thinking that setting these at runtime will *not* persist across >> > app >> > > > restarts to avoid the issue of what should happen when devs push >> > updates >> > > to >> > > > their apps that change settings around. >> > > > >> > > > If everyone's okay with this, I'll file a bug & sub-bugs >> per-platform. >> > > > >> > > >> > >> > >
