01-05-2012 09:50 PM - edited 01-05-2012 09:51 PM
Well I looked at my version and it was still 2.1 so I did a fresh install of v2.2. Everything loaded up fine I copied the config file made it just as you said and....nothing. Maybe its due to the fact I have a slow internet connection? I could upload the .cod file to a file sharing site and someone else can try and see if it works on their faster connection? Though this would make deving pretty hard without me being able to test my own creations.
By the way this is on the 9930 simulator with OS7
01-06-2012 10:40 AM
Could you give it a shot with the 9900 simulator just to see if you get different results? The dual CDMA/GSM network selection on the 9930 may be having issues, so if the 9900 works, we know that's where the issue lies and can address the 9930 in that way.
A slow internet connection should still load the page. But it might be worth trying a very simple "Hello World" hosted HTML page to see whether the size of the content makes any difference (the previous URL noted did have a lot of content, but again, we should be able to get it to a working condition.)
A recent 9900 simulator can be downloaded here:
BlackBerry Development Advisor
04-13-2013 10:23 PM - edited 04-13-2013 10:56 PM
I am getting the same error "No <feature> tags are allowed for this <access> element." when trying to insert a <feature> tag as a child of <access uri="*" subdomains="true">
Are feature Tags not allowed for <access> Tag with uri as *.
Everything worked perfectly well till now in our Webworks Applications, but our release is brought to halt because of this issue.
Is there a possible workaround you guys can suggest.?
Can something like the below work.?
<access uri="*" subdomains="true" />
<access uri="http://somedomain.com" subdomains="true">
<feature id="blackberry.ui.menu" version="1.0.0" required="true"/>
<feature id="blackberry.widgetcache" required="true" version="22.214.171.124" />
04-15-2013 05:57 PM
You are correct. If you are white-listing <feature> elements for external URLs, you will need to specify those URLs explicitly. It can not be done with the uri="*" element. Basically the idea is that, if your app is expecting an external URL to run native APIs, you will know which URLs those are.
04-15-2013 06:06 PM - edited 04-15-2013 06:07 PM
Thanks a lot for validating my approach.
I just tried my approach today. It works perfectly Fine.
I am able to generate Menu Items after the Window Load event is fired.
The problem with this approach however is :
I have two domains :
http://somedomain1.com which needs these menu items.
On this Domain, feature elements are not whitelisted, but the Menu items are still visible.
And there is no way in which I can remove Menu items from this domain as once menu items created they always sit there right.?
I hope I am clear on explaining the scenario.
04-15-2013 06:56 PM
When the user clicks the button to navigate to http://somedomain2.com, could you run some code to remove the menu items first, and then navigate to the new URL? You should be able to leverage this API on the domain that has the feature white-listed:
04-15-2013 08:09 PM
I wish I could have done that..
But being an ORG wide app, there are too many external links and clicks to handle.
And the problem is if I try to remove the items using
static void blackberry.ui.menu.removeMenuItem (item :blackberry.ui.menu.MenuItem) on the domain in which <feature> tags are not supported, it wouldn’t do anything.
Just one more weird behavior I observed today,
If you load an app on the browser the page starts to paint while Script is being executed in the background, but the same app when wrapped in Webworks waits for the entire Script execution to complete.
This gives the impression to the Users that the Page is taking more time to Load.
Is there a Webworks specific API/Workaround to allow the Page to start painting while script is executing in the background.
04-16-2013 02:46 PM
On the page being navigated away from, you may be able to add an event listener for the beforeunload event. Basically, it triggers when the user is navigating away, and in such a case you might be able to remove the menu items. This way you're not tied to individual link interactions / clicks, but a general page navigation / change event.
In general, best practices recommend that you keep your CSS in the <head> of the page, then in the <body> you list out all your elements, and after those elements, before the closing </body> tag, you include your <script> elements there. A good article on this is here:
04-16-2013 07:58 PM
Thanks a lot..Will try out this "unload" event approach today and let you know the results.
And yes we have followed the best practices you mentioned.
I was guessing instead of showing the normal Webworks GIF image in between page loads we can some kind of progress bar.
I am not sure if we can call just the URL field of browser to show the Loading status in between page loads.
If this is possible it would definitely provide a better User Experience instead of just showing a GIF image which doesn't tell you anything about the Loading status.