

iPhone development emergency guide - sounddust
http://mattgemmell.com/2009/07/14/iphone-development-emergency-guide

======
concretecode
I'd like to see more of this type of thing. When learning a new language, I
don't need an introduction to the if statement or while loops, yet in the
interests of completeness many programming books include a thorough (and mind-
numbing) guide to them. For some readers that's called for, but many of us are
stuck reading about concepts we're already comfortable with. I'm concerned
that if I don't read everything, I'll miss out of some bizarre quirk of the
language, so I'm reluctant to skim, but this gets in the way of what I'm
really trying to achieve - __using __the language to make cool stuff.

Writers of programming language books take note: I'm generally not interested
in the tool. Tools are boring. No really, they are. Making cool stuff and
solving hard problems is interesting and fun. Get the tool out of the way so I
can get things done.

~~~
tptacek
Agreed. I wrote a couple-page cheat sheet on Objective C, and since I've made
a twice-yearly ritual out of forgetting Objective C, it's come in handy.
Repeatedly.

~~~
mcav
If you ever have time or inclination to share it, I could use a good cheat
sheet. The closest I have now is "Objective C for C++ programmers", but it's
not short enough to be a useful cheat sheet.

~~~
bouncingsoul
This was meant as an intro, but maybe it works as a quick reference too:
<http://cocoadevcentral.com/d/learn_objectivec/>

------
dejb
\- You have to use a Mac to develop iPhone apps.

\- You have to use Xcode as your IDE.

\- You have to use the Objective-C language

\- You have to manage your memory manually.

\- You have to have a certificate in order to sign your code to make it work
on a device.

\- You have to pay a yearly fee ($99) to get the ability to create such a
certificate.

\- You’ll have to provide various pieces of information, and enter into a
distribution contract with Apple.

\- Apple has to approve your app before it goes onto the App Store.

Seems a little restrictive. Imagine the antitrust concerns this would bring up
if the platform actually did become dominant.

~~~
tptacek
It's no more restrictive than any major game console.

~~~
dejb
Yes. Which is why I think it would be best to view the iPhone platform in a
similar light as a game console. Cool and fun, but not something you would
seriously be expecting to be the basis of the next wave of personal computing.

~~~
roc
Actually, I think the iPhone's success has practically guaranteed the next
wave of personal computing will follow the console model.

It's easier for the user, the development community is willing and it offers
larger returns for the platform creator.

Besides, most of the guts of personal computing are being done via protocols
and services; platform lock-in isn't really done on the device anymore.

~~~
dejb
That would truly be a sad future, worse than the '1984' scenario being played
out by Amazon's DRM. What free person would want to rely on a device that
required the manufacturers constant consent to allow it to function as that
they wanted? Thankfully this seems unlikely. History suggests that there is a
significant benefit in choice and freedom and that consumers will eventually
follow that path.

> It's easier for the user, the development community is willing and it offers
> larger returns for the platform creator.

So the lock-in is powerful and effective?

> Besides, most of the guts of personal computing are being done via protocols
> and services; platform lock-in isn't really done on the device anymore.

So the lock-in doesn't really matter?

Which is it? You can't have it both ways. The answer is that the lock-in acts
like friction, wasting value instead of providing returns for participants in
the system.

~~~
jcl
The important thing is not the lock-in, and probably not even the pre-
screening of applications. The important thing is the streamlining of getting
software and updates to the user.

If centralized software distribution scares you, be afraid of Ubuntu.

~~~
xel02
With the iPhone there is one software repository. With Ubuntu (and most major
distributions) you can roll your own repository (or someone selling software
can).

Centralized software distribution is awesome, the issue with the iPhone model
is that you have to be anointed.

------
einarvollset
"The equivalent to Java’s this is pretty much self."

Well no, the difference (inside a class) of:

this.foo = myshinyobject

and

foo = myshinyobject

is nothing in Java. In Objective-C,

self.foo = myshinyobject

and

foo = myshinyobject

are different. Particularly with regards to the @property (retain) magic; if
you forget self.foo and use foo, then myshinyobject might get garbage
collected. Which is not what you'd expect with a retained property.

~~~
tumult
Well, on iPhone, it would get deallocated with the next pool drain, not
garbage collected (since garbage collection does not exist for iPhone as of
now.)

foo = myshinyobject is ok if you use instantiate it like [[SomeClassThing
alloc] initetc] rather than one of the convenience methods like
[SomeClassThing thing] since those are supposed to be returned with a retain
count of 0.

I forgot what I was getting at.

~~~
einarvollset
Well, sort of.

If you do an alloc/init, then you need to release it (or you leak). If you're
assigning to self.foo, then you can just release the thing you created after
assigning it. If you assigned it to foo, and then release it, then you're in
the position I mentioned above.

------
igorgue
Too many "have to", you guys know that you can use Mono to develop iPhone
apps?

