Does anyone know what will happen with existing apps when they run on the iPhone 4.0 in terms of the new screen resolution? I am assuming, just like developing for the iPad that there should be no hard coded screen resolutions in your code.
I'd also like advice on the best way of writing robust code to work well on any device. For instance, detecting the screen resolution is not enough - on the iPad the screen is physically bigger so you can display more items on it. On the new iPhone the screen is the same physical size but higher resolution, so the likely thing is that you wont want to display more items, just higher resolution versions of them.
Any help would be useful,
Regards
Dave
EDIT: I have read the other similar posts, I guess what I really would like to know is what is the recommended way to write code for all App Store devices in a robust way so they a) all work b) make best use of the device.
UIKit has be redesigned so that old apps just work unmodified in the iPhone 4. There are then several things you can do, some programmatic and some by just adding higher resolution images to you app bundle.
Firstly, and most simply you can include new double res images that are used by your app with a suffix of #2x in the name. i.e., Event.png as well as Event#2x.png. [UIImage ImageNamed:] will automatically look for the a file with this suffix if it is running at the higher res.
All the other UIKit stuff now uses points instead of pixels. So for both old and new apps full screen is still 320 x 480 points. This pretty much means everything will work including touches, etc. Although they may now return fractions of a point.
The only real gotcha so far seems to be if you use CGBitmapContextCreate as this uses pixels and requires some jiggery - pokery.
Related
As I say in the title, I'm developing an iPhone app. I use nib files, I don't use any storyboard, and I know that for iPad I'll need to replace some of the controls I currently use for iPhone, since, for instance, in iPad is more suitable to use popovers in some places, and some other considerations. But I'm not sure if I'd need to create a separate nib file targeted for iPad per each nib file I have now for iPhone, or it should be just the convenient thing but not needed, or I can keep just one nib file if views are for example scroll views or table views, and just resizing things would be enough...
What I want is some guidelines to avoid redundant files and work when creating an iPad version of an existing iPhone version, and what the best practices are, since I don´t find how to handle this, programmatically speaking, neither in Apple's docs nor in posts...
Thanks in advance
EDIT. A question about dealing with icons and images: let's say I have an image view that is 50x50 in iPhone. I have two .png images for the iPhone version of this image: 50x50 and 100x100 for retina display. Let's say I need this image to be 80x80 in iPad. What should be the best way to deal with this: having 4 versions of the image (50x50, 100x100, 80x80, 160x160)? or just having the greatest versions (the 80x80 and 160x160 for iPad), and just resizing them to be smaller for iPhone? In general, what is the best practice about this, having one image file per each size you need, or just having the greater you need and fitting it to smaller sizes?
At xib files you should use the AutoLayout with constraints. That was introduced in ios6.
The key and the war with patience and time it will be setting up correctly those constraints.
One xib can be used to iPhone and iPad too, not needed 2 separate files in this way. As speed of development the 2 file are faster to develop, at least for me...
You can usually get away with not re-implementing a lot of .nib files to be iPad specific and just reuse your pre-existing ones. I have a lot of projects that do this.
That said... you usually have to reimplement the top level container .nib to be iPad specific and you really need to think about where you can take advantage of the larger screen size on iPad and adapt or create new .nibs as you see fit. While you're in any .nib... consider updating it to use AutoLayout if you can!!!
Using child view controllers (UIViewController has had childViewController since iOS 5.0) and other libs like for example SGBDrillDownController (you can find it in CocoaPods.org) might be things to take a look at.
On your images question... If the images scale well and don't get too anti-aliased looking when you go from largest to smallest rendition then going that route can make your life a lot easier. I have found however that to get a decent looking image it is best to use scalable vector art and then create a separate rendition for each size needed. Getting the best possible graphics possible is certainly a key to success.
I recently created an app in flash cs6 to be used on my iPhone 4.
The app doesnt need to work through the app store its just a tech demo but when i put the app on my device all the animations become really slow/choppy.
My iPhones up to date and im using air3.2 (i did try updating to air 3.7 but then my application just became a white screen)
I have also tried cacheing all the movie clips as bitmaps bit it doesnt seem to make a difference.
(the app works fine inside the flash simulator)
please help?!
There could be a few reasons why this is happening,as I am taking a punt here as you havent gave much information on what your doing.
but your frame rate may have effect.. how are you creating your tweens?timeline animation or tween scripts.I found tween scripting works better as its distance over time opposed to distance over frames.
Also depending on your animation, images sizes, event listeners etc..
You need to take inconsideration your device itself and the resources it has available, free memory or actual storage available.
The reason it will work freely on your PC would be due to the fact of less limitations, your pc has more to computes and resources to throw at your application .
Add this line to your code to check your memory:
import flash.filesystem.File;
this.addEventListener(Event.ENTER_FRAME,performMemTest);
function performMemTest(e:Event):void {
trace(System.totalMemory);
}
I have read anywhere around 14MB++you may experience problems.
My dilemma -
I have a universal app that holds a lot of images and icon (about 1,000).
In many cases i use the #2x version as is for the iPad version, in other cases it is to big even for the iPad.
I see 2 options:
Add a unique images for the ipad (large the app size).
Scale the images every time i use them?
Would like to hear notes or ideas.
Thanks
Shani
I think you will here different suggestions here. It really depends on your requirements and whether it is more important (mandatory?) for you to reduce the size of your app or make it more responsive at run-time.
Are you going to scale the images down one-by-one (meaning that in a view you will have only an image)? Or are you going to scale down a whole lot of images to display, e.g., in a table view? This will impact greatly the user experience...
As to the "every time", you could think about using a cache, so that you only resize each image just once. This would be like an intermediate solution, but again, it depends on your app (if very many images will be loaded, the cache will become very large, so in this case it could be suggested to go for option 1).
Also, the iPad 2 is pretty fast; iPad 1 a little less, so you could also take into account that.
In general, I don't think that scaling down will add much overhead, but YMMV...
So when I run the application from the device the pictures show up and everything works great. However, when I move to the device I run in about 10 out of 38 pictures that don't show up. I am pulling the names for the images from an sqlite database and I already checked and the names are correct, case and everything. I checked the bundle and the images are correctly in there.
Does memory play into effect in this? I am not really sure what else could cause this to happen??
Thanks!
Solution:
The files somehow were not saved properly and were unable to be opened by say photoshop or paint even. So with the files not being able to be open they weren't showing up... Thanks for the help everyone!
First thing to check is the case of the strings you're using to refer to the resources. The iPhone is case sensitive, but the simulator is not.
Oops, just seen that you checked the case. Better log all your UIImage creation calls then!
The simulator accepts a wider range of image formats. Sometimes you had a specific file type that the device cannot display. Double check the 10 files looking for some difference from the others ones.
Yes, memory absolutely plays into this. Check your UIImage creation calls and make sure they dont return empty. Also, check to see if youre getting memory warnings in the console window.
Generally, if in-memory size was the culprit, your application would crash with a low memory error on the device. However, it seems like the images just don't display.
One other thing that can be going wrong is the size of the images. UIViews on the iPhone can only have dimensions smaller than the maximum texture size supported by the GPU. Apple states that this is 1024 x 1024, but I've found it to be more like 2048 x 2048 on even the original model iPhone. You may be creating a view for some of these images that exceeds this size in one dimension, but your Mac has a larger maximum texture size on its GPU and so it displays fine in the Simulator.
Apparently the iPhone caches the launch screens. So in my case, I had to reboot my iPhone before being able to see the image.
According to Apple, the iPhone 4 has a new and better screen resolution:
3.5-inch (diagonal) widescreen Multi-Touch display
960-by-640-pixel resolution at 326 ppi
This little detail affects our apps in a heavy way. Most of the demo apps on the net have one thing in common: They position views in the believe that the screen has a fixed size of 320 x 480 pixels. So what most (if not all) developers do is: they designed everything in such a way, that a touchable area is (for example) 50 x 50 pixels big. Just enough to tap it. Things have been positioned relative to the upper left, to reach a specific position on screen - let's say the center, or somewhere at the bottom.
When we develop high-resolution apps, they probably won't work on older devices. And if they do, they would suffer a lot from 4-times the size of any image, having to scale them down in memory.
According to Supporting High-Resolution Screens In Views, from the Apple docs:
On devices with high-resolution screens, the imageNamed:,
imageWithContentsOfFile:, and
initWithContentsOfFile: methods
automatically looks for a version of
the requested image with the #2x
modifier in its name. It if finds one,
it loads that image instead. If you do
not provide a high-resolution version
of a given image, the image object
still loads a standard-resolution
image (if one exists) and scales it
during drawing.
When it loads an image, a UIImage object automatically sets the size and
scale properties to appropriate values
based on the suffix of the image file.
For standard resolution images, it
sets the scale property to 1.0 and
sets the size of the image to the
image’s pixel dimensions. For images
with the #2x suffix in the filename,
it sets the scale property to 2.0 and
halves the width and height values to
compensate for the scale factor. These
halved values correlate correctly to
the point-based dimensions you need to
use in the logical coordinate space to
render the image.
This is purely speculation, but if the resolution really is 960 x 640 - that's exactly twice as high a resolution as the current version. It would be trivially simple for the iPhone to check the apps build target and detect a legacy version of the app and simply scale it by 2. You'd never notice the difference.
Engadget's reporting of the keynote included the following transcript from Steve Jobs
...It makes it so your apps run
automatically on this, but it renders
your text and controls in the higher
resolution. Your apps look even
better, but if you do a little bit of
work, then they will look stunning. So
we suggest that you do that
So I infer from that, if you use existing APIs your app will get scaled up. If you take advantage of new iOS4 APIs, you can get all groovy with the new pixels.
It sounds like the display will be ok but I'm concerned about the logic in my game. Will touchesBegan positions return points in the new resolution? The screen bounds will be different, these types of things could potentially be problems for me.
Scaling to a double resolution for display purpose is straight forward, but will this scalling apply to all api's that input/output a screen coordinate? If not things are going to break aren't they?
Fair enough if it's been handled extensively throughout the framework.. I would imagine there are a lot of potential api's this effects.
For people who are coming to this thread looking for a solution to a mobile web interface, check out this post on the Webkit blog: http://webkit.org/blog/55/high-dpi-web-sites/
It seems that Webkit has solved this problem four years ago.
Yes it is true.
According to WWDC it appears that apple has build it some form of automatic conversion so that the resolution for applications will not be completely off. Think up-convert for dvd to HDTV's.
My guess would be that apple knows what most of the standards developers have been using and will already be using these for an immediate conversion. Of course if you are programming an application to take advantage of the new resolution it will look much nicer than whatever the result of apples auto-conversion is.
All of your labels and system buttons will be at 326dpi but your images will still be pixel doubled until you add the hi-res resources. I am currently updating my apps. If you build and run on the iPhone 4 sim then it is presented at 50%, go to Window > Scale > 100% to see the real difference! Labels are smooth, my images look shocking!