UITableView: table view scrolling makes images disappear - iphone

I am working with one iOS application it has two tables placed side by side, each table view holds images. Both table views having the auto scrolling and manual scrolling functionality. By default both tableviews in auto scrolling mode, but the problem is when user did manual scrolling images in table view become disappear (loading images very lately) and its happening when table view state is moving from auto scrolling to manual scrolling and manual scrolling to auto scrolling. currently I am using static images only (not dynamic and not from server). In future i have to use with dynamic data(images) coming from server.
Any ideas to fix this issue that will be very helpful to me.

Check the size of your UITableViewCells and all their subviews. Sometimes (at least for me) the sizes will be at 0 and then when that frame (which is 0 points high) goes off the screen, the image will disappear.

Related

How to lay out scrollable iPhone view

I need advice on the most pragmatic way to layout the following view. As you can see from the image attached, I have a static logo and text that appears at the top of the view, followed by a variable number of items.
Initially, I was going to use a TableView for the variable number of items, that way I would be able to load any given number of cells at runtime.
My problem is that if I drop a tableView onto this view below my static logo and text, when the user scrolls, the static logo and text will remain fixed. I need both the static logo/text AND the tableView to scroll up.
My next inclination is to use a scrollView, inside which I would place my tableView and static logo.
Is this the most pragmatic way to approach the problem? If so, will there be usability issues when scrolling the scrollView vs scrolling the tableView? In my mind this could get messy.
Any advice on the best way to approach this is greatly appreciated.
Using a table view inside of a scroll view is a bad idea and warned against by Apple in their docs. Basically the internal gesture recognizers can conflict and create a clunky user experience. The best path forward would be to go with the tableview (which is a subclass of scroll view) and have two different kinds of cells– one for the logo and one for the repeating contents at the bottom. Make the first cell the logo and adjust the table view's settings to format it to your heart's content.

Pinterest Gridview implementation on iOS

I want to implement a grid view like the one in Pinterest
I thought about implementing as 3 table views. But I was not able to scroll them together well. When I implemented the scrollViewDidScroll and set the contentOffset for the table views other the scrollView , the scrolling became slow and unusable.
Another implementation I did was of was having a set of images to load and calling the viewDraw function in scrollViewDidScroll. The ViewDraw function just draws the necessary images and removes the rest of the images from the memory which were already drawn but wont be visible .
this too makes the ScrollView scrolling slow. And another issue with it is that there are white(background color) patches before the images are drawn.
What should be the best way to implement this grid view ?
Solution 1 (i don't know if this works and I don't like it very much)
How about having 3 vertical table views side by side, but forward any touch events from any tableview to the other ones. I understand that you had performance problems when trying to sync the tableviews, but maybe working on an event level things would work better. Maybe.
Solution 2
Use a UIScrollView (for the scrolling purposes of course). For performance and memory reasons you also need to implement a load-on-demand mechanism so that you don't load all your images at once.
To do this I would create a class, CustomImageStrip that handles a vertical image list. This class works together with the scrollview and uses contentOffset to decide when it is time to load/unload a image from the strip.
By having 3 independent image strip classes, the images can be of any size and don't need to be aligned. But, since they all belong to the same UIScrollView the scrolling will be done simultaneously.

How can we horizontally scroll tableview in iPhone SDK?

I want to scrolltableview horizontally as well as vertically. How can I do it?
I'd suggest making a UIScrollView the same size as the screen and then making your UITableView bigger than the screen.Drop the TableView into the ScrollView. Set up the scrollview with a high contenSize.width and then tweak it to work as you desire.
The idea with embedding UITableView into UIScrollView seems to be great, however there is a serious gotcha. UITableView is optimized to display only visible viewpoirt area and limiting allocated UITableView cells. In the case it is embedded into UIScrollView, it allocates complete content area of scroll view, i.e. all rows for the UITableView. It goes out of the memory for approximatelly 2000 rows. Since the UITableView.reloadData creates callback in main thread, it blocks main thread to respond to didReceiveMemoryWarning and application is killed on system sole discretion for level 2 warning, which is never received.
It seems that the better way is in subclassing UITableView and extending rows to width which can be scrolled horizontally.
If you are looking for something similar to what is done in 'Pulse', then this tutorial might help you:
http://iosstuff.wordpress.com/2011/06/29/creating-pulse-style-scrolling-horizontally-scrolling-uitableview-as-a-subview-of-uitableviewcell/
It shows how to add a horizontally scrolling UITableView to a vertically scrolling UITableView

Looking for a UI library to present Data horizontaly in iOS

Does anyone know of a UI Library for iOS, that acts like a horizontal UITabelView?
I want to scroll cells from right to left and not from up to down.
I had a similar requirement: Horizontally scrolling tables in cells of a normal, vertically scrolling table.
My solution: I put a standard UIiew in the outer table's cell. This view had its transform property set to turn by 90°, serving as a "hinge", turning its contents to the side.
In the hinge view was another UITableView. Since it is contained in the turned view, it appears horizontally on the screen. The cells of this inner table contained another hinge view, turning their contents -90°, back to the upright orientation.
This might sound a little confusing, but it gives you all advantages of table views, in horizontal orientation. It's less confusing if you leave out the outer table view with their cells which are not needed in your case.
Edit: to answer comment
Performance was definitely great. Actually, performance was the major reason to switch to this approach. Table views are especially great for displaying huge data sets, since they only instantiate visible views (cells) and reuse them after being scrolled out. By itself a table view is quite light weight and very optimized for its purpose. My data sets where middle size, I'd say (about 100 items in both dimensions) and scrolling was perfectly smooth.
The other thing besides performance I was concerned about was touch handling. It went out that the table views (which derive from scroll views) always detected the gesture correctly (scrolling a scroll view in a scroll view is not easy to get right). If you swiped vertically the outer table view would handle the events, if you swiped horizontally the inner table gets all the events. I was quite impressed of how well the framework handled this non standard situation.

UIScrollView vs. UITableView

For a vertical scroller are there any advantages to using UIScrollView over UITableView?
I ask because I am currently using two vertical UIScrollViews with UIImageViews inside of them and am having memory issues and poor scrolling performance. I am not doing much with the scrollers, only highlighting images as they scroll into the center of the scrollviews and adding a delete button above an image if the user wants to remove it. I've started to look at lazy image loading/reuse and it seems that most of these issues have already been resolved in the UITableView class, so I'm wondering if there's any reason to stick with UIScrollView?
You should be able to use a UIScrolLView with no problem if you just, like you said, lazy load the controllers, when scrolling (assuming your views are full size) you dont need to have more than 3 views loaded at any one time, all you need is the current view, the view that goes behind it and infront of it, as you scroll your view you can unload and load the appropriate views. You should look into Page Control sample application, it does exactly this and you can pretty much get all the lazy loading code from there. Link is here https://developer.apple.com/iphone/library/samplecode/PageControl/index.html