01-02-2012 04:01 PM
I have been wrestling with memory and presentation issues on a number of forms, when attempting to present maps, display photos, minimal data input, you name it.
Unfortunately debugging has not become easier as promised with OS7 as all that is displayed when accessing the port on a bb7 is the default host page as opposed to the index page being served. At a loss here.
My client is willing to limit their customers to the playbook and so I will try this to determine if QNX holds the key to successfully using the BBerry platform beyond a basic communications tool. ATM all I can recommend is that they work with their telecom and network security groups to find a device management solution that will allow access for other multipurpose devices.
I sincerely hope you guys can turn the corner because I recently returned my personal device to BBerry from the cupertino company and find the phone far better. But as a developer I find the gut wrenching pain involved in developing for your platform dissapointing.
01-09-2012 04:29 PM
I am meeting with my client one last time this week before they launch their app. I need to provide an explanation of why the app will not run on Blackberry. In addition, Blackberry users will demand an explanation when this Internationally-renowned Science Centre doesn't release its app for Blackberry. Can you please provide me with an official explanation in this thread, so that others can be informed and so that I can print it and bring it with me to my meeting?
So far I have gotten two different explanations:
1. Even though our app works on all Android/iPhone devices without any issues, it will never work on any of the current Blackberry devices because the amount of memory allocated to apps by WebWorks is too low to support apps that use the Google Maps API. [our app is too memory-intensive]
--> Can you please elaborate on why the app has no problems until after 30 seconds of use? I'm assuming it's because of the climbing memory which is addressed in my question below.
2. Despite the fact that dozens of users have been reporting issues with memory climbing in this thread in the past 4 months, no progress has been made on this issue and it is unlikely that Blackberry will ever be able to fix the problems with memory climbing. You said that you have been able to confirm that the problem is with Google Maps API climbing the memory rather than Blackberry.
--> Why is it that the memory climbs do not crash the Blackberry browser? My app works perfectly fine in the Blackberry browser (as well as all Android and iPhones) even hours later and then crashes in Blackberry WebWorks after 30 seconds. To me it seems like the memory-climbing issue is amplified by WebWorks.
I don't understand such a widely-used API (Google Maps) has a memory climbing issue. How are other apps getting maps in them?
3. I need your final confirmation that at this time, Blackberry WebWorks does not plan on supporting the Google Maps API.
--> We are planning Version 2 of the app and might delay launch if there is a way to get a Blackberry map to work on WebWorks without crashing the app after 30 seconds.
Also, this will have a significant impact on my decision to develop apps for the Blackberry platform because I specialize in location-based apps. If Blackberry can't support the Google Maps API, then I give up.
Location-based apps are the #1 trending app right now according to Webtrends.
01-10-2012 10:36 AM
Checkout this link http://www.map4app.com/
We have developed our own maps with full google-like compatible APIs. You can simply embed our maps in your mobile application (blackberry compatibility is ok) without changing a line of code.
01-11-2012 10:07 AM
Hello. We understand that Google Maps is a very popular framework that many developers leverage for their location based applications. We have run many tests using the API internally, and tested on both an Android device and a 4S. Our findings are that within a fairly short amount of time (about a minute), just panning around the map at a global level, zooming in a few times, and enabling a few layers, we can render a test application using the Google Maps API relatively unusable, with the map not getting redrawn, slow response times, etc.
We have also observed memory usage on a Windows platform in a desktop browser. Just firing up the page and initial render brings in a lot of memory, and panning around the map causes the memory to just continue to climb, until a certain point, when it starts to stabilize. It SEEMS that the API does have a cap of some sort when it starts to clean up some of its memory.
On our BlackBerry platform, all applications that make use of a BrowserField (which includes all WebWorks apps) share a dedicated section of memory to be used by WebKit. This memory is reserved for these applications, but is also a hard limited amount of memory. It would appear that the Google Maps API memory cap can exceed the amount of memory allocated to WebWorks apps on our devices. It should be noted that the browser itself has a separate dedicated memory space (I am not sure what size it is), which can account for the different behavior between WebWorks apps and the browser.
In a WebWorks app, you sometimes receive a low memory warning before the application is shutdown, but sometimes the system shuts your app down before WebKit has a chance to determine that memory is getting low.
Another option that you can consider for you application is to use BlackBerry Maps. You can invoke the BlackBerry Maps application with a KML document specifying the location, pin marker, etc. This will farm out to the BlackBerry Maps application; currently, you cannot embed BlackBerry Maps into your HTML content.
In the end, our system has a specific amount of memory dedicated to WebWorks applications. We support all manner of external, third party APIs, but your application and the frameworks that it leverages are constrained by the total memory allocated to BrowserField based applications by the system. We will certainly look at this memory cap and see if we can improve this scenario moving forward.
01-11-2012 11:28 AM
Thanks for the detailed overview kwallis.
Some things that would help in webworks api for this scenario:
1. current process RAM consumption. Max process limit.
2. Ability to request more. other mobile OS's allow for you to continue to request resources and other apps are shut down. to facilitate. Not always fast but in concert with 1 above devs can create a model that allows for asking for 1Meg increments over a period and at least handling gracefully if they don't exist.
3. BIG REQUEST as a work around: Plugin examples using the bberry map api. Support is mentioned on the dev site but none are provided in webworks leading me to believe that the same memory contraints would be applied (is that a fair assumption).
SO much cost has been incurred on BBerry dev efforts and dead ends that a corporate wide move to another OEM is probably a cheaper solution. Please help us avoid this.
01-16-2012 11:23 AM
Very good point. Let me take a look and see if we can get an example together that leverages the BlackBerry Maps approach.
01-18-2012 06:22 PM
kwallis..thanks for the detailed explanation about the causes for the out of memory error. It does appear that the behavior is different depending on the BB device used. If memory is 512mb we experience the out of memory error faster than on a BB running with1gb ram. However it appers that per app memory is very low compared to total available memory. For instance the out of memory error occurs on Torch 9800 even if app memory reaches 4-5mb. However there is so much more memory available. So maybe you guys need to increase the per app memory limit. That's just my suggestion. I think for Android the per app memory limit is between 16mb-48mb depending on device and also version. So I think there is lot of scope for allocating more memory to each process.
01-23-2012 12:10 PM
I hope the Blackberry team will directly address these issues raised (once again) by mysudbury. My project struggled with these problems last October and November. We put the project aside at that point. I was hoping that the issues would get resolved while we worked on other things. It is disappointing to find that they are still unresolved. It appears that our project is going to be canceled because of this--certainly the client is quite disappointed with the (unacceptable) performance problems on BB.
It is quite surprising that the Google Maps library is so widely used on other mobile platforms, but might not run on BB devices. If BB has its own Map library with the same API that might be workable, but far from ideal.
Unfortunately, our application was also crashing with low memory even without Google Maps. It happened faster when using the Maps, but also happens after 5-10 minutes of regular usage--the app uses several screens that each can have long lists that have a little text and an icon.
01-23-2012 12:59 PM
I was wondering if you have tried building your application with out latest WebWorks SDK for Smartphone v2.3? We have made improvements in how WebWorks applications handle memory and cleanup. I wonder if you would see a better experience with the latest SDK.
@kiranmobile This is definitely something we want to address, but unfortunately this is not something that can be managed by the WebWorks SDK directly. This memory allocation logic is in the platform itself, and what it allocates to the BrowserField that WebWorks uses at runtime. I am definitely keeping this on top of my list to track as we continue our work towards WebWorks support on BlackBerry 10.