Slashdot Mirror
Beginning iPhone Development
Cory Foy writes "When my wife got a Touch several months back, the first thing I wanted to do was build some applications for it. Who wouldn't want to play with a device that has accelerometers, position sensors and multi-touch gestures? But being new to the Mac world, I needed something to help guide me along. Beginning iPhone Development aims to be that guide. But does it live up to the challenge of teaching a newbie Mac and iPhone developer?" Read below for the rest of Cory's review.
Beginning iPhone Development: Exploring the iPhone SDK
author
Dave Mark, Jeff LaMarche
pages
536
publisher
Apress
rating
Five $1000 Rubies
reviewer
Cory Foy
ISBN
978-1-4302-1626-1
summary
A great introduction to the iPhone SDK and getting into iPhone Development
The first thing you'll need to do is head over to the Apple Developers Site and register for an account. You can then download the iPhone API. Note that while the API download and simulator are free — deploying to a real iPhone or iTouch is not, even if it is your own. To do that you have to apply to the iPhone Developer Program which is $99. For the book, you'll be fine with just the simulator with the exception of any accelerometer application, since the simulator doesn't have that feature.
With that out of the way, I was quite impressed with the book. Although I've done quite a bit of development in the past, I haven't worked with Objective-C before, and was a little concerned if I would be in over my head. If you are in that position, don't fear — the authors do a great job of walking you through, and you'll find yourself working with it in no time.
The first chapters introduce you to the basics of the iPhone and development, starting with the canonical "Hello, World" application. The book walks you through how to get and install Xcode and the iPhone API. It then introduces you to Interface Builder, the partner-in-crime to Xcode. Even in the first chapter, the authors show their attention to detail, explaining common issues you might run into (like trying to Build and Run while your iPhone or iTouch is plugged in to your Mac).
Chapter 3 introduces the Model-View-Controller paradigm, a pattern that is probably one of the most misunderstood patterns in UI development. They give you enough information to be familiar with the terms you'll be using, and they very much mean it when they tell you not to worry if you aren't understanding something — they always loop back around to make sure you understand it.
Chapter 4 was a long chapter for me, but introduces some important concepts around user interaction and controls. By the end, you have an interface which has a variety of controls which interact with each other. As with the other chapters, the authors introduce tips and tricks to make things easier (for example, Option->Cmd->Up Arrow to switch from the header to implementation file in Xcode).
Chapter 5 covers autorotation and basic animations, including linking in the Core Graphics Framework. I especially like how the authors gave three different ways of making your app auto-rotation aware, describing the benefits and drawbacks of each. Chapter 6 follows this up by introducing multi-view interfaces, something very necessary as you get into more complex iPhone development.
Chapters 7-9 describe various methods to presenting information to users, including toolbars, table views, hierarchical navigation and hierarchical lists. However, it isn't all drag-n-drop, the authors get into some good (and sometimes deep) conversations about what you are doing. For example, in Chapter 8, they talk about issues with NSDictionary and how to create deep mutable copies.
Chapters 10-13 are the last of the "fundamentals" — application settings, basic data management, custom drawing using Quartz and Open GL, and taking inputs (including gestures and multi-touch). As someone who spends most of his time as far away from graphics libraries as possible, I was quite impressed with the basics that were introduced and what someone like me could get up and running.
Finally we get into the fun. Chapter 14 introduces Core Location, allowing to figure out where in the world you are. The book goes through a discussion about the various ways to get location information, and drawbacks of each. (Helpful tip: no matter which method, if you are polling every second, you'll drain the battery pretty quickly). For the simulator-only users, this is when things start to become tricky. Chapter 14 does work, though you aren't prompted for access to Core Location.
Chapter 15, however, is useless without an actual phone, even though it's perhaps the most fun. In this chapter, the book goes through the accelerometer and all the interesting things you can do with it. There's even a small discussion on the physics (but just enough!). Both apps you create (Shake and Break and the Marble game) are quite fun for someone just starting out with all of this. It's a shame Apple couldn't figure out a way yet to include the accelerometer in the simulator.
Chapter 16 covers using the iPhone camera and Photo Library. It's short, but it shows the power of the simple interfaces Apple provides. In just 9 pages you'll be capturing images right from the iPhone.
The final two chapters I thought were quite fitting — Localization and Follow-Ups. In the localization chapter, the book covers extracting strings out to resource files and using locale to read them in. Having a day job which ships our software in 12 different languages, I know first-hand how difficult localization can be to get right, so I was glad to see this chapter. The final chapter is just a wrap-up of resources you can reach out to for help and information.
All in all I was very surprised and pleased with the book. I've had the fortune of reading many technical books, and few do a great job of walking someone through the basics without making them feel like a dolt. It felt like every time I was stuck or unsure there was a tip, hint or paragraph which explained what was going on.
The main drawback to me is the fee to deploy apps to your own phone. This wasn't something I ran into doing either J2ME or Windows Mobile apps in the past, and it is a shame that to even work on your own phone you have to pay a fee. However, since the fee does give you the ability to submit apps to the App Store, then I guess it's a consolation. I'd rather Apple lock deployments to one iPhone (or iTouch) for the truly casual people who just want to do interesting things on their own phone.
In summary, I give this book five $1000 Rubys for making a clean, concise, easy-to-read and follow introduction to iPhone development. Great job guys!
You can purchase Beginning iPhone Development: Exploring the iPhone SDK from amazon.com. Slashdot welcomes readers' book reviews — to see your own review here, read the book review guidelines, then visit the submission page.
With that out of the way, I was quite impressed with the book. Although I've done quite a bit of development in the past, I haven't worked with Objective-C before, and was a little concerned if I would be in over my head. If you are in that position, don't fear — the authors do a great job of walking you through, and you'll find yourself working with it in no time.
The first chapters introduce you to the basics of the iPhone and development, starting with the canonical "Hello, World" application. The book walks you through how to get and install Xcode and the iPhone API. It then introduces you to Interface Builder, the partner-in-crime to Xcode. Even in the first chapter, the authors show their attention to detail, explaining common issues you might run into (like trying to Build and Run while your iPhone or iTouch is plugged in to your Mac).
Chapter 3 introduces the Model-View-Controller paradigm, a pattern that is probably one of the most misunderstood patterns in UI development. They give you enough information to be familiar with the terms you'll be using, and they very much mean it when they tell you not to worry if you aren't understanding something — they always loop back around to make sure you understand it.
Chapter 4 was a long chapter for me, but introduces some important concepts around user interaction and controls. By the end, you have an interface which has a variety of controls which interact with each other. As with the other chapters, the authors introduce tips and tricks to make things easier (for example, Option->Cmd->Up Arrow to switch from the header to implementation file in Xcode).
Chapter 5 covers autorotation and basic animations, including linking in the Core Graphics Framework. I especially like how the authors gave three different ways of making your app auto-rotation aware, describing the benefits and drawbacks of each. Chapter 6 follows this up by introducing multi-view interfaces, something very necessary as you get into more complex iPhone development.
Chapters 7-9 describe various methods to presenting information to users, including toolbars, table views, hierarchical navigation and hierarchical lists. However, it isn't all drag-n-drop, the authors get into some good (and sometimes deep) conversations about what you are doing. For example, in Chapter 8, they talk about issues with NSDictionary and how to create deep mutable copies.
Chapters 10-13 are the last of the "fundamentals" — application settings, basic data management, custom drawing using Quartz and Open GL, and taking inputs (including gestures and multi-touch). As someone who spends most of his time as far away from graphics libraries as possible, I was quite impressed with the basics that were introduced and what someone like me could get up and running.
Finally we get into the fun. Chapter 14 introduces Core Location, allowing to figure out where in the world you are. The book goes through a discussion about the various ways to get location information, and drawbacks of each. (Helpful tip: no matter which method, if you are polling every second, you'll drain the battery pretty quickly). For the simulator-only users, this is when things start to become tricky. Chapter 14 does work, though you aren't prompted for access to Core Location.
Chapter 15, however, is useless without an actual phone, even though it's perhaps the most fun. In this chapter, the book goes through the accelerometer and all the interesting things you can do with it. There's even a small discussion on the physics (but just enough!). Both apps you create (Shake and Break and the Marble game) are quite fun for someone just starting out with all of this. It's a shame Apple couldn't figure out a way yet to include the accelerometer in the simulator.
Chapter 16 covers using the iPhone camera and Photo Library. It's short, but it shows the power of the simple interfaces Apple provides. In just 9 pages you'll be capturing images right from the iPhone.
The final two chapters I thought were quite fitting — Localization and Follow-Ups. In the localization chapter, the book covers extracting strings out to resource files and using locale to read them in. Having a day job which ships our software in 12 different languages, I know first-hand how difficult localization can be to get right, so I was glad to see this chapter. The final chapter is just a wrap-up of resources you can reach out to for help and information.
All in all I was very surprised and pleased with the book. I've had the fortune of reading many technical books, and few do a great job of walking someone through the basics without making them feel like a dolt. It felt like every time I was stuck or unsure there was a tip, hint or paragraph which explained what was going on.
The main drawback to me is the fee to deploy apps to your own phone. This wasn't something I ran into doing either J2ME or Windows Mobile apps in the past, and it is a shame that to even work on your own phone you have to pay a fee. However, since the fee does give you the ability to submit apps to the App Store, then I guess it's a consolation. I'd rather Apple lock deployments to one iPhone (or iTouch) for the truly casual people who just want to do interesting things on their own phone.
In summary, I give this book five $1000 Rubys for making a clean, concise, easy-to-read and follow introduction to iPhone development. Great job guys!
You can purchase Beginning iPhone Development: Exploring the iPhone SDK from amazon.com. Slashdot welcomes readers' book reviews — to see your own review here, read the book review guidelines, then visit the submission page.
What the hell is an iTouch? Sounds like something from a sex store.
If you have a background in both C/C++, and in OOP. Otherwise, I'd suggest getting a little background in those first. I think it's slightly misleading to imply that this book is the best hand-holder in this regards.
Reply to That ||
why should i pay to develop for a device that is already overpriced?
and in a language that no one else use?
J2ME tools are free, and you wont get censured by AppStore...
we got together, iTouched her a little, and then iGave her a good rogering
Saying "iTouch", you fucking toolbox. It's an "iPod Touch". How difficult is that?
Yep. Just get this book (*coughs*and buy the required Mac to develop on the iPhone*coughs*) and you're good to go!
Programming the device is rather simple, going through all the Apple hoops just to put the app on your device or deploy it is far
more difficult. In fact if you start the developer sign up process and your application programming on the same day it is highly likely
that your app will be ready way before Apple gives you the go ahead to pay them $100 for the opportunity to program for it.
What's an iTouch?
It's an iPod Touch, you insensitive clod!
> Note that while the API download and simulator are free â" deploying to a real iPhone or iTouch is not, even if it is your own.
Not necessarily true. There are ways to circument the code-signing.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
What is this iTouch of which you speak? It sounds like something ... interesting. Or do you mean iPod Touch, which is also interesting but in a far less sexually suggestive way? (Being a smartass aside, if you're going to develop for it, you might want to make sure you call it by the correct name. Ok, that's still being a smartass...)
There is nothing sacred about a simple 'Hello World' application.
I was told by my first C instructor that if we didn't do a Hello, World! application first, we would be thrown to the lowest depths of programming hell. I had no interest in taking such a risk at the time.
Reply to That ||
On iPhone development?
What could possibly be a better use of a engineer's efforts than:
* Going out and buying an overpriced Mac that is useless for anything other than running the Apple devtools
* Having to waste time hooking up monitor and keyboard switches to your work environment just for the Mac hardware
* Wasting time learning Objective C that no other company uses except Apple
* Having your application be at the total whim of Apple who could at any moment or for any reason decide to reject your app or pull your app from the Apple store
Android will have rapidly taken over most of the existing Windows Mobile range of devices just looking at the public release list of Android based phones for 2009. And Palm's Pre is now the gold standard for high end phones.
Apple got lucky with Microsoft completely botching their phone efforts and arriving at a time before Android and Palm's efforts. The iPhone is nothing more than an irrelevant and overpriced niche product. Even more so now that Jobs is out of the picture and Apple can no longer leverage the Cult of Jobs in the media for massive hype, promotion, and marketing for their products.
Really? I always hated MacOS and everything Apple stood for, but you've convinced me otherwise, where do I sign up?!
The standard Hello World is the beginning of every rite to praising the machine spirit.
---------
Oh good God this is getting posted Anon
Oh, that's right... Somewhere a High School report writing lab is still open and those two individuals have mod points.
I feel as though I just wasted an additional entire minute and a half re-reading this review for content...
It appears as though this is a "review" of a book about iTouch software development.
iWouldn't eRead this rEview.
"The Borba"
You can then download the iPhone API
I was under the impression that this was called a SDK, and not an API?
Then again, maybe I am just being Lord Pedantro the Quarrelsome.
yea, cause using a language like java, python, or any oo really makes sense on a microcontroller or any other embedded device that isnt basically a full fledged pc, e.g. the iphone. Ya know some people do still need to talk to hardware directly and handle interrupts. Its not like this whole segment of the market is very small either. C will be around for a long time because it is the best solution for small embedded projects.
I thought the first step was getting a Mac, then you can get the sdk. It's actually a pretty high barrier to entry for a developer.
-- these are only opinions and they might not be mine.
Not doing "Hello World" is no where near as dangerous as using GOTO!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
It's possible to link up an iPhone's accelerometer to the simulator, and it's also possible to link up the accelerometer in a MacBook to the simulator as well. More details here. Honestly, though, it's probably easier to just jailbreak your iPhone.
Bogtha Bogtha Bogtha
The biggest problem I've had so far is Interface Builder. It isn't the most intuitive piece of software. Dragging and dropping to connect button actions to methods between two pieces of software (XCode and Interface Builder) that don't actively sync with one another, at least not as I've yet to find.
I already had the C/C++ and GUI/fat client app building experience from 10 years back.
+fragbait
Note that while the API download and simulator are free â" deploying to a real iPhone or iTouch is not, even if it is your own. To do that you have to apply to the iPhone Developer Program which is $99.
THL phish sticks
1. The language discussed is Objective C, not C.
2. If no one programs in languages like C, you can say goodbye to modern computing. There's no way you're going to program an operating system in Python.
iTouch is the name of a UK company that provides mobile content. They were around a long time before the iPod touch but lost top spot in Google to Apple despite the fact they don't make a product of that name.
There is a company in Reston VA that trains iPhone developers http://www.aboutobjects.com/iPhone-SDK-Course.do
Very coincidentally, I picked up this book last Friday. Downloaded the SDK, and did the first chapter (dead easy). Beyond that, the book does recommend at least a passing knowledge of Objective-C. Fortunately, I have a "Learning Objective-C" book for noobs (which I am when it comes to anything C).
and i have yet to see a single good embedded device based on java that runs as quickly or as well as any comparable product that was done in C. For the embedded space java is just not up to it at this point for either realtime apps or user interfaces. Just compare the comcast/SA/motorola set top boxes to the ones from tivo, directv, and dish. The latter are all written in C, the former in Java, and it shows in speed. The ones in C are way faster from a user perspective than the ones in Java.
Dear Sir, Madam, or Troll;
If you don't care, then you're not our customer anyway. As such...
We don't care.
Sincerely,
Apple Legal
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
Does anyone know what the state of Qt is on the iPhone? I figure the core classes are ok, but does it use the same Carbon/Cocoa APIs?
I'd love to use Qt just so I don't need to learn a whole other development platform
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Unfortunately Objective-C is designed such that it combines the worst parts of C with the worst parts of dynamic languages, so your point doesn't really hold. Method dispatch is all dynamic, and in the best case seems to be twice as slow as a C++ vcall. But it only gets that speed by building runtime dispatch caches, ie, trading off memory against CPU. On phones memory is also very limited.
It really is an amazingly stupid language. I am not surprised no-one except Apple uses it. This is the language that thinks it's a good idea to redefine boolean to be YES and NO.
That sort of weird syntax quirk is not a big deal though, it's just a time-waster. The real problems start when you realize that calling a method on a NULL object doesn't crash. Instead it returns zero, another NULL or if the method returns a struct, garbage. So what would be a clean kill with a nice stack trace in any sane language in Objective-C turns into silent propagation through your code of NULL pointers and zeros, until you save state and blow away the users data.
On the iPhone there's no garbage collection. Yes it's back to the days of ref counting, whoopie-doo. The best they have to offer is a kludge called an "auto release pool", which basically just scopes lifetime to the current GUI event. Pretty useless for anything that lasts longer than a button push. It also massively complicates exception handling due to the rules around how auto-release pools stack (yes really).
Then there's the lack of features. No namespaces. No abstract classes. No stack allocation thus no RAII. No operator overloading. No generics, really no type safety at all (calling a non-existant method is a warning not an error). Your code is trivial to decompile. And of course the only really supported development environment is a Mac.
Java might be a stupid language to use on a phone as well, but seriously, I'll take that kind of stupid any day over Objective-C.
The first part of development is knowing the actual name of the platform you're developing on. There's no such thing an "iTouch".
Im not sure if your replying to the first post downplaying C or the one against using java. If it was the second, there was no mention of Objective-C only C
Interface Builder is fairly bizarre, but it starts to make sense after a while. It does. Really.
My primary reference for iPhone development has been Erica Sadun's book, but I may pick this one up too.
BTW: people may bitch about code signing, but Apple gave me my signature when I asked for it. This is minor compared with what was necessary when my employers wanted to do Brew development. I considered going the jailbreak route, but ended up not doing so.
...laura
I bought this book and it's way over my head since I have never dabbled with any OO programming. I bought Kochan's Programming in Objective-C 2.0 and it starts out assuming no knowledge of programming whatsoever. So those to books combined would be a good start.
PalmOS vs. Blackberry. No comparison needed. You wouldn't know one was running Java if it hit you on the hit with a giant strychnine laced bean. :-)
And there's breakout, and super breakout....
I have an iPhone 3g myself, and a few weeks of use got me excited enough about app development to feel truly let down when I discovered I'd have to buy a mac to develop on. Actually pricing one out that I could use for high-end photoshop work in addition to iPhone development was a sobering experience. Add that to the learning curve associated with migrating to OSX from WinXP, and I'm back to Flash development on my PC.
Mamoo dogface to teh banana patch.
If you mod me down, I shall become more powerful than you could possibly imagine.
still waiting for the windows SDK.
How do you make a small fortune as an iPhone developer?
Start with a large one.
If you mod me down, I shall become more powerful than you could possibly imagine.
When my wife got an Touch several months back, the first thing I wanted to do was build some applications for it. Who wouldn't want to play with a device that has accelerometers, position sensors and multi-touch gestures?
When I read about the accelerometers, position sensors and multi-touch gestures, of course I thought you were referring to your wife...
This space for rent, inquire within.
Say it as often as you want but some people will try.
- Michael T. Babcock (Yes, I blog)
I have to say that this book, which I picked up last week, has really given me a kick in the pants as far as getting back into programming. I haven't hardly done a damn thing since college in '02, and since I went to a pretty craptastic school that doesn't mean much.
MS Visual C++ really made programming a slog, compared to the IDE that Apple came up with for XCode. I'm just a couple chapters into the book now, but all in all I'm really enjoying the process of programming again for the first time since GW-BASIC. I can understand why a lot of people here (especially here) complain about having to buy a Mac, having to use XCode, having to do things Apple's way but for something like the iPhone and iPod Touch development I can't imagine a better route.
This is for the most part a very good book, at least for my rusty brain, but it definitely needs some kind of Objective-C accompaniment if you're not familiar with the language and want to do more than just follow instructions. Well worth the money.
And again, to those people complaining about XCode and doing things Apple's way, dig around the ADC site and you'll see that Apple's learned a hell of a lot since the days when CodeWarrior was the only hope for a Mac developer's sanity.
My own pointless vanity vintage computing page
I've always preferred Java to be honest.
public Class PostingBollocks {
public static void main(String[] args) {
public boolean posting = true;
public Kid anonymousCoward = new Kid("chubby", "virgin", "male breasts");
public Mom yoMomma = new Mom("fat", "slag", "peg leg");
public int knobs = 0;
while(posting == true) {
knobs++;
yoMomma.gobble(knobs);
if(knobs == 100) {
yoMomma.sendKidsToBed(anonymousCoward);
anonymousCoward.crySelfToSleepInMins(60);
System.out.println("You've been sent to bed so you mom can wash her stanky minge out in peace in quiet");
}
}
}
}
What possible reason would you think anyone who owns an iPhone would ever want an app based on a shitty UI toolkit like Qt?
Chapter 5 covers autorotation and basic animations, including linking in the Core Graphics Framework. I especially like how the authors gave three different ways of making your app auto-rotation aware, describing the benefits and drawbacks of each. Chapter 6 follows this up by introducing multi-view interfaces, something very necessary as you get into more complex iPhone development.
If you need to perform autorotation while doing iPhone development, something has gone terribly wrong: http://en.wikipedia.org/wiki/Autorotation.
Don't develop for the iPhone/iPod Touch environment. It's a failing platform. Sure, right now there's lots of potential customers using one of the devices, but as soon as the news hits (and I'm not privy right now to say exactly what this news entails, but believe me, it will send SHOCK WAVES through the tech community), people will flee away from these devices faster than a crowd scrambling from a theater on fire!
- if you have a programming background, read up on objective-c
from the docs on apple site
Then jump into this book. It was certainly helpful for me
to understand how interface builder and objective-c interactive.
The book helps understand that very well.
Also some of the example for navigation bar, tab bars, animation were helpful also. To get more familiar after reading this book,
go to the class library reference or the reference docs from apple.
How have none of the fanboys mentioned yet that you can develop iPhone apps on Linux with Mono?
Mono now supports static compilation, which is one of the requirements to create a legitimate app that can be sold via iTunes. Search for "iphone" on Miguel de Icaza's blog (via Google) to see a number of posts on the subject.
You still have to pay all of the fees, but you aren't limited to Objective C and, in theory, you never have to sully your hands by touching a Mac keyboard.
(Preemptively -- also remember that Mono supports more than just C# and VB.NET. Again it's just theory, but you could write an iPhone app in IronPython, Boo, PHP, Pascal, etc. Anything that compiles down to CIL.)
From Wikipedia (http://en.wikipedia.org/wiki/Objective-C)
"Objective-C, like Smalltalk, can use dynamic typing: an object can be sent a message that is not specified in its interface. This can allow for increased flexibility â" in Objective-C an object can "capture" this message, and depending on the object, can send the message off again to a different object (who can respond to the message correctly and appropriately, or likewise send the message on again). This behavior is known as message forwarding or delegation (see below). Alternatively, an error handler can be used instead, in case the message cannot be forwarded. If the object does not forward the message, handle the error, or respond to it, a runtime error occurs."
So it would appear that calling a method (i.e. sending a message) on an object that does not have a method should blow up during runtime ?
As the island of our knowledge grows, so does the shore of our ignorance.
Listen, what you say makes sense but it doesn't apply to the iPhone. The latency that you attribute to pseudo v-table calls is going to be in the noise level of that device. We are talking about software/hardware interaction; not software/software interactions.
Get off your soap box and contribute
Honestly, if you're not tying into some of the built in iPhone applications, you can make a pretty darn good iPhone website instead of having to buy in to xode and objective C.
We use iUI, it's a bunch of image, css and javascript files that help emulate the look and feel of a native iPhone app.
The only catch is that the HTML has to be VERY simple for it to work, so we had to adopt the ASP.NET MVC development model. Which is not a bad thing to learn if you're eventually headed towards native iPhone apps.
"When my wife got an Touch several months back..." You forgot the "typoinsummary" category. Regards, Your 6th Grade English Teacher
Not crashing when calling something on a NULL object is not necessarily a bad thing. You should read: Enhancing Server Availability and Security Through Failure-Oblivious Computing You can also use TRUE/FALSE and 1/0 for boolean values, too. Dropping stack allocation for objects is, IMHO, a good thing. The fact that C++ has to truncate an object when you pass a subclass to a method that expects the superclass via the stack, but does not when you pass a pointer to it. Not what most people would expect and would break dynamic dispatch.
Personally I find Objective C really rather neat. Of course it undoubtably helps that I grew up with C and can hack it upside down and backwards. I never really used C++ to anything like the same degree (having moved on to other things) and so when I started playing around with the iPhone recently this was my first taste of Objective C.
It's syntax really is weird I agree, but once you get past that - and it's no worse than many other languages - it's just hunky dory. Certainly the freedom of not having C++'s bondage style language features and ridiculous complexity really is rather refreshing. And no gabage-collection - well if you're just coding something the size of an iPhone app and you can't handle your own garbage then really you should go stick to visual basic in a nice safe environment.
The SDK requires an Intel Mac.
It does, but I think the OP point was that "nil" effectively implements all methods and returns 0, nil, or 0XDEADBEEF1374, like a bottom class without the semantic consistency of languages with true bottom types.
Don't blame me, I voted for Baltar.
There are many resources available for iPhone/Cocoa programmers. The earliest versions of Cocoa shipped commercially in 1988, and the most used features and patterns haven't changed much. Here is a good place to start: http://www.cocoadev.com/index.pl?CocoaPrerequisites
Why does Objective-C use BOOl and YES,NO instead of bool and true/false? One reason is that Objective-C predates the addition of the bool type to standard C by 11 years.
If you don't like dynamic languages, you won't like Objective-C. Bruce Eckel makes an interesting argument for dynamic languages at http://www.mindview.net/WebLog/log-0025.
I think the ability to seamlessly use and intermix the world of C and C++ software with Objective-C outweighs and criticism that Objective-C includes C.
You must keep an open mind - There are an infinite number of different ways to solve every programming problem. Many programming languages and reusable software libraries use different approaches to solve common problems. There is a good chance that Objective-C and Cocoa use a substantially different approach from other languages and frameworks you may have used. That doesn't make either approach better or worse automatically. Every commercial software development technology has advantages in at least some cases or the technology would not exist. Cocoa is renowned for enabling very high programmer productivity without constraining the set of problems that can be solved, but programmer's opinions will always vary and software development environments are subject to aesthetic judgments irrespective of abstract technical merit. Many programmers are enthralled by Objective-C and Cocoa. You might be enthralled too. Or, you may never like Objective-C and Cocoa from an aesthetic standpoint, and there isn't really anything anyone can do to change that without affecting the aesthetics for others.
and most applications run only 1.1 times faster than a modern Java app anyway.
An instant ten percent speed up just by choosing the right language can be a meaningful speed increase in many applications.
Get the frame buffer, draw a few bitmaps in, and put in a few bodily noises. You'll be rich in no time.
Shouldn't you be doing null checking anyway, you sloppy developer you?
Sounds like you really didn't use Objective-C/Cocoa long enough to even remotely start to grok it.
- Runtime dispatch caches: what, you think all those vtables that C++ generates don't take up memory?
- Definition of boolean: Objective-C & Cocoa were around long before C added a proper bool type, so yes, they used typedef char, just like every other C framework in existence.
- Messaging null: different, but neither a wholelot worse nor better. If you care about propagation of return values, you'd best be checking. But just as C++ lets you delete null for a convenience, Objective-C lets you message nil for the same reason.
- Autorelease: apparently you didn't notice, what autorelease does for you is that, outside of property accessors, you rarely actually have to bother with reference counting. (And if you'd worked with this for long, you'd have realized that the need to stack autorelease pools is quite rare.)
- I'd like namespaces and abstract classes.
- If you want RAII, just do it yourself using Objective-C++ and constructors/destructors that call retain/release. (Although if you work with this long enough, you'll eventually realize that approach adds overhead for almost no benefit.)
- If you want generics, go ahead and use STL, I do it all the time ;-)
- Non-existent methods: come on, are you really admitting in such a public venue that you ignore compiler warnings? Sloppy!
Yes, Gary, you can go to the bathroom.
Shop as usual. And avoid panic buying.
Picked up another, but similar book, to get started with iPhone / iTouch programming. Besides the horrible way that Apple wants to control how you deploy "your own software" on "your own device", what puts me off even more was the statement that you shouldn't expect that you can use the Touch used for testing your software, for normal operations anymore. As they noted it "the software environment will write to the Touch, which can make it unusable for normal use".
Is this really true? Having to pay $99 is one thing, but having to buy another Touch, just for the fun of developing apps for it, seems to be a little too much.
I'm a pretty experienced WM5 developer, and I can use my regular phone to test my software. Nothing that gets blown away by the SDK.
Browsers shouldn't have a back button!! It's all about going forward...
Is that a promise?
We don't believe in radical loony monotheistic religions from the middle east -- we're Christians.
C++ only does that if you are trying to pass classes by value, which is almost always a bad idea. I agree it's unintuitive but then a lot of C++ is, you don't lose anything if you simply never pass subclasses by value. If you use references the whole problem disappears.
Here's my reviews of iPhone developer books, and picks of the 4 best:
http://www.markj.net/iphone-development-programming-books/
Mark
Let me tell you a secret.
There were other systems languages before C and there *will* be others after C.
Although C is a nice language, it is also the major culprit of today's lack of security in major OS.
I dream the day when the OSs are coded in a systems language not prone to buffer overflows and memory leaks.
There are many examples of such OSs, unfortunately they didn't get any major impact on our daily lives.
Maybe singularity will change that.
Why should I say goodbye to modern computing?
As an example, there are OS implemented in Modula-3 and Ada. They are quite fast, and the languages are not "like C", though they do the job and there aren't buffer overflows to worry about.
Maybe getting rid of C is what we need to finally embrace modern computing?
Ah, another pontificating buffoon who has never used or seen smalltalk.
Hot flash from the newsroom, genius - ObjectiveC is an extension of C. If you want to use the features of C or call regular C code, you can. Indeed, for some features, such as CALayers, that is the only way to do it.
Now, if you are more comfortable with C++, keep programming in it. Skip the iPhone development a stick to Windows.
Freaking language snobs. Right tool for the job. I use C, Java, ObjectiveC and even a bit of various scripting languages daily. Get over yourself, honestly.
Never by hatred has hatred been appeased, only by kindness - the Buddha
The SDK *says* it requires an Intel Mac, but my wife found instructions on the net and just last night we compiled and ran from XCode on her G4 to her iPhone.
She had been excited that we had an excuse to upgrade from her G4, but it turns out iPhone development doesn't require us to upgrade.
In general I agree with your assessment, but it's a little better on a Mac instead of a phone. They've added garbage collection, for example, and dispatch caching is a pretty nice optimization if you've got the RAM, used in various other decently-performing dynamic languages.
Also, it's got a feature shared with Smalltalk and Ruby, that you can build a generic handler for all messages you haven't otherwise built a handler for. This is a pretty nifty feature for building DSLs.
This is the language that thinks it's a good idea to redefine boolean to be YES and NO.
You do realize that Objective-C was designed before C had a boolean type, right? (C didn't have a standardized boolean type until C99, but Objective-C has been around since the mid-80s.) So they weren't redefining anything. Everyone else at that time was just using a char or int and had a "#define TRUE 1" at the top of their programs...
-- Tim Buchheim