When creating complication images for old complications, we can see all 4 sizes:
But when I wanted to add images to new complications for Series 4, there are only 1 size?
The documentation (https://developer.apple.com/design/human-interface-guidelines/watchos/icons-and-images/complication-images/) stated that we need to support both 40/44mm, but how?
They are all the same icon. They all are looking for the x2 graphic to support their resolution. I would recommend using the 44mm as your x2 and let xCode scale it down when needed.
If you look at the documentation, at the end of each resolution it tells your which asset x1, x2, or x3 that it is searching for. They all search for x2.
Edit: OP has figured out that the icons have to be saved as PDF file and use the 40mm/42mm version, not 38mm or 44mm. Adding here for anyone else who is having a similar issue.
Related
I am running into an interesting issue; I have my app providing search suggestions to the QSB along with a movie poster via SUGGEST_COLUMN_ICON_1.
On versions of GTV prior to v3 I would get the poster displayed properly.
On v3, the suggestion is shown (under other) with only a portion of the poster shown in a square.
TV an movies suggestions, from primetime show appropriately sized suggestion posters in the qsb, is there a way to change the aspect of the suggestion icon displayed or maybe a different field that could be used for the suggestion ?
EDIT : code
I use a basic content provider to read the suggestions from sqlite; I use the following projections; i do not do anything beyond that.
projection = new String[] { Tables.MEDIA_SEARCH + ".rowid AS " + BaseColumns._ID,
SearchManager.SUGGEST_COLUMN_TEXT_1,
SearchManager.SUGGEST_COLUMN_TEXT_2,
SearchManager.SUGGEST_COLUMN_INTENT_DATA,
SearchManager.SUGGEST_COLUMN_INTENT_DATA_ID,
SearchManager.SUGGEST_COLUMN_INTENT_EXTRA_DATA,
SearchManager.SUGGEST_COLUMN_ICON_1 };
I spoke with the eng team and design team about this. On V3 the decision was made to constrain the 3rd party provided images to QSB into the square format you are encountering. The suggested method for serving images to qsb and maintain aspect ratio is to provide a square image where you manage the contents of it (1:1 ratio). Unfortunately there is not a way to force the aspect correction in the latest version for your case.
I am updating an app to have high-res images to be displayed on the new iPhone 4. My original images (in a UIImageView) were 100 by 100 pixels, so I updated my new images to be 200 by 200 pixels.
I know about the #2x convention, but my images are not stored locally in my project - they are retrieved from the web and being used for both iPhone 4 and other iPhones/iPod touches so they do not include #2x in their name.
Is there anything special I need to display these images properly? Do I need to send down separate versions depending on the device? Or can I send down a high-res version and set some sort of scale?
One issue I think may be causing this is I am building using Base SDK 3.2, which probably has no idea how to handle displays that are higher density than those pre-dating the iPhone 4. I think this may be an issue, because my problem seems rooted in the "point vs pixel" discussion in Apple's docs and the scale factor of an image:
http://developer.apple.com/iphone/library/documentation/iphone/conceptual/iphoneosprogrammingguide/SupportingResolutionIndependence/SupportingResolutionIndependence.html
Thoughts?
Many thanks!
I've had this problem too, the problem related to a clipping mask I was applying to the image. However, I was using 4.0 base SDK, 3.0 deployment target. What I did was check for the -[UIScreen scale] method I'd pass to the mainScreen and see if it was 2.0 (if it infact responded to it). If it was, I knew the scale was 2.0, I'd then call the method that applied the clipping mask with the proper scale. The problem wasn't passing in the data with the right scale, the problem was adjusting the core graphics code to account for the scale; it was applying the clipping mask in one scale, when the image itself was in another scale. If you show us code of what you're doing, I can revise my answer to show you code that will likely help you.
I'm the design guy on a new iPhone project and am curious on the eat practices for the up elements in the iPhone 3-4 dev. I know the dpi is different between the two and am curious how best to handle this with the dev guys. Do I need to make 2 of everything or do we need to figure how to make vectors of things like buttons , backgrounds and other images?
Any help , examples and links would be awesome. My goal is to do the best for the app with asking for dumb things from the developer
Thanks
Your only option right now is to generate PDF images, then draw them manually with core graphics if you absolutely need vector graphics. Otherwise, you can wait for someone (including myself) to get something written third-party like, or you can just make two of everything.
You need to make 2 files.
Lets say you have an image that is 48x48 called Hello.png
the hires version will be 96x96 called Hello#2x.png
The iPhone will automatically determine which image to use.
Thank you, come again.
I want to add high res images in my iOS4 app. I already read this http://developer.apple.com/iphone/library/documentation/iphone/conceptual/iphoneosprogrammingguide/SupportingResolutionIndependence/SupportingResolutionIndependence.html#//apple_ref/doc/uid/TP40007072-CH10-SW2 and a lot of other pages but I did not find the answer which ppi my image should have.
Currently, I have an image for example button.png with 160ppi and 50x30px. Now I want to create a high res image named button#2x.png. Is it correct to use 326ppi and 100x60px?
I already had a look at other iOS open source apps but each app did it on a different way. Most apps used 72ppi for normal and high res. What is correct?
Thanks for your answers
Walter
To be quite frank, I've not found a need to adjust pixel resolution for my images (i.e. I leave my Photoshop templates at 72 ppi and they're OK). If you just provide the correct dimensions for each format, the system will know how to deal with your images appropriately depending on the resolution of the device it's on.
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!