The new iPhone is being presented..
it has a new resolution aspect ratio. (1136 x 640)
Does anyone know how to upgrade apps to support the new resolution??
Thanks!
Normal UI components like buttons etc. should be update with the new SDK - Like on the MBP Retnia. But graphics you have made like images, needs to be update with a bigger dpi - This is only a guess, but that was how it work to MBP Retnia
We are using Canappi to generate the Objective-C code that works on both resolutions (and with iPad too). Canappi works like Interface Builder, but in a textual form (which is much easier to use if you ask me). This is how you specify the position of your controls for each resolution and/or form factor:
layout myTabletLayout {
text name (10,60,100,30) { ... }
}
layout myPhoneLayout {
text name (10,60,100,30 + 0,10,0,2) { ... }
tablet myTabletLayout ;
}
the +0,10,0,2 is a shift that is applied to the original coordinates when the app runs on an iPhone 5. That means that you can easily resize tables, space out controls or even, and that's really cool, bring controls which are displayed off screen on the iPhone 4, back into the iPhone 5 view bounds.
Related
I completed the development of my app, using a layout of form components that perfectly suited the iphone 6 in the simulator. I used a combination of Theme styles (always Base Resource) and some coded tweaks to the look and feel.
When i ran this up against the iphone 5 i had expected naively the display to shrink to fit, as you may expect with browser applications, but instead my components (labels largely) went off the edge of their containers. Panic.
I ended up having to measure the display height and judge the device from there and code up different sized components to get the right fit. This took some time.
Next to TestFlight in the AppStore. As part of wider testing I decided to install on my iPad 3, only to find the layout components rendered all very small. Panic.
I have now spent a couple of days resolving this just about. I basically use this method to determine the type of device 'category' to then apply the size of font or fontimage etc.
public static ScreenSizeEnum getScreenSize() {
if (Display.getInstance().isTablet() && Display.getInstance().getDisplayHeight() > 2000) {
return ScreenSizeEnum.TABLET;
}
else if (Display.getInstance().getDisplayHeight() < 950) {
return ScreenSizeEnum.SMALL;
} else if (Display.getInstance().getDisplayHeight() > 949 && Display.getInstance().getDisplayHeight() < 1200) {
return ScreenSizeEnum.MEDIUM;
} else {
return ScreenSizeEnum.LARGE;
}
}
This is unsurprisingly not foolproof. The Ipad 6 plus is not recognised as a tablet but has a large display height, but one of the Nexus's are a tablet but has a small display height.
My question is, how on earth do you get around this problem?
Tablets and phones come in different sizes but its important that you still get a quality component render regardless of form factor.
The CN1 KitchenSink demo didn't really address it. Many thanks in advance.
From the description of the issue it seems you are thinking about a tablet as a "large phone" which is the wrong way to look at it. A tablet has similar density to a phone but more real-estate in inches which means you need to design your app so it will use up the additional space more effectively.
Here are two screenshots of the same Kitchen Sink demo one running in an iPad and the other running in an iPhone. Notice the UI's look very differently as we adapted the UI to use up the additional space. Image's (e.g. multi-images) and fonts are determined by density not by the amount of pixels as the goal is to use the extra space not to fill up the screen with larger images/text.
since iPhone 4 now has 640X960 resolution i am confused how to build a proper UI for both 320 X 480 and 640 X 960 resolutions.. if i only use images and stuff of 640X960 resolution will it automatically adjust itself for smaller resolution iPhones.. if not what is the best way to differentiate on basis of device resolution??
You make 2 of each image - the first one at normal scale and named the usual "whatever.png". Then you make a second hi-res version of that image at double the scale and name it "whatever#2x.png". Then, iOS will handle the rest. You'll add both of those images to the project, and anywhere in the code that you reference "whatever.png", the system will take care of grabbing and using "whatever#2x.png" when and if appropriate, so you don't have to fuss with much. That's it. Simple.
In Interface Builder, just lay things out like normal using the standard sized graphics. In code as well, just reference images as usual, referring to the standard-sized images. So long as the higher-res counterpart is named with the "#2x.png" appended, everything will just work.
So, just as an example, say you currently have a project with a button image sized 40x100 named "awesomeButton.png". To support the retina resolution, create a new button image sized at 80x200, and name it awesomeButton#2x.png. Import it into your project and iOS takes care of the rest.
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!
I've run into the issue of using a UIBarButtonItem with a custom color. Everything out on the 'net seems to indicate that the only way around this lack of official API support revolves around the use of images. This is all fine and dandy when developing for pre-iOS 4 devices, except when using the new iPhone 4. Creating an image for iPad and pre-iOS 4 devices is straightforward enough, but the images developed for those devices look absolutely horrid on iPhone 4. I suspect that this problem will be exacerbated further with the introduction of next generation devices.
Consider the example below. Notice how the default colored button is nice and smooth, but the iPhone 3GS image looks terrible. It does not seem very scalable (pun intended) to have to include multiple images for different resolution devices.
In the absence of an official API for changing the color of a UIBarButtonItem, what strategies are out there for creating images that scale well against differing resolution devices? This problem is hardly unique to UIBarButtonItems, how is the community adapting to other UI elements that are bitmapped? Is there a better solution for this particular case than using an image (such as using Quartz to draw it)?
If at all possible, please offer concrete code examples.
You can list any image as Image#2x.png along with Image.png and the system will select the appropriate image at runtime.
If you look at the source for Three20 you can see how they draw custom buttons and shapes that will scale well, regardless of resolution.
Give Opacity (for Mac) a try. Draw your button in it with vector elements and effects, and it'll spit out the necessary Quartz code to reproduce it, drawing natively in your iOS application. You get Retina (#2x) support automatically.
Been over a year since I posted this question, but ran into a use case where I wanted to be able to do this, so instead of having to draw or otherwise create the buttons, I decided to write an open source application to create them. This application uses private APIs to change the colors of the UIBarButtonItem objects and then uses a graphics context to save them to a determined location on your computer's file system. This way you can have pixel perfect UIBarButtonItem images to use in your UIToolbars.
The app creates both the standard and #2x resolution images.
UIBarButtonItem-Generator # GitHub
Any vector drawing app may work, but I would also consider povray, which allows you to create in a C-like scripting 3D language, then export any pixel size you choose.
http://povray.org
I have the same problem with navigation bar so solve as the following:
first i subclass my navigation bar
inside this class
- (void)drawRect:(CGRect)rect
{
UIImage *image=[UIImage imageNamed:#"MyImage.png"];
self.frame=CGRectMake(0, 0, image.size.width, image.size.height);
self.backgroundImage =image;
}
finally save the same image with different resolution With #2x at the end
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.