I have a tab bar based app that runs like a charm on simulator and tested on instruments, the app contains 6 tabs, the first one that is been loaded contains only 8 round rect buttons (with a little png image on each one, image size is very small), each button when touched (up inside) will display a diferent view controller. each one of the other tabs contains a table view except for a one that contains a webView that loads a 25 MB PDF file. However, when I try to test the app on iphone device (iphone 1st genration the one that is before 3G, that runs ios 3.0.1) that app takes around a minute to load, how come that ??? what is the reason for this weird problem ?
I guess that's because you're loading a 25MB PDF file. This is huge for a 1st generation iPhone.
Its probably because the simulator uses your computer's resources, for it a 25mb pdf file might be nothing whereas it porbably is a huge strain for the iphone with its limited resource count. As has been stated above,try it with a smaller pdf , it should be much much faster on the iphone.
Try changing the PDF to something that is tiny, 100KB maybe and see if it is still doing that. If not then it is due to the fact that the app is trying to load the PDF when it runs. Remember that the device may also be scanning the app to see what is in the bundle and that could also slow it down. Never the less, a 25MB PDF is far too large to have on any device, even a computer. Trying loading it on a computer zooming right in and scrolling about, it will undoubtably lag.
If you want to reduce the size of the PDF, use the Quartz Filter that comes in Preview as this should really reduce the file size.
Related
I am currently developing an app targeting the iOS 7 environment.
I found that if I set the nib simulator metrics size to 4in with simulator size 3.5in, when the app launches, it will give me a screen with cut off elements.
And if I set the simulator size to 4in with a simulator metrics of 3.5in, the layout will be shrunk.
So basically it's like a 4in screen on a 3.5in device and vice versa.
But when I navigate away from that screen (within the app) and come back to the page, it will resize to the size it should be.
But it seems to be a hit or miss. It happens to some of the views, but some other views like UITableView do not resize properly.
Another thing to note is that even when I set the metric size to None or Freeform, it will not auto-resize to the proper size.
Is this normal?
My fear is that if I deploy via TestFlight, and I had the nib set to one of the size and my testers have device of the other size, they will see improperly sized screens.
Does anyone have similar experience? Any fix to this problem?
Most of the times when I run my application , the marked area starts blinking continuously. Sometime , the left and right margin of the iPad also starts blinking. It happens randomly.
I would like to know whether its a hardware issue , which is happening on my iPad only(iPad 3)
or it has something to do with my application memory allocation .
I have done quite a search on the web regarding this but cant find anything.
About my application :
It captures data from the user on the table form , then we capture some images using av foundation and upload the data and images on the server . The uploading is done asynchronously .I also perform some image operations on the images captured.
Note- This blinking/Flickering only happens when I run my application and that too randomly. iOS version is 6.1.
I faced the same problem with one of my application ,in which I was using the high defination images . If you are running your app on to non-retina device , the images getting consumed at that time should be low resolution ,i.e. Suppose you are setting a background image for any view then you must be having you must be having to images for background . let one be having resolution (320*480) for non-retina , and another (640*960) for retina . also you must follow the naming convention so that the device automatically the right image according to the device's resolution .
backgroundImage~iphone.png (for non-retina iphone)
backgroundImage~iphone#2x.png (for retina iphone)
backgroundImage.png (for non-retina ipad)
backgroundImage#2x.png (for retina ipad)
Also check the memory allocation using the Instrument in XCode and release the un-necessary wherever possible
Hope it will help you !
I have 2 iOS apps that have been in the market, 3 years on iPhone, 2 years on iPad HD version. The apps are a popular reference tool in the medical field. They are both comprised of 1100+ images. The current app size is roughly 52mb.
Approximately 400 images will be redone. They are currently jpg and low resolution. The replacements will be png, with higher resolution.
I'm uncertain on pixel size for these images. If they are in the 280x280 range, each file is about 100k, if in the 560x560 range, each file is almost 400k.
So I'd be looking at additional 40mb for the smaller images and 160mb for the larger.
There are plans for another 400+ images in the near future. So, I'm somewhat concerned with final app size.
If I went with the larger size for Retina devices, can I downsize for non-Retina devices?
If I supplied both sizes, image.png and image#2x.png, that would be 200mb just for these images.
I'm a little uncertain on how to manage these with regards to their individual size and, more importantly, their total size.
Any comments or suggestions are welcomed and would be helpful.
TIA,
jb
Here are a few options you have:
1. Downsizing Retina Images
I would not recommended downsizing retina images for the non-retina devices. This produces non-optimal performance and makes the images look bad. Your still loading in all the pixels of a retina image, but only displaying 1/4 of them.
2. Bundling All of the Images
Honestly for a medical reference app, I think it would be understandable if your app size would be quite large. I wouldn't imagine people would need to download this app over 3G or LTE. Your users understand this is a large database app which provides high resolution images, thus they should be okay with the large app size via this method.
3. Hosting the Images on a Web Service
Another alternative would be to host the images on a server, allowing them to be downloaded individually as needed, or in bundles. I think your users would prefer being able to fully use the app without internet connection rather than having a smaller app size.
4. Alternative Image Loading
This approach takes a bit of work and could be a little risky. You could bundle only 2x versions of your images into the app. Then on App launch you could force the user to wait until you resize all the images to their 1x counterparts and save them off to the disk. Then you could create an image loading convenience method which loads a UIImage from either disk or the app bundle based on whether or not it needs a retina image.
I definitely recommend option 2 for your purposes. I only mentioned the others to be thorough.
I've made an "magic" app with a lot of coins/playing-cards.
Therefore I have a lot of images of coins, dollar bills, playing cards etc. (regular + retina resolution)
This results in a relative big file size of the final app, which I would like to avoid; since it can't be downloaded without a wifi-connection.
Currently it's 48.6 mb when downloading it from the App Store.
The images (100+) is all .png's saved in two versions, for the regular and retina displays.
Is there anyway to optimize this and reducing the final file size of my app?
I've considdered only storing the big (#2x) .png's and the scaling them accordingly.
I have had a lot of success using ImageOptim to compress the size of images in my application.
Also, if your images are png-24, you can reduce them png-8 and save a lot of space as well. png-8 doesn't support transparency though.
Why save 2 sizes? Do you have to display so many at a time that loading the retina version takes up too much memory on a 3G? Personally I don't think you should still think of supporting such an old device. Apple also dropped support for it a while ago and it really is lacking the memory for some decent applications.
Also, have you tried using some tools to compress your images without the users noticing it? like photoshop "save for web & devices", or yahoo's services etc.
why do you need to store TWO versions of images? Just use hires imges in regular displays. Or, if you whant so, you can distribute 2 apps...
Are you shure, that your images has necessary sizes? i mean retina display has 680x920 pixels. if you are don't zooming images, you don'n need to make them bigger. And in this case, mb *.app file, in archive... there must be 1000 images...
For example, preparing a launch screen of 320 x 480 would have to be changed....
How is that going to work for us? Are programmers always going to have to be submitting a high-res that will be scaled down for old devices such as the iphone 3g?
The size of the screen is basically 4 times on a pixel by pixel basis. So each pixel of your image for example gets boosted to 4.
What this means for you? You don't have to change your App, your app will scale to the hi res screen for you, same with your UI and images within your UI. Of course if you want to take advantage of the better screen quality you will have to submit hi res images.
I haven't looked at going the other way but I believe it would be a similar case.
One exception to this is text. It automatically scales to the higher res for you for free. So text will look super sharp. One problem with this is if your loading image has text based on the original load screen that wouldn't look the same as when the high res text loads.
Strictly speaking, anyone who's seen the documentation on how they're handling this is still under non-disclosure until Monday, when the new iOS ships.
Suffice to say, it's clever. You'll be able to put both high and low-rez versions of ALL your images into your app, and then load them into your app in a way that's totally transparent from the code side. The device will make its own call about which version of the image is appropriate for the kind of screen it's got.
Now that the WWDC 2010 videos are available for free to any registered iPhone developer (or ADC member), I recommend watching Session 134: Optimize your iPhone App for the Retina Display for a full description of what you need to do to support the iPhone 4's new display.