04-14-2011 02:00 PM
Terrible time trying to compile my App now for os 6 phones. Seems to have problems if the overall size of the zipped assets are too large.
Just to test he code I have reduced my main audio asset by trimming it to a very small sample, and still have had to strip a lot of of code out as I was using JQuery libraries including JQTouch, and JQery UI (in themeselves a problem for the compiler due to many files named with hyphen (-) characters.
So finally have a stripped down code and small audio testing on the simulator ! But no go if I use the actual audio which is about 30Mb in size. I would also like to use the larger code as it is nicer with these extra UI functions from the libraries
Please, any help or experiences from the forum to assist my problem ? Maybe need to file bug reports, but theres many problems, this is just the biggest one, that needs addressed.
Or to be more specific:
1. the files with hyphens = I found a solution from a patched bbwp.
2. Failure to compile is the headache now.
3. Simulators have been acting badly.
Result of above is that the test debug cycle is terminally slow (and boring)
Any advice welcome. Also would welcome lobbying of RIM to improve the tools
04-14-2011 03:28 PM
I noted that you said the audio file size was 30 MB? Are you using .wav files?
04-14-2011 04:58 PM
An application that runs on the BlackBerry OS (5.0, 6.0) has a 7MB upper limit on size. The PlayBook does not have this same ristriction.
My guess is that you are packaging content that is exceeding the maximum allowed size and it is giving you those errors in response.
04-14-2011 05:30 PM
This is sort of like another thread where the developer had a LOT of files
A theoretical way around this is bar file hacking but this ...
a) Ain't guaranteed to work
b) Is fiddily
c) Is a last resort
d) Is probably frowned on by RIM
And I might have missed something (anyone who spots an omission pls speak up)
A bar file is a renamed ZIP so...
Package a very small version of your app
Now package your data files into a seperate BAR - you might have to do this more than once depending on just how much data you're tying to put in
Extract all the BAR files and open the META-INF/MANIFEST.MF files
Add the lines that look like this...
... from your fake data barfiles into your apps proper barfile. Be careful to keep the formatting correct or it'll fail
Put all your data files where they should be
Zip the whole lot up again and rename the zip to bar - you can now load it onto the simulator or sign it (not that I've had to try the latter yet)
Obviously you don't want to be doing this every build
04-14-2011 05:32 PM
I believe the issue is with the BlackBerry Smartphone and not the PlayBook..
04-14-2011 06:14 PM
Yes it is the os6 for phone; not the playbook I am talking about.
7Mb limit is very low. My App is in the iTunes store and I have seen others in there well over 100Mb. Obvious disadvantage of very large App is that customers will want to avoid slow downloads and eating up storage. However, at 30Mb it is no problem over WiFi. Apple had a limit in place (previously) of 10Mb for mobile data (3G etc) and I am not sure what the current limit is.
But more impotantly for me, encoding audio at 128kbps for a 30 minutes track leads to the data size of around 25-30Mb as an MP3
I feel that to target for example the Torch with same level of potential as the iPhone the 7Mb limit shoulkd be reconsidered. Aceptable limit maybe for expensive cell data but not so for Wifi, and modern smart phone should easily sport 8Gb-32Gb of flash memory.
04-14-2011 07:07 PM
Just been researching App store limits and the following article shows the upper limit to be 2Gb on Apple's store while Google Android store around 50Mb limit. The cell net (3g / EDGE) limit for iOS is currently 20Mb
04-14-2011 07:23 PM
The 7MB limit isn't an App World constraint. It is the constraint of a "compiled" application for the BlackBerry Smartphone.
You application can use as much data as you can store on the file system. The issue is with packaging all of this data compiled into the application itself.
You are able to distribute your application, check for wifi and then download the files you need via wifi.
04-16-2011 04:57 AM
First of all thanks for your prompt input, with out which I would be very stuck indeed. I have simply not found the 7MB policy mentioned anywhere so far, and am coming to accept this as the current state of affairs. Looking at the App World listings, it does seem that all Apps are meeting the constraint, with App size helpfully indicated on the store. This makes sense for the assumptions of mobile connectivity and relatively small flash storage on many devices.
I have to remain critical however overall, that RIM do not lay out the very important details and make it very clear. This is one very basic piece of information that a developer needs to know from the beginning. I think policy should be stated up front, and comilper errors should convey actual programming errors. I accept that the Webworks compiler is a convience made to package Web Apps, so by the time the errors emerge they have no relation to what is going on with the App which is just a packiaging of working Web code into a java framework
Anyway, moving on with the actual problem in hand. Essentially the method supported is to obtain assets such as images, movies, audio after the users have downloaded the App.
I have a problem with that since users will pay for an App expecting it to work straight away. Now thay are learning that a further download activity is required on first running the App. If anything goes wrong with the data downloading and saving on the memory of the device, their money is wasted.
If this is the practice then: on to the details. From what server does the data get downloaded ? We have to maintain and run a server for this purpose, and administrate such a download service ?
Next practical problem: where on the file system are we advised to store the data ? It needs to be private to the App.
Once downloaded, is there any chance it can be deleted by the user, and require a further download (hope not)
Finally, which APIs are to be used ? I find there is a blackberry.io.file that would probably hande the saving and reloading of the data. But not sure about the initial download. Perhaps an AJAX style request ?
04-16-2011 09:51 AM
I've just done some reseach by building apps of artificially bloated sizes to work out the current definitive answer to this
16M is the limit - A few 100K under and my test compiles, a few 100K over and it throws the somewhat less than meaningful Null Pointer exception
I note that the same limit is also a problem on Android going on what I glean from a Google search
The 16M problem does not occur on the Playbook.
I just created a 100M BAR file by adding an 80M file to an already sizable (21M) app
There is a reported problem with having hundreds of files - this is apparently due to a 4k limit on command line length under Windows - I don't know if the same is true of the Mac
There are two versions of BBWP, one to package for phones and the other to package for Playbook
It seems reasonable to presume that the development team have never seen the sort of apps we are able to create using the rich media today and that somewhere there is a legacy configutaton file that limits an app size to 16M. I would guess that someone just needs to change that number to allow us to create apps for today rather than yesterday
A server is a useful facility to have if for no better reason than being able to skip the compile step every time you make a change
Personally I have a cheap old PC in a cupboard as a development server - this is a great facility as I have it set up to allow me to treat it as an extension of my other machines by providing a SAMBA share to them. A personal server can also be on the Internet - you just need to point a DNS server at your home IP and port-forward it to your own box in a cupboard. A static IP and a decent DNS service make this very easy (I use GoDaddy for that part of things). If you can't have a static IP you can use a service such as no-ip to get the same external illusion of a 'normal' server.
Beyond that you will need a 'proper' server. As you're not going to be hosting a HUGE amount of data you can get away with an extremely cheap (a buck or two per month) service simply to provide the end-user files
Going past this requires a more accomplished server - I won't get into that situation here
A possible compromise
This is entirely dependant on what your app does - I can think of few situations where 16M of data files are required to let your end-user decide if they like the app. You may have the opportunity to convert the app to a try / buy with the initial download being relatively small then an upgrade to full purchase downloads the rest of the data from a server
Another approach that would work as a direct purchase is the same basic smaller version with a cache-on-demand approach - this can be easily managed by HTML5's cache support. This path to a solution means that your users only download small amounts of data at a time. I would give thought to also allowing a mass 'get everything' in case the user desires it though
A final thought is that the push service may prove useful as part of such a solution but as I haven't had a chance to look at it yet I can't say for certain whether it's a good