Is there any alternative or work around so that I can use zoomScale in Iphone OS 2.0. It seems the property is only available in Iphone OS 3.0 or later?
I have two subviews in my UIScrollView and if the first subview reach a specified scale then it will change to the other subview and save the current scale to zoomScale so that the new subview will apply to the previous scale. Like for example in, scrollViewDidEndZooming,
scrollView.zoomScale = scale;
When I run my app in Iphone OS 2.0, it gives me error saying invalid zoomScale invalid selector.
How can I work around this?
Thanks.
The only way to achieve the effect of non-initial zoom=1 on early iPhone OS platforms is to manually scale your drawing and initial view positions as if zoom were not equal to one. Painful. But conceptually all your doing (if you solve this problem) is adding one extra scale factor related to the difference between zoom=1 and the initial zoom factor desired.
A right old pain involving lots of code edits to add the extra scale factors but at least this gets the result! On iPhone OS 3 (if your code runs on multiple platforms) the factor will always be unity 1.
Related
I am porting an existing cross-platform program I have made in C++ and with OpenGL/ES on the iPhone. Please keep in mind I do not know anything about Objective-C...
I have just briefly edited the Objective-C files of one of the tutorials to initialize OpenGL properly for the iPhone, and to simply call my C++ multi-platform code for everything else.
My program will only run in landscape mode, that is why I have set it as the only supported interface orientation (in the info.plist file).
What I want to know is how I should tell OpenGL to rotate according to the landscape mode. Currently I have added a glRotate that does it before draawing, but it is a dirty trick.
Another thing : I try to convert the touches into mouse click coordinates equivalent with another quick method, and I get a point located at a distance of 80 pixels on the X axis and 80 pixels on the Y axis. I added yet another dirty fix (with GlTranslatef) to this mess and I get the correct coordinates, except... color picking is broken.
To be clear, color picking does not detect anything on the 160 first pixels on the left (which is both 2 * 80 and 480 - 320, so, huh, 99% chance it is caused by my dirty code...)
What is the proper way of dealing with this ?
You shouldn't have to do anything to use OpenGL in landscape mode. I suspect you aren't actually going into landscape mode. You need to override shouldAutoRotateToInterfaceOrientation: in your view controller:
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)orientation {
return orientation == UIInterfaceOrientationLandscapeLeft; // Or ...Right
}
To verify that it's working, put some random controls (e.g., empty buttons) in the corners of your view, with Interface Builder in landscape mode, and see where they pop up.
On iPhone 3G, this is a bad idea. Rotate using shouldAutoRotateToInterfaceOrientation use OpenGL hardware to perform this operation, so it is better to use a rotation in your OpenGL code. If you have no performance issue, keep it simple.
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.
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 would like to imitate the minimize window effect of OS X on the UIView's iPhone. I was thinking about making two animations: the first one extend and distort the view and the second one reduce the view!
What do you think? My problem is to distort the view!
Do you have any idea how I could make the whole thing?
There has been a lot of discussion on this see the response from Brad Larson on How can I replicate the trashing animation of Mail.app
Does anyone happen to know the maximum value for someView.bounds.size ? I'm creating a view hierarchy with where the accumulated bounding-box of all child views is equal to the root parent view.
Cheers,
Doug
According to the UIView documentation:
Prior to iPhone OS 3.0, UIView
instances may have a maximum height
and width of 1024 x 1024. In iPhone OS
3.0 and later, views are no longer restricted to this maximum size but
are still limited by the amount of
memory they consume. Therefore, it is
in your best interests to keep view
sizes as small as possible. Regardless
of which version of iPhone OS is
running, you should consider using a
CATiledLayer object if you need to
create views larger than 1024 x 1024
in size.
In actuality, I was able to create UIViews and CALayers that were 2048 x 2048 in size on a standard iPhone / iPhone 3G in 2.x. Anything above that just stopped rendering.
I don't know that there's a specific limit. I have created UIScrollViews that are hundreds of pages in width without any problem. Have you tried it and run into problems?
Paul
I would not think there is a conceivable limit. Since the sizes are stored as floats, my guess would be that it is limited to CGFLOAT_MAX which is so large there is no need to worry about it.