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.
Related
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.
I am getting ready to design a new iPad app, which will be locked in landscape mode. It's going to be relatively image heavy, as it will be a sales utility for hotels and resorts. There will be quite a few "hero shots" of hotels, meaning full or half screen images meant to highlight the property.
With the jump in resolution between the 2 and the 3, I'd like for it to look presentable on both versions. What is the standard way of designing for this? Do I include the highest res shots possible for the 3, and then let it scale down in software when rendered on lower versions? Do I include two versions of every image? Do I include just the highest resolution that the 2 can render, and hope for the best on the 3?
I am using the Jquery/Jqtouch libraries for an iphone compatible site. I am now stuck with a problem just in iPhone 4 (not in 2g, 3g or 3gs) where the text becomes blurry on one specific scenario. Below is how it happens
The site has one common div container.
<div id="container"></div>
The container is filled with content dynamically based on the user action. Below is the function that does that.
function loadPage(url, section, callback) {
$('#container').empty();
$('#container').load(url + ' ' + section, loadComplete(section));
}
One sample call to the above function
loadPage("Data.htm", "#Friends", null);
Basicaly eveything works fine except on one scenario where the amount the data on the container is huge (ie the #container height increases to 1500px+ not predictable). Now if i replace it with smaller data for different tabs on the same container then the text becomes blurry. Attached is the image
http://i.stack.imgur.com/XE9q4.png
Did anyone come across this scenario. Thanks in advance.
Try closing all your running apps besides safari. It sounds crazy but we have the same problem on the ipad and it just seems to be running out of memory at some point. Closing all the apps stops it. Other thing that seems to make a difference is -webkit-overflow-scrolling:touch, if it doesnt have this property then it doesnt seem to have the problem described.
i was able to fix this by applying the same settings to reduce flicker on the element in webkit browsers:
-webkit-perspective: 1000;
-webkit-transform-style: preserve-3d;
-webkit-backface-visibility: hidden;
Graphics elements must be "aligned" with the pixels on the screen; coordinates must always expressed as integral values and not floating values. If not, the subpixel rendering engine of the GPU would make it blurry, which is not a problem with animation but definitely one with static images.
In the native SDK, we have to make sure everything is aligned (such as using CGRectMakeIntegral()).
Since you're using a web framework, it's more difficult to tell how to exactly how fix the problem, but I would try to adjust the sizes of your to a precise size and not let the framework figure it out.
What content do you load? Images? Text? There's an internal limit on image sizes for the iPhone (about 4 Megapixels or so). It looks like the phone is trying to reduce the memory load of your website and reduces the resolution to non-retina values.
I can't say more without you posting code.
This is a shot in the dark, but have you aset your sizes using pt values for your block elements, and em for your text?
The iphone4 resizes your content to fit its higher-res Retina display (compared to the older iphone), and with that scaling i have sometimes noticed blur when using pixel values for block height, width, font size, etc.
Very hard to diagnose without seeing the actual code, but could be the issue.
In my case it was CSS
-webkit-transform: translateZ(0);
applied to one of the elements in body. So as Ariejan said, it's removing transition property that fixes it.
body{ text-rendering: optimizeLegibility}
could solve this issue, worth a shot if you haven't included it already
Sometimes, Text blurry may be cause of the iScroll Plugin. Did you use this?
Try to comment
trnOpen = 'translate' + (has3d ? '3d(' : '('),
trnClose = has3d ? ',0)' : ')',
Currently iOS supports three different art sizes: art for the 480x320 original iPhone screen, art for the hi-res 960x640 iPhone 4 screen, and art for the 1024x768 iPad screen, which in my experience is usually not the same as for the hi-res screen because of the different demands placed upon the different aspect ratio of the screen.
In a worst case, you could include three sizes for all of your artwork, and that's exactly what I did for the main element (cards) of my last game. However, it's ultimately wasteful in both download time and my time in creating them all.
What would y'all suggest as the best way to deal with the different requirements of the different iDevices? Here's a few general possibilities that I'm considering:
Include artwork in all 3 sizes.
Include artwork in just 1 size (the big one), but resize it on the fly as UIImages are created.
Include artwork in just 1 size (the big one), but make resized copies of it the first time a user starts up your app.
There are of course variants involving using some techniques for just some sizes (e.g., share artwork between the two big sizes, slightly resizing as needed). I'm interested in which method you'd use, with notes on the pros and cons of doing so. I expect the biggest cons are going to be: file size and any lag that might be caused in display or resizing of the objects. One of my biggest unknowns is how good of a job iOS does if you let it do the resizing, both in output quality and in timing.
I'm currently using artwork in all 3 sizes. If your artwork is in vector format and designed for both the iPhone and iPad aspect ratios, it's a simple batch action to create all 3 at the same time.
If you just include the highest resolution, the memory usage might be a problem with older iOS devices which have less memory to work with. The image quality and speed of resizing is not an issue, since both are excellent, if you let the OS resize the images. For me, I don't want to have additional code to handle resizing the same image for different devices. Otherwise it sounds like having just the large artwork and making sure it's resized correctly will be fine.
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!