08-19-2010 01:09 PM
I have received a request from my client - for whom I built my first BB widget recently - asking if it is possible to easily return a user to the widget after the widget has invoked the internal browser. For example, if the user were to select a link in my widget, which invoked the internal BB browser and navigated to a page designed by me, the bb widget would be moved to the background and the BB browser to the foreground. Now, could I put a link or button on the web page that when clicked, would bring the widget back to the foreground?
Please not that I'm asking this whilst in the full knowledge that such a thing could be a haxor's wet dream but I figured there's no harm in checking anyway!
If the above cant be done I'll simply recommend some help text be added to the web page
Solved! Go to Solution.
08-19-2010 04:31 PM
Is there a specific reason on why you need to invoke the Browser to display your website? You could always browse to it right in your widget?
08-20-2010 04:51 AM
To be honest, I did it this way for simplicity more than anything else - invoking the browser is super simple and there's really nothing much one has to do after that point.
Now that I think of it, I understand widgets are essentially a java wrapper app that load a webview2 (cant remember exactly what the BB terminology is for the web views -sorry). So how would one access and load (and allow full functionality) a full, external website whilst still in the widget? I'm assuming it'll be an AJAX load and then doc.write into a div, but this sounds quite heavy and potentially error strewn (my widget is entirely a single html page with show/hide divs - the recommended approach I believe)
08-20-2010 08:49 AM
You just need to make sure that you whitelist the domain (if you are going to use JS extensions on that domain) or whitelist * to just bring the content in for display.
The history is retained so that you can use the back button to go right back to your application, or if you want, you can make a hyperlink to "local:///yourlocalpage.htm" and it will browse back to your local content.
Since the outside content will take some time to load over the internet, you could turn on loading screens with transition effects for outside content so that you would have a nice user experience.
08-20-2010 09:20 AM
Thanks for the suggestion. Perhaps it's me being pessimistic but loading a new site in to the same page sounds like an accident waiting to happen. I know you know best but still...all the JS and HTML i've carefully crafted would be replaced entirely by new content, and i'd have to hope the user knows to use the back button to get back to the widget view (and I'd have to hope it all loads in properly and my widget JS is still initialised etc.).
Also I do believe I override the back button behaviour in the config.xml file so that when hit the widget drops out to the homescreen. If I were to remove that behaviour I'd have to see how the app behaves when the back button is pressed and potentially deal with any issues.
It's certainly something I can suggest but I'd much rather find an approach with a less likely chance of introducing more work for me! So was my original assumption correct in that there's no way to send the user back to the widget if it's been put in the background via an browser invoke command?
Many thanks as always!
p.s. hey how come I haven't got a developer badge on my profile? I defo added a comment in the thread for them. I mean, it's obviously super important....
p.p.s. my widget is available for download here: http://www.musicmonk.me/bb_install/musicmonk.jad - should you wish to better understand what on earth I'm talking about. You might recognise the tab bar from somewhere else....!
08-20-2010 11:18 AM
I downloaded and checked out the app.. Super cool by the way
I definitely wouldn't recommend embedding outside content into one of your existing pages using AJAX and DHTML.
What you could do to control the experience is to simply allow navigating away from your existing page by changing the location.href to the outside url. All of your existing content in the current page will be unloaded and it will move on to the outside page just like moving from page to page in a browser.
For the back button, you could change the functionality to actually do a browser "Back" instead of exiting. This way it will work for the outside pages you load in. Then in the local pages that you control, you can override the BackButton click to exit the application.
This may give you the best of both worlds. It may be worth a quick experiment to see if it gives you the desired result. it should be fairly minimal changes to give it a try.
If you turn on the loading screens for outside content it would even show your MusicMonk page while they are browsing from link to link.
08-20-2010 12:03 PM
Thanks very much for taking the time to check out the widget! I'll use your suggestion as an option when going back to the client (the other one being just to put some text on the webpage).
08-21-2010 08:55 PM
The widget looks good sibbaldl.
Have you thought about using the RIM navigation mode or is the cursor a client request? Again, good work.
08-23-2010 04:09 AM
Thanks for the kind words! It wasn't a request of the client to override the back button behaviour; it was more one made by myself when I initially began coding the app. Perhaps because I'm not a natural BB user I found the back button offered a peculiar navigation mode, in that it essentially "overrode" one's natural instincts with a tab-layout app such as mine. In other words, I think there's an understanding with users of a tab-based interface that in order to move between the tabs one must select each tab in turn. In my mind, selecting a back button to move back through the interface just didn't feel right. It also meant it could mean many presses of the back button in order to exit the app, without me creating a close button specifically for this purpose.
I'm fairly happy with the results, certainly from a presentation perspective, and it was an interesting experience putting it together. Regarding my original request in this thread, I think I'll advise the client to stick some instructional text in the external web page rather than mess with the widget and potentially screw the whole thing up. Getting everything working together just right is a black art when it comes to xhtml,css and JS, let alone in a mobile environment, and the last thing I want to do at this stage is make changes!
09-03-2010 11:20 AM