Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Developer
Developer
Posts: 28
Registered: ‎02-10-2012
My Device: playbook 4G/LTE
My Carrier: none

Re: using navigator_invoke() to view local file:// urls

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...

 

Developer
Posts: 133
Registered: ‎03-28-2011
My Device: BlackBerry 9900 & PlayBook
My Carrier: Bell

Re: using navigator_invoke() to view local file:// urls

Well, others have proposed solutions that should work just fine for you. Simply place your files in a shared location, and invoke them from there. If you're uncomfortable with that, my solution should work for you, at least until we get the ability to embed a WebView control within our apps.

Allowing other applications to reach files within the sandboxes of other applications strikes me as an unclean/unwise solution.

Founder of Pulsecode Inc. and taab
Authomator - Two-factor authentication codes on BlackBerry 10 - http://www.xitijpatel.com/ - Follow @xitijpatel
Is there a helpful or useful post in this thread? Click the thumbs up on it so that other people can find it more easily!
Developer
Developer
Posts: 28
Registered: ‎02-10-2012
My Device: playbook 4G/LTE
My Carrier: none

Re: using navigator_invoke() to view local file:// urls

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 Smiley Happy

er... did i phrase that correctly ? Smiley Happy

 

Developer
Posts: 133
Registered: ‎03-28-2011
My Device: BlackBerry 9900 & PlayBook
My Carrier: Bell

Re: using navigator_invoke() to view local file:// urls

Yup, of course. Apologies for associating certain intentions with you that were not there originally.

Point is, the browser IS an app, just like any other. It has special mechanism for allowing us to invoke it, but that's really about it. Due to the architecture of QNX, for it to access files within your sandbox, would mean that most other apps would have the same access. Even if RIM gave it different permissions, it would introduce a security issue, since now the browser can be used to access ANY app's files. Not good.

Again, until a WebView control is made available, the proposed solutions are likely your only bet. I like the web server solution personally, it's very easy to manage and control. It doesn't have to be heavy-weight at all.

Founder of Pulsecode Inc. and taab
Authomator - Two-factor authentication codes on BlackBerry 10 - http://www.xitijpatel.com/ - Follow @xitijpatel
Is there a helpful or useful post in this thread? Click the thumbs up on it so that other people can find it more easily!
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: using navigator_invoke() to view local file:// urls

dnp, to clarify/support what HorizonXP is saying, there are two forms that the browser can take, and really only one that's referred to as "the browser" (which probably explains any initial misunderstanding if you used that term).

The browser is as HorizonXP said the sys.browser app, which is a "regular" app that cannot access your files.

There's also a libwebkit.so (not sure it's called precisely that) and various wrapped forms of that in each of the different SDKs, which allows us to embed a "browser component" inside our apps if we wish. This is just the control itself, not all the chrome, so there's no configuration or fancy functionality (unless you provide it) other than basic rendering of HTML and related content. If you want to let the user click a link and have it go somewhere, you even need to catch an event that signals that, and update this webkit control with different content.

It's the latter thing you clearly would like, and which is currently missing from the native stuff. It will definitely be available in Cascades and perhaps to vanilla native apps as well, but just not yet.

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Highlighted
Developer
Developer
Posts: 28
Registered: ‎02-10-2012
My Device: playbook 4G/LTE
My Carrier: none

Re: using navigator_invoke() to view local file:// urls

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.