iPhone SDK Programming, A Beginner's Guide Date: 28 April 2011, 08:06
|
iPhone SDK Programming, A Beginner's Guide By James Brannan * Publisher: McGraw-Hill Osborne Media * Number Of Pages: 512 * Publication Date: 2009-08-04 * ISBN-10 / ASIN: 0071626492 * ISBN-13 / EAN: 9780071626491 Product Description: Develop your own iPhone applications Ideal for non-Mac programmers, this introductory guide shows developers how to create applications for the world's most popular smart phone. You will learn how to use?a modified version of?the Mac development environment, the Objective-C programming language, and the Xcode development tools. Nearly every chapter of iPhone SDK Programming: A Beginner's Guide consists of a self-contained project, with the corresponding Xcode available for download and modification. The book is designed around the concept of accomplishing specific, discrete programming tasks for deployment on the iPhone. . Summary: Good Book, Great Visualization, Lack Information Rating: 4 I would like to say that this book is great. It's definitely a great book for beginners. The book teaches how to do the basic stuff such as navigation controllers, table views and simple stuff such as buttons, images, view controllers, etc. However, I noticed this book seemed to be rushed...for example, the author teaches how to make the navigation bar disappear using the viewWillAppear method but then doesn't tell you how to get it back and where to place code (PAGE 178). I found out that you must incorporate setNavigatioBarHidden:NO animated:YES to view didLoad method in the second view controller just to get the Navigation Bar back. It was frustrating to search through the net and then figure it out on your own. I recommend this book for absolute beginners, who would like to tinker but not for production. Although the author has written a decent book, I hope that the author realizes that improvements are needed such as: 1) Completing methods when they are introduced. 2) Help the reader understand why they are doing some things introduced. 3) Check the book for logical reasoning in the reader's perspective, such as the aformentioned navigationbar. 4) If a publishing company rushes the author to print an unfinished book, then the author needs to find a new publisher. Summary: Easy to Follow and Understand Rating: 5 As someone with Java and C experience, I find that the author did a good job relating Java and C to Objective-C. I enjoyed that the author provided step by step, with pictures, on how to create an application for the iPhone, and how different components work together. It is the best book to show how to implement Pickers (and I have three other books that I am using to learn how to develop for the iPhone). Thanks to the author, I was able to create a working timer picker, and at the same time understand what I was doing. Mr. DDD is expecting a literary writing, but for technical people like us, we get the concepts that the author is trying to convey. Summary: A good book for beginner and advanced user, worth buying Rating: 5 It's an attractive book with a lot of full graphics. For a new developers, this book provides all source codes for each project. For advanced users , there are probably enough tips, tricks, Thanks, Richard Summary: Not recommended Rating: 2 I feel quite sorry for anyone using this as their main, or even worse, sole, resource from which to learn iPhone development. There many small niggles with the book and some material errors. Annoyances: - the code presentation, whilst using monospaced font, uses short indentation (usually two spaces) and makes almost no use of whitespace lines to separate methods, declarations etc. Conversely, methods are written with extra inline spaces in places where there usually is none. - there is an underlying assumption that the reader will be familiar with Java, with many references such as "Java does x", or "Java doesn't do y" etc. - inconsistent use of the terms 'function' and 'method' which should really be kept quite separate at this level. [- there is no @package compiler directive in Obj-C (p47). Furthermore, even bringing in @private, @public, and @protected at the start of the book needlessly complicates things.] [NOTE: this was an error on my part, and I apologize for that. There is indeed an @package directive for 64-bit implementations. This is covered in some Apple docs, but not in others (see discussion thread below for further comments)]. - the chapter on C, whilst it would make a useful appendix if it was written well, is billed as a refresher. Some, perhaps many, people coming to iPhone programming may have some Java experience, but it's a fair bet that many do not have C experience and really need a different treatment than a C 'refresher'. - needless disquisition on C pointers etc. It would be fair to discuss the asterisk syntax in Obj-C and mention that it relates to C pointers, but the new programmer is probably well served to treat classes and objects in Cocoa/Obj-C at their face vaue as OO constructs and not bother digging too deeply into their C antecedents until they're well advanced in their studies. - there is a tendency to explain points - sometimes quite intricate points - using the same kind of language and technical wording as is made in the original point. - there is no need to go into the definition of Obj-C categories in the early part of the book - it's too much, too soon. The same point applies somewhat to discussion of dynamic binding, dynamic typing, method overloading, method overriding, inheritance (yes, they can be covered but the approach taken is really quite blunt and seems to assume a lot of background knowledge). - wordy, and ultimately very confusing, discussion of why using @property/@sythesize (more generally, accessors/mutators) helps with memory management. The underlying point is valid but the choice of when and how to tackle it seems quite misguided. In marked contrast to three other books* in the beginner category I feel this author fails to empathize with his target audience or really understand what their aims are and where their conceptual problems might lie. There is an awkwardness and distance in the treatment of the subject and a tendency to 'throw the kitchen sink' at the reader that I think could really cause some problems down the road. The really annoying stuff: - comments about MM on p9: "You can use something called autorelease, which makes memory management a little easier, but even autorelease is not recommended". Autorelease isn't about making memory management easier, per se, but even then the author goes on to use it in contrived situations, despite warning against this (see below). - using -retainCount method (p55) when it is widely understood to be of no use to the app programmer and cautioned against in the apple documentation (the author does put a note stating "there is no reason to call retainCount" but it is plainly misleading to state "I use retainCount to illustrate Objective-C memory management" - it's one of the worst ways to do this). - setting up your own autorelease pool to bypass the supposed problems with memory management (p59). To get over the "tiresome and error-prone" manual managing of reference counts the author creates an autorelease pool, puts an object into it, and then releases the pool. All this instead of simply releasing the object itself after he has used it. - in the protocols discussion (p74): "Remember, in Objective-C, you send a message and if nobody can handle the message, nothing happens." This is misleading, particularly if taken out of context. It's true that certain methods can be made optional in protocols (unlike, as we're told, with Java interfaces) so not implementing the optional methods will cause no harm. In general Obj-C terms, though, sending a message that can't be handled or forwarded will lead to a run
|
DISCLAIMER:
This site does not store iPhone SDK Programming, A Beginner's Guide on its server. We only index and link to iPhone SDK Programming, A Beginner's Guide provided by other sites. Please contact the content providers to delete iPhone SDK Programming, A Beginner's Guide if any and email us, we'll remove relevant links or contents immediately.
|
|
|