Build native apps for iOS, Android, and Blackberry from a single JavaScript codebase with Appcelerator Titanium. This guide gets you quickly up to speed on this amazing framework and shows you how to generate cross-platform apps with 100% native controls. You’ll also learn the advantages of using Titanium when you want to create an app for just one native platform, rather than struggle with Java or Objective-C.

Fast-paced and full of examples, this book helps you build your first project with Titanium Studio, and then takes you through the steps necessary to build complex data-bound apps.

Learn how Titanium differs from frameworks such as jQuery Mobile and Sencha Touch

John Anderson

John always tells people that he feels like computers picked him, and not the other way around. While in grade school he walked into a Radio Shack, got his first look of a TRS-80 and fell in love. From that point on, computers and programming was the main focus in his life. All he could afford was the manual, so that's what he bought and started learning about programming. He has stayed with that model of learning about new technologies by getting a good book and learning about a new topic. He’s been programming computers for about 20 years now, starting as a Customer Support Rep, getting his first programming job and working his way up. When the Internet got popular, he jumped onto that as the Next Big Thing and his career built on that for over 10 years. A couple years ago when a similar phenomenon was happening in Mobile, he again took to the books and started building his own mobile apps and immersing myself in all things mobile. He has apps in Apple's App Store and the Android Marketplace, some of which were done with Titanium.

The book starts with promising platforms overview intro, but after that it became sort of reference and doesn't provide confident and deep knowledge of the subject. I think it require additional work and should provide code examples as well.

I was happy to see a title about Appcelerator Titanium. I realize this book represents a significant effort by its author and editor, but I don't think it's up to O'Reilly's high standards. Even if all of the careless typographical and stylistic errors were fixed, there are still structural problems that make it a confusing and frustrating guide to an already complex framework.

From cover to cover, here's a sampling of errors, omissions, and structural issues:

- Long-winded and off-topic pablum about hardware configurations. These might be relevant to novice computer users, but developers likely have this stuff figured out or have opinions of their own. An example:"And the importance of memory is as true as ever. Additional memory for Mac or Windows will help speed up things. I expanded my MacBook Pro with memory bought from Amazon and it worked fine. Don't think that low-cost memory is cheap or will not work." (p 15.)

- Sloppy editing. (e.g. "When you run the installer, it's a good idea not to change any of the defaults. It's a good idea not to change any of the defaults." on page 17.)

- The notion of using an object as a namespace is introduced without explanation. (app = {...}, first seen on page 21.) Some examples use it, some don't. It probably deserves a quick explanation since it's a best practice in Titanium apps. At the very least, a promise that namespaces will be discussed in chapter 7 would help the reader.

- Syntax highlighting errors in the PDF (e.g. page 37 and 38)

- The version of the Titanium SDK covered — 1.8.1 — is long over a year old. This is particularly problematic in the API reference chapter.

- Inconsistent styling in code samples. JavaScript allows a great deal of flexibility, but using arbitrary code style sets a poor example. (Example from the text include single vs. double quotes around strings, use of var when instantiating variables, semicolons, "e" vs. "evt" callback parameter names, inconsistent spacing around colons, etc.)

- More typos: "Once you have a handle on the event that fired the event, you can generally find out what you need." Presumably should read: "Once you have a handle on the object that fired the event…"

- Bizarre (il)logical thought progressions. For example, on page 49:"The TableViewRow is a very useful item. When I first started working with them, I thought they were a nice way to display data in rows, but not incredibly flexible. There are a few attributes you can set to show a left image, right image, caption, and a hasChild indicator. This will cause an indicator to be displayed on the right of the row to show there is more content, like a chevron arrow in iOS."

The "when I first started" bit of the sentence primes the reader for some kind of "and then I found out…" revelation in the next sentence or two. It never comes.

- Needless and vague editorial asides. On page 50, for example:"As you can see, the aspect ratio for the Android tablets is much "taller" than that of the iPad. I think this reflects Apple's ability to know what's best for the user and to build it even if it costs more. In the end, users appreciate the better user experience, and will pay for it. Since Android tablets and phones use more "off-the-shelf " components, the resolutions and aspect ratios might not be optimal for a great user experience."

This *might* have been worth the ink if accompanied by some discussion on measurable implications of different screen aspect ratios on UX. Also, filler clichés like "As you can see" and "In the end" aren't necessary.

- Framework conventions are introduced with zero fanfare or explanation in unrelated example code. For example, the "exitOnClose" and "layout" parameters make their debut in a picker control example in the with no explanation. (The layout parameter is briefly discussed in a later chapter, but upon first use an acnowledgement that the reader hasn't missed something and that these aspects of the API will be covered later.)

- It looks like some content intended for chapter 5 didn't make it in. A summarizing graph on page 54 claims that the reader learned "how to add things to a standard control (a TableViewRow, in this case) to create a customized look". In fact, there's no sample code or example involving TableViewRow up to this point in chapter 5.

- View parents / children and the display hierarchy are never introduced, so figuring out what the reference to .parent means on page 56 is an exercise for the reader. These are details of the Titanium API that deserve at least a paragraph for those uninitiated with the display list pattern. (View-as-container is never introduced. Maybe it could be introduced when oft-nested objects like TableViewRow are first mentioned earlier in the chapter? Or push the "Window and View Objects" section up?)

- Figure 6-9 doesn't accurately reflect the output from the example code on page 86. The window background in the figure should be white, not gray.

- The author champions fiddling with the prototype chain in the introduction to chapter 7 on page 93: "Prototypes are a very cool feature of JavaScript and should be exploited profusely." Despite this endorsement, he never offers an example of using this feature in the context of the Titanium API (or why this might be a bad idea), and instead the rest of the chapter shows how to customize Titanium objects by creating proxy objects rather than messing with prototypes. Prototyping is never mentioned again.

- The "saying" quoted on page 94 is incorrect and conveys the opposite of the intended meaning: The author quotes "If you don't know where you're going, you'll probably get there." He probably meant to cite Yogi Berra's aphorism: "If you don't know where you're going, you might not get there."

- In the example code on page 96, "TiCL.Util = {};" should probably read TiCL.Utils = {};" to follow the author's advice about mirroring the Titanium namespaces. (Indeed on the next page the author references a TiCL.Utils namespace.)

- More sloppy editing on Page 97: "…but requiring three different parameter names" should read "…but require three different parameter names."