Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

detz

macrumors 65816
Original poster
Jun 29, 2007
1,051
0
If you have to come up with a list of 10 things that every iOS programmer should know what would be on it?

I have:
  • delegates and how they differ from notifications
  • ARC and autorelease
  • Properties and their settings (strong, weak, nonatomic, etc)
  • MVC and how it works with iOS
  • Blocks - What are they and why are they useful

Thanks.
 
I would probably ditch ARC / auto release - knowing the right property modifiers is good enough 99% of the time (and not even knowing those is good enough ~75% of the time.)

Something important for your checklist is auto layout, storyboard, and collection / table views.

Are we talking about for hiring a developer? I'd want to focus less on Obj-C and more on programming. Can/do they unit test? Can/do they use source control? Can/do they use debuggers? Can/do they comment?

I ask can/do because just knowing how doesn't actually mean they understand the value and do it.
 
I would probably ditch ARC / auto release - knowing the right property modifiers is good enough 99% of the time (and not even knowing those is good enough ~75% of the time.)

Something important for your checklist is auto layout, storyboard, and collection / table views.

Are we talking about for hiring a developer? I'd want to focus less on Obj-C and more on programming. Can/do they unit test? Can/do they use source control? Can/do they use debuggers? Can/do they comment?

I ask can/do because just knowing how doesn't actually mean they understand the value and do it.


Yeah, understanding table/collection views and how they work with delegates/data sources would be a good one. Not sure about storyboards, it would be nice if they know them but personally I'm not a huge fan and think it's more powerful to not use them.

Unit Testing and basic debugging (Breakpoints, stepping, etc) is a must. Thanks

They should know what a xib file is and how it's used though which kind of plays into storyboards. It's important to know how to do it with an interface and just with code so you understand what the gui is doing for you.
 
They should know what a xib file is and how it's used though which kind of plays into storyboards. It's important to know how to do it with an interface and just with code so you understand what the gui is doing for you.

It's true that you can write code to accomplish anything Storyboards and XIBs can do. By the same token, you could use CoreFoundation instead of Foundation. You wouldn't do that, though, because it's often more productive to use Foundation (although once in a while you might want to use a CoreFoundation data structure which lacks a Foundation equivalent.) Similarly, people should know how to use Storyboards. If a task can be done with either a Storyboard or through code, it'll be simpler and quicker to do it with the storyboard. And if you're intimately familiar with them, you'll know the extents of what they can do and know when you need to switch over to coding because the behavior you want is too unique (which should raise some flags about your UX. Is it unique for a good reason, or should you be doing something that's more standard?)
 
Re: storyboards

What a developer should know is that there are multiple ways of doing some things. So instead of banging their head against that one way, they can try an alternative.

If a storyboard or auto-layout set-up is too convoluted for their app's UX, they can plop down some custom jumping object in code. Or vice-versa.

----------

I don't think I could select a "top 10" from what's there, because restricting it to only 10 would leave out some essentials.

Nonsense. Humans can't consistently keep more than 9 things in mind, so unless you prioritize, you are probably making a mistake in the most important thing.
 
Nonsense. Humans can't consistently keep more than 9 things in mind, so unless you prioritize, you are probably making a mistake in the most important thing.

Even more reason number 1 in the top ten should, learn how to use the documentation.

Understanding @protocol would be pretty high on my list as well. Not just to for Delegates but as a class extension method an alternative to subclassing.
 
Even more reason number 1 in the top ten should, learn how to use the documentation.

I'd love to see this be incorporated into an interview. And seeing as I sometimes am on the other end of the interview table, I'll be sure to start mixing it in.
 
I'd love to see this be incorporated into an interview. And seeing as I sometimes am on the other end of the interview table, I'll be sure to start mixing it in.

Yeah, find an obscure api in the docs that they probably haven't used and create a scenario where they have to use it. Give them the docs and have at it. Using the docs (and or the Internet) is extremely important and I would rather know that a person understands how to research how to build a certain algorithm vs them memorizing them.
 
Understanding the concept of a runloop helps immensely when it comes to how / when one should dispatch task in threads.

Asynchronous programming in an event driven App model is what provided the biggest leap in understanding how iOS should be programmed.

(Wow, that sentence sounds cheesy, anyways ... I mean it)

Forums are full of questions about why performance sucks, or how they "draw" incremental content on screen, because it's hard to understand the event driven nature of an App.

Once I got my head around this, my code improved a lot.

Dispatching results back on the main thread, queuing up image operations in bitmap context or similar is so important.

Read about GCD, Blocks and all the other good stuff that really can improve your App a lot.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.