Creating an iPhone App From Scratch (sans Xcode/IB)(lambdadevp.blogspot.com)
lambdadevp.blogspot.com
Creating an iPhone App From Scratch (sans Xcode/IB)
http://lambdadevp.blogspot.com/2010/11/creating-iphone-app-from-scratch.html
24 comments
I'm confused by your comments.
Interface Builder is pretty much a must-have for serious iOS developers. Of course, you may have your neckbeards that like coding XIB files by hand in vim, but they are the exception.
I can see XCode being optional, though.
Edit: I didn't downvote you. I'm curious about your stance.
Interface Builder is pretty much a must-have for serious iOS developers. Of course, you may have your neckbeards that like coding XIB files by hand in vim, but they are the exception.
I can see XCode being optional, though.
Edit: I didn't downvote you. I'm curious about your stance.
I don't hand-code XIB files: I don't use XIB files. I do use Interface Builder for laying out a basic UI design, it's much better than sketching it by hand.
But when it comes to code, it's much easier to have everything in once place. Override -loadView on your UIViewController subclass, and create the views right there. Sure, grab the frame dimensions from IB, but when you create it in code you have full control of how it works. There's no magical linking of the right nib to the right view controller. There's no "outlets" that work most of the time -- except, and I've had issues with this, in a few methods where they don't. There's no almost-but-not-fully-correct parsing of your source code looking for the "IBOutlet" markers, and there's no custom UIView subclasses that you have to make in code anyway, because IB doesn't support configuring them.
Basically, similar to this line from the Zen of Python: "Explicit is better than implicit."
But when it comes to code, it's much easier to have everything in once place. Override -loadView on your UIViewController subclass, and create the views right there. Sure, grab the frame dimensions from IB, but when you create it in code you have full control of how it works. There's no magical linking of the right nib to the right view controller. There's no "outlets" that work most of the time -- except, and I've had issues with this, in a few methods where they don't. There's no almost-but-not-fully-correct parsing of your source code looking for the "IBOutlet" markers, and there's no custom UIView subclasses that you have to make in code anyway, because IB doesn't support configuring them.
Basically, similar to this line from the Zen of Python: "Explicit is better than implicit."
This is great info. I was pretty ignorant about this facet. Thanks for the response. Thanks to the other people responding to the OP's comment, too. This is what I love about HN.
Interface Builder is definitely not a must have. In many cases, it just gets in the way. You can easily override loadView and create your views by hand. In fact, for most of the good stuff, you have to do this.
> In fact, for most of the good stuff, you have to do this.
IB's biggest benefit is we can have our artists skin apps and check in the XIB - no programmer needed. This is very important once you start creating platform type apps. Skinning can be a very time consuming process; IB makes it more manageable.
To clarify what milkshakes is saying, IB stops being useful when you are doing custom animations (e.g. moving subviews around - something that is very common if you have a custom animation). Usually, IB will beat a developer coding CGRect type code from scratch (unless they are using Opacity - a great tool that generates code and is very programmer friendly). A custom UIView will probably win the performance race but lose in the productivity/maintenance marathon.
Once you start getting into custom rounded table cells, custom table headers that act as row 0 of the table cell, empty placeholder cells, CoreData, and table/cell animations - you are entering the dark side...
Using IB for UITableViewCells doesn't have a significant performance penalty now because if you are doing custom cells - the client is probably willing to sacrifice 60fps scrolling - to get their custom table gradients/cell backgrounds (otherwise the cells would be opaque).
IB's biggest benefit is we can have our artists skin apps and check in the XIB - no programmer needed. This is very important once you start creating platform type apps. Skinning can be a very time consuming process; IB makes it more manageable.
To clarify what milkshakes is saying, IB stops being useful when you are doing custom animations (e.g. moving subviews around - something that is very common if you have a custom animation). Usually, IB will beat a developer coding CGRect type code from scratch (unless they are using Opacity - a great tool that generates code and is very programmer friendly). A custom UIView will probably win the performance race but lose in the productivity/maintenance marathon.
Once you start getting into custom rounded table cells, custom table headers that act as row 0 of the table cell, empty placeholder cells, CoreData, and table/cell animations - you are entering the dark side...
Using IB for UITableViewCells doesn't have a significant performance penalty now because if you are doing custom cells - the client is probably willing to sacrifice 60fps scrolling - to get their custom table gradients/cell backgrounds (otherwise the cells would be opaque).
I find that I used to do most of my work without nibs and do it in loadView. In recent releases I've been using xibs for a lot of the base layout and doing the rest in viewDidLoad. 99% of the time you can create most of your interface in IB and save yourself a bunch of time and make it more maintainable.
In all honesty, the only reason why I don't use IB is because I'm too lazy to learn how the advanced functionality and customization actually work. Besides that, I always end up wasting too much time trying to figure out why the app won't build because I forgot to ctrl+drag an outlet to the File Owner or something silly. I'm insanely faster at building the UI when I code by hand so I choose that over IB.
It's essential when working with artists and UI designers. I'd rather have the coders coding and the UI guys laying out / lining up the UI.
As a UI designer, there are few things more soul-destroying than having to ask a coder every time you wanted to move something by a pixel or replaced with something that (to them) looks identical.
My gripe with IB is that it is beginning to look long-in-the-tooth: it lacks many of the modern layout tools you might expect: zoom, show/hide layers, lock, align-just-these-together. IB could do with taking features from a vector art package (without becoming too-much like Expression Blend).
My gripe with IB is that it is beginning to look long-in-the-tooth: it lacks many of the modern layout tools you might expect: zoom, show/hide layers, lock, align-just-these-together. IB could do with taking features from a vector art package (without becoming too-much like Expression Blend).
We use IB for most things and actual code for very specific things. Make things much easier when you are dealing with localization when you have to adjust text elements due to translation. "The best code you can write is the code you don't write" or something like that
The Phases of Interface Builder:
newbie: Whoa! I can build a UI without writing any code? Cool!
novice: Damnit, why isn't this working right? IB Sucks. It must be IB's fault!
junior: Ah, to hell with it, I know enough code, I can just write all my views in code. TOTAL Powah is MINE!!!
journeyman: Locilawhat? Whoization? Whatever, I am tired of having to recompile and constantly change dozens of off-by-a-pixel issues in code. Maybe Interface Builder can be used, but I'll keep it on a short leash.
enlightenment: Interface Builder vs. code? You kids, you gotta, like, embrace the duality of the universe, man... everything in balance... feel it until you don't know where interface builder ends and code begins.... and anyway, its code all the way down, man! Have you got a light?
More seriously, there's a period where you feel like you're fighting interface builder all the time... and once you get past that, you use it where it makes sense and code where code makes sense. The app I'm working on today, the UI is done completely in interface builder, and it has saved a whole lot of time, though animations and stuff like that are done in code, of course.
newbie: Whoa! I can build a UI without writing any code? Cool!
novice: Damnit, why isn't this working right? IB Sucks. It must be IB's fault!
junior: Ah, to hell with it, I know enough code, I can just write all my views in code. TOTAL Powah is MINE!!!
journeyman: Locilawhat? Whoization? Whatever, I am tired of having to recompile and constantly change dozens of off-by-a-pixel issues in code. Maybe Interface Builder can be used, but I'll keep it on a short leash.
enlightenment: Interface Builder vs. code? You kids, you gotta, like, embrace the duality of the universe, man... everything in balance... feel it until you don't know where interface builder ends and code begins.... and anyway, its code all the way down, man! Have you got a light?
More seriously, there's a period where you feel like you're fighting interface builder all the time... and once you get past that, you use it where it makes sense and code where code makes sense. The app I'm working on today, the UI is done completely in interface builder, and it has saved a whole lot of time, though animations and stuff like that are done in code, of course.
Nice approach, I've always believed a coder should be able to code an application from scratch.
I wonder if on a long term your workflow is not too time consuming. We use Xcode to avoid writing each time the necessary boilerplate code that is repeated from application to application. I don't think this can be the way to go for a team of coders for example, for a single coder it could work.
Again, nice example of going to the source.
I wonder if on a long term your workflow is not too time consuming. We use Xcode to avoid writing each time the necessary boilerplate code that is repeated from application to application. I don't think this can be the way to go for a team of coders for example, for a single coder it could work.
Again, nice example of going to the source.
If you have boilerplate code that's repeated from app to app you only have to rwite it once, right?
At least that's what I do when developing on a jailbroken iPhone. I don't start from scratch every time.
At least that's what I do when developing on a jailbroken iPhone. I don't start from scratch every time.
I commend your efforts.. but no screenshots? I'm curious to see whether it turned out to look the same as it would have using IB.
I'm with Groxx. You do understand that IB is not necessary for iPhone development, right? I fear a lot of people go into iOS development with that notion in mind and it's simply not true.
Huh. "Page not found
Sorry, the page you were looking for in the blog Dev-P does not exist."
Works here (now). Chrome, Windows 7.
http://printful.com/mirrorizer/
It will check the referrer and redirect you to the mirrored copy of the linked article.
It will check the referrer and redirect you to the mirrored copy of the linked article.
plutil can be used to convert a plist between XML and binary formats (tried to comment on the blog directly, but the commenting didn't seem to work)
There are some errors in there:
// The UIApplicationDelegate protocol requires you implement this function.
// It will return our main UIWindow so the application (UIApplicationMain from main.m)
// knows where to start.
- (UIWindow *) getMainWindow;
Hrm. Thanks, I'll look into it and correct it. I could have sworn it was necessary at one point...
Anyway, for an easier solution for Xcode-less iPhone development, I'd check out Theos by Dustin Howett (https://github.com/DHowett/theos). It's a set of makefiles (mostly used for jailbroken app development), but it uses the same tools and methods as Xcode and the binaries it builds are perfectly fine for the App Store.