How to Write Good iOS Apps
coffeetimerapp.com
coffeetimerapp.com
For deep-dives into the nitty gritty of Cocoa Touch, we've learned minute important details from digesting countless hours of WWDC videos that make all the difference.
http://developer.apple.com/videos/wwdc/2011/
Especially the perennial classic, "Designing Apps with Scrollviews"
This is not true at all and it is a very dangerous suggestion. Automatic Reference Counting indeed makes memory management an awful lot simpler (often you don't have to do any explicit memory management at all with it) but you still need to learn about it and understand it, otherwise all sorts of bad things will happen like memory leaks due to circular references (delegates come to mind) and crashes due to the autorelease pool high-water mark eating up all the memory on iOS devices.
And after you've learned all of this, you can also do some really neat things with Cocoa's dynamic runtime. Things like invocation building using a category and code like this (or similarly, store and queue up actions on the Mac's Undo manager):
[[NSInvocation invocationBuilderWithTarget:self] aRandomMethod:arg];
Also, in Objective-C you should never user the Garbage Collection feature. And Automatic Reference Counting, while awesome, is not production-ready yet. Apple will not approve apps with it yet—I know, I've been rejected for trying to use it in an app.
[1]: HN's markdown parsing is a little funky, this is meant to say:
NSError**Why not? On the Mac, the garbage collection process is offloaded to another CPU. Any performance hit is more than made up for the fact that developers probably messed up the retain counts.
Memory management is a thing that you have to get perfect or your app will crash. I personally trust ARC or GC more than I trust myself.
> I personally trust ARC or GC more than I trust myself.
I don't. Reference counted memory management is so easy that I never had the problem of leaking/crashing apps because of forgotten retain/releases. The most common memory management related bug for me are hidden retain cycles. (Which ARC doesn't really address.)
But ARC is pretty nice for the stupid UI boilerplate code which saves you from writing huge -dealloc methods. For critical code (Obj-C and C intermixing) I tend to disable ARC.
Just change the Info.plist of your app (so that it looks like it was built with the non beta of XCode), re-codesign the bundle and upload it. (Have tested it with OS X apps. No guarantee for iOS.)
My argument wasn't to go and be naive about memory management. It was to not worry about it right now. Memory management makes the already steep learning curve of Objective-C even steeper, and can scare away newcomers.
The other reason people are careful about autoreleases is because, obviously, objects in the autorelease pool won't get deallocated until the pool is drained, which normally happens in the main application loop. Normally, this is not a problem, but if you do memory-intensive things (like dealing with images or other media) in a loop that means that you will consume a lot of memory before the autorelease pool gets drained. This might get other apps killed (on iOS 4+), and ultimately, yours too.
If you're already in the habit of autoreleasing everything you +alloc, why not just release it when you're done with it instead?
UIView* view = [[UIView alloc] init]; ...do a bunch of stuff [view release] <-- you have to remember this
vs. UIView* view = [[[UIView alloc] init] autorelease];
Of course I know about the cases where we have tight loops,w hich is why i said 99 of the time.
The worst that will happen is that you might get a circular reference and leak memory. This may (or may not) cause your app to eventually crash.
I wouldn't say that. I consider learning by trial and error far more valuable than reading the best books on a topic.
If you read the guide now you get more out of it. You have done the groundwork yourself - now it's time to hone your skills :)
Hilarious, great article.
Teaching a course seems to be an excellent way to learn the basics. It does not make you an expert, though - that needs a couple years of practice.
Creating good apps has nothing to do with the tools you use, it is how you use them ... And more importantly than that, knowing how to design, polish, shine, and pay attention to detail is what makes a good app. Maybe adhering to some standard UI styles and layouts as well.
EDIT: Wow, I'm bummed that this is getting down-voted. Maybe reply with WHY you are down-voting because developing GOOD apps in Corona is much easier than the route described by the author of this post.
If you don't want to, you will have to look elsewhere though.
Now you can develop for Android AND iOS with Corona, plus, you can use their Native UI API to create actual apps with Corona, not just games:
http://developer.anscamobile.com/content/native-ui
Check out their showcase:
http://developer.anscamobile.com/showcase/
I'm not affiliated with Corona other than that I'm a subscriber and developer who uses Corona and loves the heck out of it.
Canyon County National Parks - looks good, but scrolling is noticeably non-native in several ways, and the app is oddly slow sometimes
Drum Toy - takes forever to load, ugly sliders
iSleepWell - UI is confusing and difficult to use (tap areas too small)
For some screens, it is certainly faster and easier to programmatically build them up, but for the vast majority of screens, your comment seems to tell more about a willingness to learn than a desire to make good apps.
Perhaps you stopped trying to use it during the Xcode3 days? Now, almost any hairs it did have got shaved off in the Xcode3->4 transition.
I'm not saying use it for all adjustments to views, sometimes those go faster in code, but it is by far the better way to do almost every view.
If you prefer to boil each grain of rice separately for a pilaf, and it tastes the same at the end, you just wasted a lot of time in the kitchen for no good reason other than you've not stopped and learned how to boil them all at once.
Try the new Xcode4 book: http://www.amazon.com/Xcode-Developer-Reference-Richard-Went...
It goes into IB's newest incarnation. IB is also fantastic when adding assecessability functions to your app. Another reason to add accessability functions to your app (beyond being a good human being who lets not-fully sighted people use your app) is that it allows kif to work: http://corner.squareup.com/2011/07/ios-integration-testing.h... (play the video).
I'm not a IB Zealot, I make views manually when it makes more sense to or IB is just not doing it's job with any speed, but "0" is not the amount anyone should be using it who makes non-game apps.
Sure: http://www.goodtimestove.com/
Modern constraints(http://developer.apple.com/library/mac/#recipes/xcode_help-i...), for instance, are insane to edit manually with no visualization on any complicated screen.
Perhaps you're just building tons and tons of tableview cells or something else automatically laid out for you, so you're not really feeling it (or are too strident a believer of your position to learn then judge, rather than judge first). But if you do any manual layout at all, there are huge wins within days of starting to learn the tool.
It feels like I'm discussing with someone contending that zip files are as good as source control here.
Is the iOS link to the same article. I just hit the wrong one in google.
>The one thing I would recommend people do is not use Interface Designer. It bloats your code base and adds more complexity to the view hierarchy. It might be good to quickly mock-up a prototype, but not much else.
Is the issue. If you yourself wish to do things a different way, that's fine, but it should be clear to people that this is a you thing, not a thing that's really accepted by anyone much who does this. Have fun not using it, it's fine, I'm not working with you in particular.
Your example, however, is probably amongst the worst to support the argument you are making. Here are the steps to create a tab bar view with four tabs, each containing a navigation view, and those containing alternating table views and plain views:
- drag out a UITabBarController
- remove the two default UIViewControllers instantiated with it
- drag out to the tab bar four UINavigationControllers
- select each tab and drag out to the center area of the view a UITableViewController or UIViewController
- customize to your heart's content
- there is no step six…
In my guestimate this will take at least 20 lines of boilerplate code, even with the minimal amount of customization. And you’d be missing out on all the rest of the benefits of NIBs, like the ability to see (and to some degree test) your UI without having to build and run your application or the ability to send it off for localization to a collaborator.
For example, instead of drawing a table programmatically, I can drag it into my view from Interface Builder's default list of objects. I can edit the table's properties quickly and easily.
And that's just one tiny example. Suppose you have a complex interface with loads of different buttons, sliders etc, custom backgrounds - you would have to set everything in code (e.g. button background images, button type, x and y co-ordinates on the view). In my admittedly limited experience that adds massively to the amount of code you have to write. It's crazy not to use IB in my opinion, but each to their own.
How does it add more complexity to your view hierarchy exactly?
Most people are getting away from doing their UI's in code and moving back to their proper place in IB.
This is done almost entirely in IB:
http://www.youtube.com/watch?v=Tk8HCkqZsNU
As is this:
I'd still be typing if I did it in code.
Weird.
It's unfortunate that the Default.png is a photo when the UI doesn't seem to vary enough to exclude the standard preview shot.
In the adjustments view, "Finish" should be "Done". And tapping it should not trigger a flip animation-- it's too distracting.
Also, the music is extremely loud.
Not sure what you mean by the standard preview shot?
How so?
All Interface Builder really does is serializes the objects, much like you would any other object supporting NSCoding. The net result is that an instantiated view from IB should be identical to one you created manually.
IB certainly isn't the right tool for all situations, but its design is pretty clever with tight integration with the rest of the system. I can't see any reason not to use it, when it is appropriate.
Care to be more specific?
OK, but why?
Seriously, it'll be worth it not to learn about manual memory management.
I'm confused - MonoTouch presumably has garbage collection, but Objective-C lets you 'not learn about manual memory management'. What's the deal?
I believe he's making reference to the inclusion of automatic reference counting in iOS 5.
EDIT: @tptacek What confused me is there's no reason given to avoid MonoTouch, so I latched onto the memory management comment, to try and make sense of the text.