4 ms·
> It can't be that much more work to do the whole interface with UIKit. It really does take that much more time. Just to use a simple example of displaying a
by angrycoder 15y ago
> It can't be that much more work to do the whole interface with UIKit.
It really does take that much more time.
Just to use a simple example of displaying a list of data. An experienced web developer can take a list of data from a database or web service, loop through it, and spit out a decent looking page in 10-15 minutes. Maybe take an 15-30 minutes of tweaking and styling to make it really look professional.
Now, doing the same thing on iOS, you use what is called a UITableView. There is no type of magic data binding included, so you have to wire the whole thing up by hand. A bit more extra work but nothing too terrible so far. Now, tableviews are great if you only need to display text in one of 4 predefined ways, but that usually ends up not being the case. You end up having to make your own UITableCells to get things laid out just the way you want. So you make a cell and start loading it up with different label fields, one for each differently styled piece of text you want, image controls, etc etc. Now, if you are doing this the 'right' way, each of these cells should have their own controller because by now the method that is providing the cells to the UITableView has a ton of logic in it and is acting as the controller for your custom cell. But, you have to maintain this list of controllers seperately inside your UITableViewController, further down the rabbit hole you go.
You think you are all done, but depending on how fancy your cells are and how long your list is, you notice the scrolling is jerky, not smooth, not very 'iPhoneish'. So you read some more and figure out the only way to get really smooth scrolling when dealing with complex cells is to manually draw them yourself and not rely on a collection of controls contained inside the cell. So there you sit, drawing out your individual cells with pen-style graphics methods and blitting text and images like you are a video game developer.
Most of the nice interactions you think of as being native, aren't. They are something that a developer had to do by hand. Even something like not having the keyboard cover up a text field has to be done manually.
I'm not saying it isn't worth the time to do a full native app, but it does require a lot of time, UIKit gives you very little for free.
- reidmain 15y agoYou realize that is just a matter of experience? Using the frameworks I've developed I can have a iOS app hit a web service and display a list of data in 30 minutes max. I could write three paragraphs on all the "complex" stuff I'd have to do using JavaScript and CSS and make it sound a lot worst than UIKit just because I am inexperienced. UIKit gives you so much for free. It is why so many iPhone apps look "iPhoneish" because if you follow the good programming practices you get them for free.
- iandanforth 15y agoI would be interested in a more specific response to the parent. For example, given your expertise, can you diagnose his problem with jerky scrolling and offer a solution?
- adamjernst 15y agoSure, I'll do a deep dive here. Doing high-performance scrolling is a hard problem. You just can't do it in HTML, at all. Native code is not a silver bullet. If you're implementing a table view cell, the newbie approach is to just put subviews on the cell for each slice of content. This performs horribly because the graphics card has to composite all the sublayers while you're scrolling. The faster approach, as he alludes to, is to do everything in one view, using pen operations to move around and blit each section. If you're serious about smooth scrolling, this is what you have to do. Tweetie was famous for its smooth scrolling, for example; it's because Loren Brichter used this approach. Of course, if you're coming from the web/css world, doing everything with pen operations seems incredibly foreign and backwards. But you get good at it quickly. And it's worth it, UX-wise.
- jonknee 15y ago> Doing high-performance scrolling is a hard problem. You just can't do it in HTML, at all. Not necessarily. Especially with Apple adding momentum scrolling to Mobile Safari in iOS 5. I have no problem smoothly scrolling through tables hundreds of rows long.
- beatle 15y agoThis is a very common in iOS. You can preload the array. inside cellForRowAtIndexPath return the array instead of the cell. works perfectly.
- spicyj 15y agoI'm not sure what you could mean -- tableView:cellForRowAtIndexPath: returns a UITableViewCell *. Do you have an article describing what you're talking about?
- adamjernst 15y agoBut of course, doing pen-style operations instead of declarative markup is precisely what gets you the speed and fluidity of a native app. When you open a video with many subtitles in the current iPad app, the UI freezes for a couple seconds. Why is that? Well, WebKit is laying out the DOM for a few thousand <li> tags (the subtitles). That takes a lot of time. I'm the iOS developer of the Khan app; I worked with John Resig who did the JS side. Ultimately we decided poor subtitle performance wasn't a big deal. UIKit could easily add a table class that didn't have such complicated requirements. But then it would be slow, just like WebKit.
- minikomi 15y agoInteresting.. Why not have a single element who's text is updated rather than using multiple elements?