06-01-2012 08:13 PM
running your own server strikes me as an unclean/unwise solution.
(just personal philsophy about such things)
may as well implement html rendering code in my app to display help files,
if i'm going to just do it all myself.
really, the idea that local app helpfiles may be in html and may need displaying
without reaching out over a network connection doesn't strike me as being too far
fetched an idea to get some offical support some day...
06-01-2012 08:17 PM
06-01-2012 08:29 PM
the idea i wanted an external app to reach into my sandbox was implied/deduced by those reading my original submission and NOT what i intended.
i figured if i included a Native api call to the browser i would then be running an App-Local instance of the browser to play in my sandbox. it just turns out that is not the case. i certainly would not want externals reaching into my box
er... did i phrase that correctly ?
06-01-2012 08:47 PM
06-01-2012 09:28 PM
06-02-2012 02:37 AM
yes i did use the word browser and understand how the confusion arised.
but the title of my original post did refer to the Native API call: navigator_invoke()
which i think i perferctly reasonable for someone new to this particular platform
to assume it invoked a local-instance (to the calling app) of the navigator and thus
have the same rights as the caller. inhereting rights/permissions of the caller process
is not unheard of on other (non mobile) platforms.
but it doesn't in this case. i accept that.
workarounds have been suggested, and i will try them if i ever get the time/motivation to get
back to working on the app.
what is really needed is an official native api call to render html data (not a browser, just
render html fed to it.) html is a perfectly reasonable format for documentation. and non
network-based documentation is reasonable to have too.
but no need for anyone to keep posting defences of the status quo with implied
blame-the-victim mentality (please ACCEPT MY APOLOGY for using the word browser.)
i accept this is the way it is.