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.
Related
I am new to iOS/Mac and ObjectiveC development and need a bit of guidance if someone could be so kind, so please excuse my ignorance.
The issue I have is I need to create a Grid view for a TV Guide where you have a vertical list of channel logos on the left that scrolls up and down, and to its right we have a horizontally and vertically scrolling grid. Horizontal scrolling doesnt move the channel logos which is fixed on screen, but vertically scrolling grid also scrolls the logos as you would expect.
Now being new to ObjC and iOS Frameworks, I was wondering which methods I should go down to implement this, Quartz2D perhaps? Or are their alternative simpler methods?
Whatever method is used, it needs to be quick with thousands of 'cells' across up to 600 rows; it also has to be memory efficient with out of view cells being disposed/reused as needed.
I am not necessarily asking for specific code (although that would be nice lol), just some advice on what methods to use so i can concentrate my education on those areas; if that is possible
Thanks.
It seems you do not really need two different scroll views / table views left and right, as the two sides should always scroll with each other.
Thus, just use a UITableView with a custom cell (subclass UITableViewCell) that has the logo on the left, and another scroll view (for horizontal scrolling) on the right.
Read Apple's Table View Programming Guide, and you will be on your way.
How can one enable horizontal and vertical scrolling at same time in a grid view?
If I have a 4x4 grid of thumbnail images, I want to implement swiping in both directions, left/right and top/bottom. Currently I am done with left and right swipe, but if I select the second cell and swipe towards the top, the 2nd row should be scrolled like a Rubik's cube.
Please share if any one have any idea.
It's been quite a while since your question but as I've been struggling with the same thing I'm gonna answer it for future reference...
Sadly I could not find a good solution anywhere so after a lot of hours of experimenting I came up with this: https://github.com/AlvinNutbeij/DWGridController
It's still a work in progress but very usable for your purpose I'd say!
How have you currently implemented what you have? Your mention of 'cell' makes it sound like you are using a UITableView. You won't manage to make one of those scroll in both directions, you'll need to work with a UIScrollView.
I suggest you watch "Designing apps with Scroll Views" from WWDC 2010, then "Advanced Scrollview Techniques" from WWDC 2011. That'll teach you about how you implement tiling and infinite scrolling.
Essentially what you want to do is implement some kind of view recycling yourself, that works like the way UITableView recycles its cells. When things are scrolled off one side of the scroll view, you remove the views for the things that just scrolled off screen and put them in a queue. When things scroll onto the screen, you pull views out of the queue (or create new ones if the queue is empty) and lay those views out in the correct place.
To do the infinite scrolling, you fake it: when your scroll view gets near its edge, you reposition everything inside it, you move the scroll view's content offset to where you've repositioned the views, and then you continue from there: it's all done at once so the user never notices.
The videos will explain these techniques better than I can sum up here: watch those as your first point of call.
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.
This may turn out to be 2 questions in one, but I believe solving the first will go most of the way to solving the second.
First, I have created a view in Interface Builder (I know!) and I load the xib file into my view controller in the app delegate. All of this runs smoothly and as expected.
The view consists of 3 table views, two of a similar size and one small one in a corner.
A cell is added to one table view a pan gesture is added to allow movement around the scene.
However, if a cell is moved from it's table view, it appears to go BEHIND the parent view, as per the screenshot below:
The grey line between the two tables is the gray background of the parent view. If the user still has his/her mitts on the cell, they can drag it into view but how can I make it so that all table views are on the same 'layer'?
I.e. so that dragging a cell from one table view to another with show the cell hovering over both views.
This leads me onto my second question, which I will not ask yet as I believe the solution to this will solve my current issue. but I will explain for further clarity.
In my pan gesture, I use a point inside check to see if the cell is within a table view, currently panning a cell from any table makes it print. It is almost like the views take up the whole screen, even though they are sized not to?
All ideas welcome! Thanks!
This was solved by listening for the cell leaving the bounds of the table view, when this happened, I transferred the cell across the table view that it has been dragged to, adding it to the bottom of the list.
Not the most elegant solution and you do lose the touch but it does work,
I have a page enabled scrollview on an iPad. On the first page, I have a child scrollview that scrolls horizontally through image buttons. The buttons scroll the outer scroll view to the correct page. Its basically like a table of contents that jumps to the correct page.
My end goal is to be able to categorize the buttons seen in the child scroll view. So there would be a segmented control that changes what buttons you can see. So maybe one category would be ALL, and another category would be A-M, and another would be N-Z for example.
My question is, should I use a uiscrollview or a uitableview?
Right now I use a scrollview and it is really easy to get the buttons in. I could implement the different categories kind of gimmicky by having all of the buttons in the scrollview and then just showing or hiding the buttons accordingly. I feel that it'd be bad memory usage though.
For a uiscrollview i was looking at using EasyTableView, butI'm not 100% sure if this is compatible with what i want to do or if it'd even be better.
Any ideas for what the best way to implement this is? Specifically, I'm not sure of the best way to change the buttons when I change categories.
Thanks!
Use a tableview when you are dealing with data that is best expressed as sections and rows.
I think for your situation I'd have a UIView subclass that can display the images you need for a given category. Stick that on the outer scrollview as needed. You can keep memory low by only keeping the currently visible view and the ones on either side on the scrollview. When you scroll to a new location you can recreate the view needed for that page, and the ones surrounding it. Then you release the ones that are far away and let the system reclaim their memory if needed.