For an iPhone app, I'm going to need to display read-only tabular data in a grid format. This data could potentially have many rows and columns.
I could use UITableView, but the problem is the data will most likely be very wide and require scrolling.
Is there a way to put a UITableView in a UIScrollView and allow zooming and scolling x and y, but still take advantage of reusable UITableView cells? I assume putting a huge UITableView in a UIScrollView would not take advantage of the cell reuse (virtualization).
Or am I better off using UIWebView and a HTML table?
A webView with HTML tables would likely use more memory, but end up being a lot easier to code and debug than 2D cells inside a tableView inside a scrollView.
Another option for a really large table might be a tiled scrollView where you only render the visible tiles (and release and/or reuse the offscreen tiles).
If you're still looking for a native solution, you might consider this iOS data grid - even though it's not free, it's quite full featured.
Related
I have several local html files and I want to show them in a table with static(for now) cells.
Each UIWebView would have a different height (I dont want to have any scrolls in the UIWebView) so obviously each cell has a different height. Most of the comments i read discourage the usage of UIWebView in table cells. What do you think : is this applicable ? will it be slow and need time to load?
UIWebview in tableview cells will affect the performance for sure. To display Html content in tableview cells you can use NSAttributedString.
I used a UIWebView in an app to display content coming from the web as rows in a table view.
I know that doing that is discouraged, due to the high memory use of UIWebView, but in my case it was not only a matter of displaying rich text: I had to display HTML loaded from the web, so I give that option a try. In short, I tried it and it worked fine.
The app got memory warnings from time to time, but it was also able to recover memory effectively and run unaffected even on an ipod touch (just 256MB of memory). Performance was possibly affected, but due to the fact that the app was doing just that (loading text from the web and displaying it in the table), the app was perfectly responsive.
One important notice: pages were pretty simple, just text, and each table did not contain more than 15 elements. Furthermore, one thing you have to consider is that the UIWebView introduces a small delay in the rendering, so you will have to deal with it and accept it in your app (there is no way to get rid of it that I know of).
In a later project, I used a different approach: using just one UIWebView and creating the table using HTML/js inside of it. Well, it also worked, but I could not see any big improvement as to peak memory usage nor performance (I checked with instruments).
This is just my experience, I am not trying to say that this will work or that is good practice to do. In any case, I hope it helps.
I currently made an app which contains a tableview with 1000 cells. Each cell contains on the left side a UIImageview in the contentview. All the image files are currently stored in the NSBundle. Unfortunately the app is to big in size to download over 3g (one of the regelations from Apple) and I will need to cache these images.
I currently am downloading and saving each image once the cell is on the view (dereusable cell) but this slows down the scrolling drastically. Is their a way to keep the scrolling fast but once the user stops at a certain position it caches those files? I tried an NSOperationQueue but this did'nt work out for me.
Some hints in the right direction would be appreciated!
Thanks!
Well if you are the same downloading and displaying a table view, it's normal that you have a performance drop in the fps you get from your tableview as the cpu is using some of it's threads to download the data...
The only way you could gain in performance is if you speed up the drawing of your tableview cells by using core graphics to draw directly into the cell (as Loren Brichter demonstrated with the tweetie app).
I have a scrolling grid of photos that looks and functions pretty much exactly like the photo picker on the iPhone. It is constructed from a UITableView that uses a custom UITableViewCell which displays a row of photos (very similar to how Three20 implements it).
It works great except that scrolling performance is poor. I'm already following most of the best practices for fast UITableView scrolling (à la Tweetie).
The images are all bundled with the app. I load them on the UI thread, on demand. I use UIImage's imageNamed: so that the images will be cached after they're first loaded. Once I've scrolled through the table view once, it scrolls very smoothly.
The problem is, the first time scrolling through the table view, scrolling is jittery. I've profiled the app and found that the majority of the time is spent loading the images from the file system. They are JPEG images, already sized correctly (small). I tried using PNG images instead, but performance doesn't improve very much.
The iPhone photo picker exhibits much better loading performance. I'm wondering if combining all the photos into a single image, which I load once and then split into smaller images would be faster. It certainly works in games, but I know that's really a totally different story. Has anyone had experience doing that?
Any other ideas for how I can improve performance?
Incidentally, I'm having a similar, albeit less, performance problem for another UITableView that just uses standard UITableViewCells with one image assigned to the imageView per row.
One thing to try could be pre-caching all the images when the view loads. Beyond that, perhaps loading the images in the background (even though it's loading from the filesystem and not the web). I haven't tried this myself, but perhaps you could use something like https://github.com/rs/SDWebImage and have the URLs point to the filesystem. Users might see some placeholder images at first, but then the UI wouldn't stutter while images are loading.
Setting the PagingEnabled property to off improves the scrolling performance.
I had a similar issue using a UITableView to display information parsed from an RSS Feed. I ran into scrolling performance issues when there was a significant amount of data. Though I'm still working on it I suspend the parsing when the table is being scrolled. It resumes when scrolling stops. I am not at my computer, but I believe I used tableViewDidScroll and tableViewDidEndDecelerating. You can check these tableview delegates. In any case it works very well, I just need a more elegant way to pause my parsing.
Fantastic. That does work like a charm! So efficiently I ended up using insertRowAtIndexPath rather that reloading the table. Now it behaves the way it
Thanks so much!
Joe
I know this is kind of a vague question, but does anyone know how to get rid of choppy scrolling on a tableview?
Thanks
I suggest reading up on the subject but a few main things are:
Don't do heavy calculations in your GetCell function (it is calculated several times per second as each row appears.
Make sure as many elements in the cell are "opaque" as possible. Read about red/green transparency checking with instruments / simulator. Transparent areas require compositing which causes a performance hit with the hardware (especially on iPhone/3G).
Make sure you are using a constant cell identifier so dequeueReusableCellWithIdentifier isn't creating a new cell every time one is needed.
Have you tried Apple's suggestions for Cells and Table-View Performance yet?
You might also want to look at the TableViewSuite sample code for different techniques for creating fast scrolling table views.
Try Atebit's fast scrolling table cells:
http://news.atebits.com/post/197580827/fast-scrolling-in-tweetie-with-uitableview
The idea is that instead of a deep hierarchy of subviews you draw everything flat to the content view so that rendering doesn't have to composite lots of transparency.
Another possible problem may be background web calls - if you are using asynchronous calls to servers, try moving them into background threads. That can really improve UI performance.
In reference to my previous question, I would like to know how to implement a large grid of cells in an iPhone application.
I'm working on an interface which would be similar to an Excel spreadsheet, with many rows and columns. Do I have to handle each cell separately? How can I handle user interaction in each cell?
Is there a standard way to create this type of control?
There is no real standard mechanism.
If all of the cells in a given row will always fit in the width of the screen, one way to do it would be to create a UITableViewCell with several UILabels and vertical separators between them. If all of these rows had "columns" of the same width, you would get the appearance of a grid.
If that isn't possible, it might be helpful to think about what the table view control truly is. A table view is just a scroll view that automatically adds, removes, and recycles its subviews so that only the ones that are visible at a given time are in memory. There is no reason you could not write a GridView control that did the same thing, but in two dimensions. It wouldn't be as easy as using the built-in table view, of course, but if the table view can't do what you need, well, that's why Apple isn't writing all the apps.
Sounds like the exact thing that UICollectionView was made for!
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UICollectionView_class/Reference/Reference.html
Look at my answer to this question: MS Excel type spreadsheet creation using objective-c for iOS app.
Basically there's no standard way to do this. You will need to made everything by hand and there's 3 ways to go:
Use a UIWebView and layout everything using html/js.
Modify a UICollectionView.
Make everything by hand using Core Data.