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.
Related
I am developing an iPhone app with skiing destinations being listed in an UITableView. The table view can contain up to 2000 cells. Every cell has a small weather icon of 25x25px (Retina 50x50). I am already using weather icons on the detail view of every destination. These icons are twice the size: 50x50px on the 3GS and 100x100px with Retina display.
As rendering pngs in a UITableView is pretty memory consuming I am not sure if I should use the larger images also for the table view or if I should design images half the size for the table view only. Of course this would increase the download size of the app by about 300 KB.
It would be nice if anybody could give me an advice if it is best to recycle larger images in the app or if it is best to design images for every resolution needed.
Thanks in advance
Martin
You definitely want to use 2 images. If you use 1 image, you are using more memory on non-retina screens, but the same on retina screens. Using 2 images uses the least memory. There should be no problem with memory whatsoever with what you are doing, so I'd venture to say that you are keeping the images in memory after they are needed, which is unrelated to the table view code.
A good thing about UITableView is that it's memory usage is not particularly related to the cell's sizes. The little hoops you have to jump through as the datasource are there so that the table can recycle cells, keeping the memory relatively fixed with respect to memory usage of a given cell.
Recycling cells trades speed for space, so there's a more legitimate concern about scroll performance. This is related to the setup effort per cell (since they are being recycled and re-setup all the time). Image size can be factor here, but I don't think so at the scales you're considering (50^2 or 100^2). This is the kind of thing best investigated by running on real hardware.
On binary size, I think you're correct that a single version of the images would reduce the app download. It's probably not a make or break factor at 300k, but kudos for considering it.
I have a 6000x3000 px image that is in a zoomable view in my xCode project. In the initial view, a button is pressed to access the view with the large, zoomable image. This all works fine, except for the time that is taken to "load" the image often times causes a crash in the app, especially when I am testing on older devices (it seems to work fine most of the time on my 4G itouch). Is there any way to "pre-render" this one large image, or anything else that I can do to prevent crashing?
Do the math: 6000 x 3000 x 3 (red green blue) = 54,000,000 bytes = 51.5MiB of raw data. The normal image handling has a lot of overhead and that simply takes too much memory.
According to this question the solution is to use a CATiledLayer. As far as I have understood it, you need to divide your large image into smaller parts and draw these smaller parts with the help of CATiledLayer.
Edit: Here's a quote from the UIView class reference:
Note: In iOS 2.x, the maximum size of a UIView object is 1024 x 1024 points. In iOS 3.0 and later, views are no longer restricted to this maximum size but are still limited by the amount of memory they consume. It is in your best interests to keep view sizes as small as possible. Regardless of which version of iOS is running, you should consider tiling any content that is significantly larger than the dimensions the screen.
Read: If it's larger, use a CATiledLayer to draw smaller parts.
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!
im searching for a solution of the following problem:
i got a "larger" XHTML string that i want to display in an area that is scrollable.
I already used TTStyledTextLabel for a small text-caption and it works pretty well.
But now i want display it more like a UITextView that scrolls or a UIScrollView with my TTStyled Content in it. i think TTStyledTextLabel isnt the right thing to view such a large (with large i mean about 900px height) content.
i need a TTStyledTextView, or something like that. Does something exist? How to work with it. My Content has a variable length so i cannot setup a UIScrollView with a TTStyledTextLabel in it.
Any hints for me ?
Thanks!
You can determine the height needed to display the whole XHTML string by doing this:
htmlLabel.text = [TTStyledText textFromXHTML:htmlText];
[htmlLabel sizeToFit];
CGFloat height=htmlLabel.height;
I do this to create dynamic table cells that include these labels. You can use this height to set the contentSize of a parent scrollview.
You might however run into problems if your view is higher than 1024pixels on iPhone OS 2.x:
Note: 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.
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.