Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
02-16-2011 01:11 PM
As far as I'm concerned, this is all wild speculation until proven otherwise.
I just added "import qnx.*" to my main class, and the package size went down 82 bytes.
It's my suspicion that an import statement is nothing more than a way of telling the compiler which of possibly more than one class with a given short name (e.g. DisplayObject) will actually be used in the code if you use a class with that name at all. Classes not explicitly referenced will (I believe) not be linked in at all (unless of course they are pulled in by other code indirectly, but still explicitly).
There's absolutely no way that all the classes in flash.utils/net/display/events/filesystem/text.* which I am not using in my own code, even indirectly, come to a total of 321 bytes of bytecode.
02-16-2011 01:21 PM
A few years ago, when I was trying to understand how the AS compiler worked, I did see a difference when including external libraries. I was trying to compare it to my experience with C/C++ compilers for compile time performance and if they "statically" or "dynamically" link to these libraries.
However, I cannot recall the exact outcome of those tests and if they are even compariable to current AIR compilers.
I did see a great increase in file size when trying to import MX classes to an otherwise light weight Sprite foundation. In the order of 40%.
02-16-2011 01:23 PM
@peter - that was just an example I threw out there - I've never done an import qnx.* - I just know when I cleaned up my imports it knocked my .bar file down by about half a meg. The biggest drop I saw though was when I cleaned out all the various background files I had been trying/icons.
02-16-2011 01:27 PM
Everytime I am about to release a BAR file to app world, I have a checklist of things that I need to do. One of them is to open up the BAR file and make certain there is not something odd in it that should not be there. Also, any images that are being installed, I try to bring the quality down to about 50-70% (JPEG) to help reduce overall size of each.
02-16-2011 01:40 PM
John, I suspect AS2 compilation behaviour won't tell much about how AS3 works.
I'm going to call it conclusive that at least with the command line compiler doing a bunch of wildcard imports does not correlate to any relevant increase in .bar file size. I just threw in another half dozen mx subpackage imports and, overall, there's a 227 byte difference between having none of the wildcard imports and having all the ones I now have.
Whether this is different from you guys using IDEs is another question... I could imagine some ways in which an IDE might be managing to toss in lots of unused junk just because you have imports for them.
Why doesn't someone with an IDE try with my set, for comparison, so we can be sure any knowledge-base article (as Elena just suggested) isn't stocked with misinformation. I hate "cargo cult" programming...
Here's the full set I have now:
import flash.net.*; import flash.display.*; import flash.events.*; import flash.filesystem.*; import flash.text.*; import qnx.*; import mx.charts.*; import mx.charts.chartClasses.*; import mx.charts.effects.*; import mx.core.*; import mx.core.windowClasses.*; import mx.effects.*;
Note that the 227 byte difference is when compiling with debug mode OFF. It also varies slightly each time I compile... just got 216 bytes, then 235, for example. I suspect that's related to embedded timestamps or something like that.
Just tried with debug mode ON, and the difference between having those imports and not is only 88 bytes this time.
02-17-2011 03:53 AM
1. i didn't added any .* statement in my imports.
2. There is no image in my project, i am using only library components.
3. I build a new "Flex mobile project" without any additional code, the size of the bar file is more tha 1mb.
Why there is too much difference b/w "Actionscript mobile project" and "Flex mobile project" bar file size.
How to reduce the file size.
Thanks again in advance.
02-17-2011 03:59 AM
when you are building a flex project, you are basically loading a lot of things (components, gui stuff, etc) you do not need. its there to make things easier and more convenient for you. the trade off is the size of the project after you build it. you cant really go below the ~2 mb starting point when using flex mobile from what i've seen.
02-17-2011 04:18 AM
@JRab- Its seems to strange for me because without any source code the size of .bar is more than1mb, which is not significant.
Can any one confirm through "RIM Developer" for this. And is there any way to reduce the .bar file size.