2. That's hard to estimate, it will depend on the hardware capabilities of the device, bundle size, and amount of processing you do in the didFinishLaunchingWithOptions method.
But keep in mind that you should return as fast as possible from that method. If your app takes too long to load (over 20 seconds I think) iOS will kill it.
You mean weight, as in size. You can only estimate it. Compile the app for release then compress the binary. That size in the App Store is usually just below that compressed archive. No way to tell exactly.
You could estimate the size of your graphics by taking width*height*(4 bytes per pixel if there's an alpha channel, 3 otherwise) and then throwing in an estimate for compression factor.
In your case, for RGBA PNGs with 50% average compression 550*800*4*40*0.5 is around 35 MB. For RGB JPG, with 70% compression 550*800*3*40*0.3 is around 16 MB.
My suggestion to minimize app load time would be to load them in the code on demand when you want to use them as opposed to loading them all at app load time.
__________________
Apps: Exian - Brick out in space
You could estimate the size of your graphics by taking width*height*(4 bytes per pixel if there's an alpha channel, 3 otherwise) and then throwing in an estimate for compression factor.
In your case, for RGBA PNGs with 50% average compression 550*800*4*40*0.5 is around 35 MB. For RGB JPG, with 70% compression 550*800*3*40*0.3 is around 16 MB.
Why would he calculate the uncompressed image size to then estimate the compressed size again? He already has the files and can see how large they are. But that's just the size of the files. There could be other resources involved, then the app binary itself. Compiling it is the quickest, easiest and most precise way.
I don't disagree that throwing the pix into a binary to find the size is the most accurate way to calculate the size. However, if you haven't already got the images (I didn't see anything in the posts to say that he does) and you're just kind of doing some back of napkin calculations, then you can use the formulas in my post.
__________________
Apps: Exian - Brick out in space
(I didn't see anything in the posts to say that he does)
I don't see anything that he doesn't.
Also, the file size of the image will depend greatly on the contents, not just format, pixel-size and compression. Try creating a 550x800 image in Photoshop that is just white, and save it to JPEG with quality 7. It will be less than 50KB. Then apply the Noise filter to the image and save it again with the same settings. It will be about 1MB.
Yep, you're right, there are lots of variables. However, if you make some reasonable assumptions you can come up with a reasonable estimate. If you already have the images, you don't need to estimate.....
__________________
Apps: Exian - Brick out in space
By "wight" what will be the final all size in kbytes
I have only the default processing in dudFunushLunchingWithOptions
Well, I don't know about you guys, but my lunches can take several hours and that's without many options....
__________________
Highlight PDF text like no other app: iHighlight (now available for iPad and iPhone!)
-----
Create iPhone lists with no typing: Insta-List
-----
Make spelling fun, and create your own tests: iWillSpell
-----
A fast, elegant flashlight app: Insta-Light
-----
I am writing a program for ipad that loads around 40 pictures at size of 550 * 800 pixel.
I have 2 questions regarding it:
1. can I have some kind of estimation what will be predicted application wight?
2. what will be the estimated loading time of the application?
thanks ,
Shlomi
I think the pertinent question here is why do you want to know this?
__________________
Highlight PDF text like no other app: iHighlight (now available for iPad and iPhone!)
-----
Create iPhone lists with no typing: Insta-List
-----
Make spelling fun, and create your own tests: iWillSpell
-----
A fast, elegant flashlight app: Insta-Light
-----