What are my options for viewing hierarchies in iOS? In OSX I have the option of using NSOutlineView. Ideally I should be able to support at least 3 levels.
Not much. Table views support sections and rows, which gives you 2 levels.
You could use a UICollectionView and roll your own hierarchy of data, but I don't think there is an equivalent to NSOutlineView in iOS. The UI Elements are designed for the small screen on a phone, where you don't really have enough space to present multiple levels of data. Apple added a few extra controls like a split view controller for iPad, but not really an outline viewer.
The norm on iOS is to use multiple levels of master/detail views. You drill down from the top level item by item until you get to the detail you're looking for.
Related
I'm trying my first steps in iOS development, and so far my app is going well. However, I've reached the point where simple UITableViews are just not cutting it.
For starters, I have a table view with two sections. I've implemented the method providing each section's title. But when I compare it to, for example, iOS's Settings screen, Apple's style (which I've seen implemented in other apps) looks much better, with better styling in the "section titles" and complex controls in the "table cells":
Now in my app, in some screens I would like to implement something similar to WhatsApp's settings screen. In this case, each "cell" does not have anything very noteworthy layout-wise, but I like the spacing between the different sections:
My last question is: when I am composing a cell, it is very clear to me how to implement a layout, its constraints, etc. Now imagine that I want to show a Table View showing a list of teams, and for each team I want to show the team players underneath, one player by line. It is not yet clear to me how I define layout contraints with an arbitrary number of elements. How would I approach doing this? Grid inside cell?
To sum it all up, my question is: are these screens TableViews with fancy styles and cells and more complex implementations? Or a different View that I am not aware of? Or even an empty canvas that they then compose "by hand"?
For context, I am developing with XCode 9, Swift, on a project with storyboards.
They are custom UITableViewCell cells (like the volume and profile avatar) or standard cell prototypes (WhatsApp settings are UITableViewCellStyleDefault with cell.imageView.image set.
I'm trying to figure out the best way of managing the two list/detail view of the photos app. My main question is, is it two collection views with two separate layouts? Or is it just one that is changing its flow layout? Right now I'm using two in two separate apps, but I'm not sure if it's the best way of doing it.
EDIT: I'm talking about the grid view of photos turning into the detail view of a single photo that is also swipeable (left/right).
Thanks
I'm making a view with a 9 x 9 grid whose cells and layout will never change or scroll. I was thinking of using UICollectionView for this but the more I look into it the more I'm finding that it's geared towards grid views that scroll and may change and reposition. Is this a good assessment? If so, am I better off sticking with my own hand-rolled grid-based view? That would at least enable me to support devices running iOS versions < 6.
I would prefer UICollectionView for grid based structure even its non scrollable. We should try to use native components and then we should customise them on need base.
Its manageable in future if you start supporting scrolling in future.
You can add functionality like cell deletion, cell addition with more precise APIs provided by Apple.
Views will be reusable.
And suppose you want support iOS < 6.0 , you can use "PSTCollectionView" which is open source library. This library checks iOS version and behaves accordingly.
https://github.com/steipete/PSTCollectionView
If the cells do not need to scroll or change, then simply having a view with 9 subviews would be perfectly acceptable. Collection views are great for when the layout changes, such as on device rotation. If you support multiple orientations, this can still be handled without a collection view.
If by static, you mean stationary, yes; and, not only for the reasons provided by the first answer. Here are some additional reasons, which I think are even stronger:
UICollectionView grid layouts accommodate orientation changes well;
UICollectionViewCell allows for better control over cell sizing based on other factors in addition to content size
UICollectionViewDatasourceDelegate simplifies connecting dynamic data to your view, and displaying updates to it
That's just three out of dozens of more reasons; for the rest of them, simply list every advantage the collection view framework provides.
The value of a collection view isn't based on scrolling at all; I say that because scrolling is not a part of the collection view framework. The collection view framework is a UIScrollViewDelegate. It is the UIScrollView class that provides scrolling.
Accordingly, all advantages that collection view provides are yours whether you choose to add scrolling or not.
I need to create an app for ipad.Its something like the contacts app in ipad.(like an open book)
My doubts are whether they are using split view or two different views.
If splitview is used,how could we increase its width and style?
You can tell that they are not using a split view controller by turning the screen vertically: split view moves the master into a popover; contacts simply rotates, without popping the master portion out. I think that they use a single, highly customized, view for the contacts.
The background can be just a chunk of graphic or a picture. On top of that you'd add your own or Apples UI elements.
Each functional area should probably be implemented as a separate subview, ie. the UITableView on the left, the index on the right and so forth.
In your words - implement it as separate views not a split view.
If you want something like that (don't know why you would... the Contacts app is horrible) then you're going to look past the default set of UI elements provided to you by Apple.
UIViewController, UITableView are really the only two things you'd be reusing for something like that.
I am currently working on an iPad application that uses a table view to present data, I was inspired by the iTunes application in iPad that present it's data in multiple columns in a very nice and neat manner, and the most interesting thing is that during the portrait mode the itunes application displays data in 2 columns but when the user switches to landscape mode, it switches the display to 3 columns (since there are plenty of space to display data horizontally).
This is what i'm talking about:
but i found out that iOS SDK only supports single column for tableview (it would be nice to utilize the entire space provided on iPad screen to present data), i did some research and i found out that the best way to present data in multiple columns yet like spreadsheet style is to use datagridview instead, but iOS SDK did not provide any data grid view controls for iOS developers.
I found out over the internet some customized tables like:
AQGridView.
DTGridView.
and also the one from this:
http://usxue.is-programmer.com/posts/14176.html
and the one from this:
http://xebee.xebia.in/2011/04/14/building-editable-gridview-for-iphone-apps/
But sadly none of these ever met the requirements of the application i was working on.
Could you guys provide me some ideas or share some sample codes or links on how to display data in somehow-data grid view, to achieve similar effect used in iTunes application (as shown above).. Any form of help would be pretty much appreciated. Thank you guys!
The summary answer is, place multiple data "views" across in a single cell.
The more detailed answer:
Create custom views that represent the single cells you want. You can for this purpose make them resizable enough to work two across or three across (they will get loaded into 1/2 or 1/3 of the cells bounds).
Then make a custom UITableView cell, that can take two or three data items - load up an instance of the custom view previously created in the cell for each data item you have, placing them next to each other. You can have the cell do the view layout when groups of data items are added.
In the cellForRow code in the table delegate/datasource, you use your data source in groups of two or three (and report the row count accordingly) to pass along to the custom cell.
Sorry I can't share code, but I have used this technique before in other applications.
What's wrong with creating a UIView class to represent a single cell, and another that lays out an array of those cells in a grid? Put your grid view in a UIScrollView and you're about done.
UITableView is obviously a pretty complex class. Much of that is to make it very general, very reusable, and able to support a huge number of rows. Your class doesn't necessarily need to be that complicated -- if you have a fairly small number of cells, your "grid" could really just be a UIView in which you lay out cells in rows and columns. UITableView removes cells that aren't seen in order to save memory; you might need to do something similar if you have hundreds of cells, especially if they're large, but a few dozen probably won't require that.
In short, since you need a grid view for a particular use, you don't need to do all the extra work that would be required for a general, reusable solution.