I have an iPad app which always stays in landscape mode. It is more of a data centered app with 5 columns and couple of hundreds of rows.
In current implementation, I have used UITableView. The rows' height could be anything depending on the data that comes in from server and all the columns can have different size.
The question is, can I use UICollectionView instead of UITableView? Will there be any performance issues? If yes, which is better in grid like layout? I understand UICollectionView is to be used in iOS pictures app like layout but how it behaves for grid like layout?
Thanks,
Pruthvid
What you describe is exactly what UICollectionView is designed for, it's the perfect solution. The limitation is only to the version of iOS you will be able to support (if you need to go back that far).
The choice really comes down to the visuals you want. Of you want each row to have a height defined by the maximum height of any column value in that row and the row appears as a single row item and the last row of the table should be full width then you may prefer to use a table view.
The collection view gives you more options for accessory views (as opposed to just the headers and footers of the table view).
Related
I'm trying to implement the following:
At the top is a segment control that, based on the user's selection (either tapping or scrolling), moves to the relevant CollectionView section.
I've been playing around for a couple of days with CollectionViews and maybe I've just confused myself with LayoutFlows and CompositionalLayouts or is that over complicating it?
I have a diffable datasource that is made up of [Sections, CellItems] but I'm struggling with how to structure it.
What is the recommended programmatic (rather than using interface builder) to do the above? I was just going to originally do 5 horizontal cells, each with a tableView but based on some other comments I've seen from Apple on the Apple forums and the move away from TableView to CollectionView at this year's WWDC, I thought I should be trying to do this properly.
Any direction would be appreciated. All my research seems to point to using orthogonalScrollingBehavior but that layouts out the sections vertically with each section scrolling horizontally.
So my question is should I be trying to do what I'm doing using a CompositionalLayout?
Well first off your segmented control idea makes this sound like you could just use a page control for the horizontal aspect and remove a lot of the collection view complexity. Something to consider anyway.
As for the data source, I think all you need is an array of arrays. Eg. [[CellItems]]. So CellItems[0] would be the first column. Then CellItems[0][0] would be the first cell. CellItems[1][2]... 2nd column 3rd cell. I do apologize as your current solution may be related to diffable datasources and I haven't had time yet to dig into those.
Start with the horizontal axis first and ignore the vertical axis. Get that working as needed. Once you have that up and running... implement another collection view into the first one's cells.
Sorry if I misunderstood the question if it was more about HOW to implement a collection view.
Assuming I'm on a chat scenario, I want user images to move along with scroll until the other user's messages appear. Some visual example:
I'm using a subclass of UICollectionViewFlowLayout to display the messages and provide that initial left offset for the messages (the sectionInset property is not working on iOS 9 for some reason) and I assumed handling a custom supplementary view to do what's shown above should not be that hard, but apparently it is :)
Some info:
I'm not using standard header/footers for flowLayout since it add a space between sections that I don't want
Found this link which is pretty interesting from performance perspective but the example is somehow incomplete (great post though)
I'm trying to avoid shouldInvalidateLayoutForBoundsChange: to return true and recreate attributes every time since chat cells can be complex in terms of size calculation.
I believe this is not a weird scenario, have anyone accomplish something like this successfully? If so, I would appreciate some pointers.
Thank you in advance.
you can use sections for each cell groups. When using sections they have to be a clear background and be customized. So message cells can be scrolled below sections and circle images on section will be on top of its cells.
As a second way, you can use circle images apart from all collection items. For this, you have to create circle images that how many required. While scrolling up/down, they have to be moved as they will be anchored on top of message cells group.
I hope it helps for you :)
I have a UITableView in Xamarin iOS and the requirements are this:
There are always at most 10 items to display in a table. There may be less (like 3), but never more than 10.
The Table should always show all 10 rows, and the height should be such that the table never scrolls (because it's only 10 rows).
What would be a good way to make sure it always shows all 10 (or shrinks in height if it's less like 3). This table shares the page with some other elements, so it's not the only thing on the screen. You can scroll on this page.
Right now it's showing the first 5 in the view, but I have to scroll to view the rest. Would this be a matter of me setting the height in StoryBoard to be rather high? But if I do this, would the table shrink automatically if it had a fixed height?
Any advice/recommendations? Again, remember it will only be 10 records, so not a lot to manage in memory. I want to use a UITableView because of the customizations and repetition of the cells, etc.
Thanks!
I work on a app, nothing fancy, but since is my first app, there alot of stuff I never did before.
So, I'm trying to build a view like the image attached.
I've looked up on the Internet how to do something like that but I don't know what is better/cleaner way to do.
As you can see I have 3 areas: the title, the tableview in the middle and a button on the lower side.
The table will expand based on the content (3 lines or 30 lines) so the button must move down and a scroll bar should appear.
So, my idea:
Using a tableview having 3 static cells: one to put my title, second to put a tableview having prototypes cells, and a third one for the button.
That way I would have a scroll bar when the table in the middle grows, pushing the button.
Here I have a question: how to have the table view (the inner tableview) resize itself, pushing the height of the middle row, instead of having a fixed width with a scroll.
Is the the best way to achieve that?
Thanks for any idea.
C.C.
Are you sure you want to push the bottom UI down as the table grows? You say whether the table has 3 or 30 cells, but what if it has 300 cells? Your user then has to scroll to the bottom to reach the button and tab bar. I think you'll find that it would be better to use Auto Layout and let the table fill the screen space between the title and the button. The table will scroll so if you have 300 cells then you can scroll through inside the table's available area.
The advantage here is you won't be fighting with Auto Layout. If your user rotates an iPhone 4S into landscape you'll only have a few rows displayed but conversely if they run in portrait on an iPad you'll fill all of that space.
As for how to do it, the other advantage is that you don't need the nested table you describe. Use a constraint to attach the title label to the top layout guide, then attach the tab bar to the bottom layout guide. Put a vertical space constraint between the button and the tab bar. Finally, put vertical space constraints between the table and the title & the table and the button. (You'll need to implement constraints for the horizontal axis as well, but that's pretty simple.)
There's are refinements you can put into place if you want the table to shrink to fit if there are only 3 rows, but this should get you started and you may not want that anyway.
Key point: the tableView wants to scroll naturally, inside a view sized to fit the display. Don't change that behavior unless you really have to. Neither your users nor UIKit expects what you're trying to do, and the table is going to fight you all the way about it.
Nesting UIScrollViews (which your nested table would do) works, but it opens up a lot of bad UI flow problems. In my experience every time somebody wants nested scrollViews there's some other approach which is more "natural" to iOS interface paradigms.
If you're dead set on the UI you described I wouldn't use a table for the outer structure. Just make it a UIScrollView and calculate your content size based on the number of rows the table will display. You can actually do that, and then use Auto Layout as I described.
I want to implement something similar to this- (focus on the left portion)
I imagine possible implementations to be
Making a table view with (in this case) 7 'normal' cells, one normal size cell with a custom right accessory item, one 3XL cell containing a button, and finally a normal size cell with an imageview and custom accessory item.
or
Making a scroll view with styled view containing UILabels masquerading as 'cells', a button within a larger UIView, and another faux view-with-label-cell.
Considering the challenges posed by different screen sizes, and the want for easy configuration and modification- which way should mixed sequential data be displayed? Hacky table view, redundant scroll view, or reinvented custom UIView?
Edits
I am currently using a sliding view controller. The sliding functionality is of no worry to me, the contents of the scroll/table view within is.
There are various open source libraries available on net/github. you can use this https://github.com/edgecase/ECSlidingViewController.
Although you can make your own if you want but doing this using scrollview I don't think it will be a good way to do that.
Edit
You basically have to create 8 normal cells and change the color of the cell label which is selected. And create a footer view of YUTableview for last view.
You can use Slide-Out Navigation Panel. Use this slide-out-navigation for better understanding.
I've found more information on this, and I definitely overcomplicated a simple matter.
The answer is yes (use the table view), and there are multiple reasons- the first being the principle of always using the highest level of abstraction where practical.
StaticUITableViewCellsare completely capable of rendering other UI elements (buttons, sliders, etc) inside themselves from stock, and this is encouraged in Apple's UITableView spec. Dynamic cells, stock, are not as flexible but they can be subclassed from UITableViewCell for more custom functionality.
To speak for the example, the first X (in this case, 7) cells are likely dynamic, and the last 3 cells are static. The 'second to last' cell seems to have an infinite(?) height, and the last cell appears to be a sticky tableview footer.