Is the iOS 7 Apple Mail app is using a UITableview for the composing and viewing message screens? If so, why?
The composition screen appears to be using a UITableView with a UITextfield for the subject row and a UITextView for the message row. What is the benefit? There aren't any table rows similar enough to be reused (Max is 6 if you include cc and bcc), so I don't see a performance benefit. There is no Edit mode (i.e. move, delete rows) on these two screens. The resizing table rows necessary to accommodate long messages seems like an unnecessary headache.
I'm working on an app with a similar text input layout and number of fields. I initially planned to use a UIViewController with UITextField and UITextView placed on a UIScrollView. Examining the Mail app, I'm assuming there's a reason Apple would use a UITableView. Though I don't see what it is.
Insight appreciated.
Table views are REALLY good at a few things, and one of those things is creating forms. All you really need to do is add the fields to the cells and do a little cell customization, and the table view handles all the spacing, formatting, rotation, scrolling, etc.
I built an open source iOS form building library that is build on top of UITableView for just these reasons. (https://github.com/mamaral/MAFormViewController) In my case, if you need to move around or add a new field to the form, it's as simple as updating the data source with a new form-field cell, as opposed to creating a totally new textField, configuring it, determining the frame, moving everything above and below it around accordingly, etc. I would suspect these reasons are similar to why Apple would use table views for forms like the above.
The class chain is:
NSObject - everything subclasses this. you have to be really crazy to not subclass it
UIResponder - anything that responds to user input should be a subclass of this. the message view responds to user input
UIView - anything that draws to the screen should subclass this. the message view draws to the screen
UIScrollView - anything that scrolls should subclass this (note: that's not how it works on OS X! Only on iOS!). The message view scrolls, so it needs to subclass UIScrollView
UITableView - anything that has rows of data should subclass this. The message view has four rows, so it should subclass it.
Basically, it subclasses UITableView because it needs all of UITableView's functionality. So why not subclass it? You are saving yourself thousands of lines of code by doing so.
Duplicating all of UITableView's functionality is very difficult.
Chances are if you write an app without subclassing UITableView, it will be so sucky Apple might even reject it from the store, telling you to go back and make it work properly. Which would mean subclassing UITableView or else writing thousands of lines of code — for example Voice Over is a huge pain in the ass if you don't subclass UITableView.
If you don't want to restrict yourself to rows of data, consider using a Collection View.
Related
I'm new to IOS development, I have a few questions.
1) What's the purpose of property rowheight on table view cell, I mean it does nothing even if I change its value, it always takes the value from its parent view i.e a tableview property rowheight? It visually changes in the IB but nothing happens when I run the app.
2) What's the purpose of Content View why is it even there? Let's say If I have to make some image equal to the height of the cell it restricts me. Or is there any way a content view can be changed to be equal to the cell height & width? I have to put constraints on the image in relation with the cell which is not the immediate parent of the image and I don't know if this is the correct way to do it.
3)How does Xcode Autocomplete works? like if I want to write a function tableview(_:tableview didselectrowwithindex:IndexPath) and I type tableview it shows a list, what to do next? I mean I can't type the whole fucntion with params or find the func in the huge list.
The height of the cell set at the IB is primarily used for simulation, the views described at IB are normally resized when actually used. E.g. you can set rows height to be 100 for the table view, 30 for some of the cells and keep the whole controller simulating a nice screen of iPhone 6. The same view will be used for all devices and will be scaled accordingly as well as the cells with the help of your delegate.
The content view is there for the reasons directly related to your additional requests. It holds all the content while there other views that accompany your content and are part of the cell like separators, accessory views, slide action views. Without a content view the responsibility of managing all the additional parts would most likely fall on you as a developer and while you might think that that is fine at the simple layouts, a simple enhancement to it would make a huge impact.
Fuzzy autocompletion at Xcode seems to be something Apple is working on now. If you can't wait and find it too difficult to navigate through the list, there are Xcode plugins available that provide fuzzy autocompletion.
Answering the question in the topic:
example: tableview(_:tableview didselectrowwithindex:IndexPath)
if you write tableview it will show all the symbols that start with tableview. For functions, it will show all the functions sorted by the second parameter name (didSelectRowWithIndex).
[EDIT]
it will autocomplete as far as the answer is unique and then show you a list full of options. I don't know any tricks to skip looking through the massive list. But after a while you'll know what you're looking for and it gets faster.
[\EDIT]
when you press tab, it
by the way: the delegate functions names start with the name of the object they're related to.
So UITableViewDelegate functions start with tableview.
as for your first two questions there are tons of answers for those questions on SO. This one seems closely related to yours.
I'd like to implement a feed in iOS 7 that is only pulling new data if it appears the user has a chance of viewing it. I know UITableView is a subclass of UIScrollView that does this well, but I can't get the cells to behave the way I'd like - I'd like it to look similar to facebook or twitter's newsfeed where you can reload by pulling down and load more by hitting the bottom.
I've seen other questions such as this but I'm looking for vertical scrolling only, with absolutely no horizontal movement. I'd like to use a method calling (for example) nextTenPostsFromIndex: that instantiates from zero, and applies to whatever index was the last on the screen if hitting the bottom.
My question: Is the best way to go about this to create a UIScrollView, place a subview inside of it, and programmatically space them on the available scrollview space, and apply the same drawing methods again with repopulated data if nextTenPostsFromIndex is called or checkForNewPosts (if pulling down from the top)? Would this be a reasonable way to implement Facebook's iOS7 newsfeed, or others like it?
Short answer: No. You really ought to use UITableView for things like this. You can use a custom cell or whatever you want. If it helps you, also know that since UITableView is a subclass of UIScrollView, you can do anything you would normally do with a scrollview, including assigning a delegate which acts based on the current position when scrolling.
I would like to know how to handle, for my iOS app, the following situation:
I have to deal with something like this (basicly this is an article with comments, received from a server):
=- Text and Images -=
=- UIWebView -=
=- List of Comments -=
Now, I came up with two solutions:
Have the content above the list of comments wrapped in a UIScrollView, and create Views for each and everyone of the comments (don't know many of them could be), and
Make the list of comments a UITableView, and the above content its Header.
Which of these (or possibly another if you have any recommandations) should I choose? It may look not very important, but I would like to know this, so I could use the idea in further developing.
I would use a UITableView with a custom UITableViewCell wich holds the comments.
It will definitely have a better performance the UITableView than the UIScrollView since the UITableView re-uses the cells.
Using a UITableView you will just have to worry about customising the cells for the comments.
Otherwise if you want to use the UIScrollView in case you have a lot of comments you will have to create manually a way to reuse them which is what the UITableView does.
If you want something like facebook, so that the context + comments both are movable,then go with option 2.
But, if you want content always at the top, go with option 1.
Indeed, UITableView is a subclass of UIScrollView.
And If you think you might have many comments like (50+),
If you use scrollView, then you should have to supply scrollView with those number of UIView objects.
But, if you use tableView, it perfectly reused already created views.So evenhough you have 1000+ comments, it just uses 5 UIView objects
I am trying to build a custom UIPickerView replacement class mainly for learning purposes but with a view to implementing this within an application I am developing. I have put a lot of time and effort into the UI of my application and now the default UIPickerView just doesn't fit right.
I saw this Dribble mock up of a really slick looking date/time picker but realise that theres not a chance in hell that UIPickerView can be customised this heavily without some major hacking.
After a whole lot of reading and investigation, I have found that UIPickerView uses UITableViews for it's components rather than a plain UIScrollView as I had first assumed. This is confusing for two reasons:
Customising UITableViewCells is a major pain in the derriere. It's not that it's hard work, just laborious and rarely yields the required result. Somehow UIPickerView manages to pull this off though with very little overhead. I would assume that each row in a component just uses UITableViewCellStyleDefault with a custom view for it's contentView but you know what they say about assumptions.
The second thing that is throwing me off is that UIPickerView conforms to the UITableViewDataSource protocol, but not the UITableViewDelegate protocol. This seems a little odd as the delegate is responsible for providing the correct height via – tableView:heightForRowAtIndexPath: UIPickerView however does allow you to set the size of a component via – pickerView:rowHeightForComponent:
In line with this, it also seems a strange choice to utilise a table view as natively these do not "snap" to a specified row the way a scroll view would with pagingEnabled.
Can anyone offer up an explanation of why the default UIPickerView doesn't conform to the aforementioned delegate? Would it be easier for me to implement my custom picker with a UIScrollView instead or should the UITableView provide the functionality required?
UIPickerView actually conforms to UITableViewDelegate protocol but just does not expose that in public headers. You can check that yourself using class_copyProtocolList function.
Using UITableView internally makes it much easier to implement pickers with large amount of rows as UITableView provides great support for reusing cells, otherwise Apple would need to reimplement that logic once again for picker - that would not make much sense (sorry I don't see any big problems in customizing UITableViewCell for this case, so it is hard to comment on that)
As UITableView is UIScrollView subclass you can make it "snap" to a specific position, check scrollViewWillEndDragging:withVelocity:targetContentOffset: method in UIScrollViewDelegate protocol that can be used for exactly that purpose.
Custom UIPickerView are done by mimicking it's behavior using an UIViewController subclass containing as many UITableView you need for fields.
Eg: if you want a time picker, use 2 tableviews
You should style them in a xib using images and such.
What's -kinda- hard about reproducing the behavior is the part where UIPickerView "snaps" to the closest cell, and especially getting it right.
Also, cells in a UIPickerView are simple, just no borders/delimiters between cells, text label is centered, and voilà. What you see are just images overlaid in front of the UITableViews.
As to why it doesn't fully conform to the UITableViewDelegate, it's because in fact, it's a lightweight UITableView that snaps automatically that is used internally in UIPickerView. Thus, it lacks some delegates that are not specially useful for this.
But I guess we all agree on one thing: Indeed, building custom UIPickerView is a big pain and should be easier.
Take a look at this component, looks quite nice, though I haven't tested it myself. computerlogicx/AFPickerView
I managed to implement an "alternative" UIPicker by extending UICollectionView.
Although UICollectionView is usually used for cases where you have multiple items in a section, you can just have one item and it works fine. If you enable paging you get similar behaviour to a UIPicker, but it has a "stickier" scroll that only lets you scroll one item at a time, which might be better if that is what you want. Furthermore, you can scroll vertically or horizontally. You could even have a 2D picker with some extra code.
Ok, so I have a normal viewController that has a UIScrollView in it that gives details about distilleries. What I wanted to do was have a list of spirits that are distilled at the distillery that they are reading about. So I attempted to implement a UITableView inside of my UIScrollView, and after hooking everything up and writing all the delegate and datasource methods I come to find out that a UITableView will not work inside of a UIScrollView. So does anybody have any ideas as to what kind of User Interface Object I can use to accomplish something like a UITableView's dynamic characteristics? I don't want to use a UITextView because it just looks cheap and unstructured. I need something that can dynamically change the number of items shown because not all distilleries will have the same amount of spirits distilled there.
If you are implementing a UITableView, there is no need to create a UIScrollView.
As a UITableView will automatically increase its size and behave like a scrollable view whenever the content size is larger than the screen.