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.
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 am kind off struck in implementation of indexed UITableView. The content display size of tableview in my application is of dimensions 320X250. I am successfully able to display the indexes in tableview as display area is small so half of indexes are displayed by default as "dot symbol".
Any suggestion regarding this would be really helpful.
Cheers!!!
For that,
You have to take UILabel inside the "cellForRowAtIndexPath" method.
And assign the label x, y position and width & height.
So, it will be display properly.
Let me know if you want source code for that.
That is the default behavior of iOS. It automatically truncates the indexes when they are too many to display.
I get a page full of info from the server VIA JSON. There is a lot of info and different parts to the info, images, text, graphs etc. So i display it inside a UIScrollView so the whole page can scroll. I get some HTMl which i want to display inside a UIWebView. I have the HTML before i create the UIWebView so i can change the height of the UIWebView to contain all the text without the UIWebView itself needing to scroll. But it can vary in length each time i get a new load of data back from the server so i cant hardcore the height it needs to be.
So my question is. Given you have an NSString holding the HTML. Is there a way to calculate how high the UIWebViews frame needs to be, to contain all the HTML without having to scroll.
Hope you understand my question it is kinda long :)
Thanks,
-Code
If it's ok to resize the webview (and the parent scroll view's contentSize property) after the HTML finishes loading, you can use JavaScript to query the rendered height of the HTML and use that. See iPad - find the true height of a UIWebView
Well that would depand on the size of the text in the UIWebView. One way I can think of is to try finding out how many characters (letters) you need to fill one line in your UIWebView. Then use that number to devide your total number of characters in the NSString containing the HTML and base on that number lets call it lanes you could increase the hight of your UIWebView
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.
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.