Here we go again…

Yep, another cross-post from the Appcelerator blog. This time it shows off how I managed to implement the dynamic and unique Path menu in Titanium. From a single code base the menu is fully functional, with native performance, on both Android and iOS.

• Original blog post

Video

Yeah, yet another cross-post from the Appcelerator Developer blog. This was a fun one, though, where I got to show off some really cool features and functionality of the Titanium platform. There’s a lot covered so it’s stretched over a 3 part series. I’ve brought them all together here for your viewing pleasure. The original blog post links included with each video contain links for all the source code and references associated with each video.

Here’s the 10 second summary of each part:

1. Create a native Android module to determine a device’s physical orientation as azimuth, pitch, and roll
2. Use the above data to animate and render a 3D model using a Titanium WebView and
3. Represent this 3D model on multiple remote client devices simultaneously using high volume, realtime network communication via Titanium Sockets

Part 1 – Native Android Module

>>> Original blog post

Part 2 – 3D With Three.js

>>> Original blog post

Part 3 – Sockets

>>> Original blog post

I don’t cross post often from the developer blog over at Appcelerator, but people seem to be liking this screencast so I thought I’d share. I put together some code and a video showing off how you can you use cross platform design, modular Javascript, and of course, Titanium to deliver a simplified interface for creating forms in your mobile apps. Aside from it being easy for developers to implement, there’s also a special focus on making the forms as easy to navigate as possible for the end user.

I’ve tried not to overpopulate this blog with Appcelerator content ever since joining them as a platform evangelist. I think I’ve earned an Appcelerator post though after talking exclusively about PhoneGap and Adobe in my last one though.

Additional Resources

• Forging Titanium Episode 1: CommonJS Modules

Link To Full Blog Post

• Android Intent Filters on the Appcelerator Developer Blog

It Starts…

Here’s just a cross post of my first tutorial on the Appcelerator Developer Blog. It details how you can use Android Intent Filters to make your Appcelerator apps receive Intents from other Android applications. For example, I’m sure if you are an Android user you are familiar with the SEND Intent list:

With this blog post I’ll show you how you can add your app to that list. It’s a great example of how Appcelerator still leverages powerful native functionality, both visual and non-visual, while it provides a cross platform solution.

CORE

For the sake of not repeating myself I’m going to refer to the phrase “code once, run everywhere” as CORE from here on in. Who knows, maybe it’ll catch on. And on to the blog post…

So as you may have heard by now, I’ll be starting my new job as an Appcelerator platform evangelist on Monday. If you’ve read some of my past blog posts, you’ve probably noted that I’ve been pretty critical of cross platform mobile solutions. From a developer’s perspective, we are expecting the coveted CORE, but are often left wanting.

What you’ll quickly find in the world of mobile development is that cross platform does not always equal CORE.

Rather than bemoan the shortcomings of each mobile framework, I’d rather talk about something I heard say during the Appcelerator online training videos. He stated that Appcelerator does not aim to be a CORE technology, but instead a “code once, adapt everywhere” one. Not quite as sexy, but perhaps an even more intriguing philosophy. Let’s discuss why.

Web Based vs. Appcelerator

For a quick summary of how Appcelerator is fundamentally different than web-based cross platform mobile frameworks, read here.

Aside from near-native performance, what’s the biggest advantage of using Appcelerator over web based mobile frameworks like Phonegap or Rhomobile? Its ability to use the device’s native UI components. And no, I don’t mean it has UI components skinned to look like native components, like many of the web-based solutions. I mean it actually uses the platform’s native, performant UI in the app.

With native UI we can build apps that are indistinguishable from apps built with Objective-C or Java. The look, feel, performance, and behavior will be exactly what is expected of the given platform. Plus, we don’t have to build them ourselves.

To achieve this level of quality, though, you need to be willing to adapt your app, not just design for the lowest common denominator, as is often the mentality with CORE apps. Sure, you can use the iPhone’s slick Navigation Controller bar on all versions of your app, but is that what Android users are expecting? Nor would an Android Spinner be befitting of an iPhone app.

You see, in some cases, CORE apps come at the expense of the most important factor: the user experience.

Why Bother?

Many people, particularly proponents of web based mobile development, are of the opinion that native UI components are not necessary to deliver a high quality user experience. I agree, in certain circumstances. Games, novelty utilities (think Flashlight), and otherwise simple apps are good examples that probably don’t benefit much from a native experience.

In my opinion, though, it’s a necessity for more complex apps, particularly ones leveraging native APIs, to use the UI that is familiar to the device. They need to work in a simple, intuitive manner as mobile users can be quick on the trigger in deeming an app unfriendly. Those who have spent time developing for multiple platforms understand that the users of each platform have different expectations.

I don’t want a navigation bar in my Android app. I want my tabs at the bottom on iPhone, the top on Android. I want to press my menu button on Android to get my app’s options. I want my system buttons to look familiar. I want to pull to refresh on my iPhone.

Let me be clear that both Appcelerator and web-based frameworks have the ability to adapt their apps to supported platforms. And I don’t just mean churning out a basic app, I mean creating a high quality, native app. Depending on your point of view, however, one may be much more appealing than the other.

Attending to the UI (Web-based)

With web-based solutions, the app exists in a web view container. This means that you are effectively building a native app that consists of only a web view which hosts a web application. You have no native components with which to work. This leaves us with 2 options for building the UI of the app (super quick assessment coming):

1. Use a 3rd party framework like jQuery Mobile or Sencha Touch
   • Pros
     • Lots of functionality and UI components
     • Speeds up development process
     • Some, like Sencha Touch, have a very native look to their components.
   • Cons
     • Web based framework UI is generally less responsive than ones created natively or with Appcelerator on mobile devices.
     • Additional learning curve for the added framework
     • You are even further removed from the native app. You now have a UI framework which sits on a native web view wrapper which then becomes a native app. Lots to know and lots of places for things to go wrong.
     • Frameworks like Sencha Touch are limited to webkit based web views (iOS, Android, BB 6.0+). This essentially removes the biggest advantage of web based frameworks, which is their compatibility.
2. Create the UI yourself with HTML/CSS/JS
   • Pros
     • Totally customizable for any platform
     • Its easier to manage performance and UI inconsistencies when using code for only what you need to achieve
     • No additional learning curve beyond basic web dev and understanding your web based framework of choice.
   • Cons
     • Much slower to develop, as you have to build your UI from scratch. The styling of the UI to look native all falls on you or external resources you can find.
     • Even for seasoned web devs, managing cross platform mobile CSS can be a daunting task.
     • All cross browser inconsistencies become your job to address, unless you use a light JS framework like xuijs or zeptojs.

So as you can see, web based mobile development encounters many of the same issues that traditional web development does. And the problem is compounded when you are trying to make these web based solutions look, feel, perform, and behave natively.

Attending to the UI (Appcelerator)

Appcelerator apps are built differently. The extremely short version is that Appcelerator Javascript code is mapped to native symbols of the target platform. Any code that can’t be mapped to a native symbol is run through a Javascript interpreter. , CEO of Appcelerator, does a much better job of explaining it in this StackOverflow post.

What this means that there are no 3rd party tools or special code necessary to create totally native components. You want a button that has native appearance and behavior on both iPhone and Android?

var button = Ti.UI.createButton({title:'test button'});

There you go, an Android and iPhone button respectively. How ’bout a table view populated with sample data?

var data = [{title:"Row 1"},{title:"Row 2"},{title:"Row 3"},{title:"Row 4"},{title:"Row 5"},{title:"Row 6"}];
var table = Titanium.UI.createTableView({data:data});

Yep, it’s that simple. The iPhone table will even have the bounce scrolling users expect. You have the same simplicity that web based UI frameworks solutions provide, except you are additionally getting native look, feel, performance, and behavior. The components are even designable as you would expect them to be.

The one drawback to this simplicity is that without careful attention to your code, you can end up with a mess of interlacing UI and logic. Android has XML for layout, iOS has .nib/.xib files, web based solutions have HTML/CSS. Appcelerator, for the time being, relies solely on your Javascript code. Javascript MVC frameworks, like PureMVC, and attention to best practices (as mentioned in the online training videos) can mitigate this risk. There are even some vague rumblings of a more declarative syntax for UI design in the future…

Adaptation

So now that we know how UIs are built in both Appcelerator and web-based frameworks, how do we adapt them in such a way to deliver a native user experience? Despite the differences between the frameworks mentioned so far, the solution is fairly common among all frameworks.

While I will confidently say that Appcelerator has the abstraction that delivers the most familiar and device-specific experience, it too needs to account for usability that is not necessarily CORE. And even saying it is not CORE can be a bit of a misnomer as the same code base can be used by multiple platforms. It just requires the clever and judicious insertion of platform specific code facilitated by your mobile framework’s device identification APIs.

Let’s take a quick look at how Appcelerator identifies your device and can act on the information:

var osname = Titanium.Platform.osname;
if (osname == 'android') {
    // android specific code
} else if (osname == 'iphone') {
    // iphone specific code
} else if (osname == 'ipad') {
    // ipad specific code
}

For a more in depth example of how you can use this logic to create truly cross platform components and functionality, check out the 6 minute screencast “Forging Titanium: A Cross-Platform Navigation Controller.” Or just watch this:

And for reference, let’s look at PhoneGap’s adaptation method as well, just to show the similarities:

var platform = device.platform;
if platform == 'Android') {
    // android specific code
} else if platform == 'iPhone') {
    // iphone specific code
} else if platform == 'BlackBerry') {
    // blackberry specific code
}

Very similar indeed, but you need to consider the 2 prior “Attending to the UI” sections before calling them equal. Its the frequency with which you are required to apply this and other types of adaptation that affects the maintainability of your app as it grows.

Minimizing Adaptation

It doesn’t take an expert software engineer to see that conditional checks on the device’s platform throughout your code isn’t ideal. It gets harder to maintain the more conditionals you include. It becomes apparent that we need our development framework to do most of this work for us.

In the case of Appcelerator, the need for conditional adaptation is minimized by the fact that you can utilize native UI components. Look back at our examples of the buttons and table views. There was no conditional code, no special handling. You get system specific components with no extra effort.

You really only need conditional code when you want to leverage native components that don’t have an equivalent on your other target platforms. For example, if you haven’t already, check out the Cross-Platform Navigation Controller video above. It shows how you can use these conditionals to create navigation code that you can use seamlessly between iOS or Android.

Web based platforms also do a great job of creating an abstraction so that you don’t need to use conditionals for each supported platform. The problem, as discussed earlier, is that these abstractions don’t represent actual native components. They most often represent HTML/CSS/JS that are attempting to mimic native components. Worse yet, sometimes they are components that have no relation to existing native components, yet find themselves in native apps. As I said, this is a point of contention among mobile developers, and I’ll leave further discussion for the comments if necessary.

What web based frameworks can’t give you in native components, they provide in CSS, often applied dynamically via Javascript. The use of CSS is a double-edged sword. On one hand, you have a method of styling that not only allows you to skin your whole app, but also affords you the opportunity to gracefully degrade the styling based on the user’s device. This is why web based solutions typically support more platforms than ones like Appcelerator. Add all the bells and whistles like rounded corners, drop shadows, webkit transitions, etc… and if the device doesn’t support them, they will disappear without interrupting the user experience.

On the other hand, unless you are a CSS wizard with existing knowledge of CSS3 and how it applies to mobile, using it can be difficult. You can find yourself with mountains of CSS attempting to mimic components that are created with a single line of code in Appcelerator. For example, here’s a shiny iPhone button in pure CSS:

input[type=button] {
  font-family: "Helvetica Neue", Helvetica, sans-serif;
  font-size: 1.3em;
  font-weight: bold;
  width: 97%;
  height: 50px;
  border: 3px solid #282726;
  background: -webkit-gradient( linear, left top, left bottom, from(#e2e2e2), to(#8c8a88), color-stop(0.5, #acadae), color-stop(0.5, #82807e) );
  margin: 0 0 3px 0;
  text-shadow: 0px 1px 0 #cecece;
  -webkit-background-origin: padding-box;
  -webkit-background-clip: border-box;
  -webkit-border-radius: 8px;
}
 
input[type=button]:hover, input[type=button].cancel,
input[type=button]:active, input[type=button].cancel:active {
  color: #fff;
  text-shadow: none;
}
 
input[type=button]:hover, input[type=button].cancel:hover {
  background: -webkit-gradient( linear, left top, left bottom, from(#aaaee5), to(#10006d), color-stop(0.5, #1F3B97), color-stop(0.5, #081f6f) );
}
 
input[type=button].cancel {
  background: -webkit-gradient( linear, left top, left bottom, from(#5c5c5b), to(#1e1b16), color-stop(0.2, #1e1b16) );
  margin-top: 6px;
}

It does the job, but man, it is really cumbersome. Again, this is all a factor of wanting to create a native experience. Some will contest that it does not need to be this complex, that as long as the UI is uniform it does not need to conform to the native expectations. This mentality, though, is typically only held by those who back mobile frameworks that are incapable of delivering that native experience. As the local radio sports caster in Pittsburgh likes to say, “Not hatin’, just sayin’.”

Summary

You can’t beat web based mobile development for platform compatibility. Every mobile device has a browser that supports HTML/CSS/JS, right? You can create UIs that work on many platforms and degrade gracefully to handle lower end devices. Quality, usable apps are totally possible with these frameworks.

But the user doesn’t care how compatible your app is. They just want it to work, as they expect it to, on the device of their choice. In this respect, Appcelerator is unparalleled in the realm of cross platform solutions.

I have a strong suspicion that web based mobile technologies are only going to get better. I mean, let’s face it, the web isn’t going to be disappearing anytime soon. It will get faster, more functional, and closer to the expectations of the mobile user, just like desktop web browsers. And I, as a soon-to-be Appcelerator employee, welcome this.

As web based mobile development ups it game, so shall Appcelerator. Whether you’re an Appcelerator, web based, or native developer, it’s an exciting time… no matter what side of the fence you’re on.

Knuckle Head, Take 2

Here’s a sneak peek at the soon-to-be-released iPhone version of my MMA fighter app Knuckle Head, built with Appcelerator. I chose to do the native Android version first, as it allowed me to iterate through versions very quickly, making changes as users gave me feedback. Now I can apply that feedback without having to go through Apple’s much slower approval process with each iteration.

There were 3 main drivers behind this port:

• The Android version has been rated really well so far, and I’ve had requests for an iPhone version.
• I will be joining the Appcelerator team in a week and a half, so this seemed like a great way to sharpen my skills with it.
• I was just curious how the download and ad fill rate numbers would stack up against each other with a niche app like this one on Android and iPhone.

Also, there’s a chance I will open source this and put it all up on Github once it’s approved for the Apple App Store. If there’s any interest let me know. If not, I’ll probably turn out some blog articles based on things I learned doing this port. The short version is that Appcelerator definitely has its quirks, but is in all likelihood going to be your fastest route to a quality iPhone app. I went from zero to complete port in about 20 hours of work.

And that doesn’t even get into the cross platform potential. Expect a lot of content going forward on how you can turn the “potential” of cross platform code into “actual” cross platform code using Appcelerator.

Knuckle Head for iPhone video

So here it is, in all its water-marked, sub par quality glory. You’ll have to forgive those issues, I’m currently evaluating ScreenFlow. Seems like a good tool so far, but I don’t like shelling out $99 for software without playing around with it a little bit.

2 Days in the Valley

Yes, the developer/blogger with no allegiance to any mobile platform has finally found a home. I spent 2 days in Silicon Valley at Appcelerator HQ meeting the crew and getting to know more about them. In that time I had the pleasure of speaking with , , , , , and . Needless to say, I was VERY impressed by them as individuals and as a team.

As it turns out, although I’ve been very critical as of late regarding Appcelerator, they respected the concerns I brought forth. They actually seemed to view them as a blessing in disguise. For every loudmouth like me there’s 100 who make no mention of their issues with the platform.

Major efforts are currently underway to make Appcelerator even more developer friendly. If you have not heard yet, as of the 1.2.0 release of Titanium Studio, integrated mobile debugging is now free. As you might have guessed, this was a big talking point between me and the Appcelerator guys in light of the less than complimentary post I wrote regarding their initial charging for it, which has since been ammended.

In addition to free debugging, Appcelerator has made a copious amount of training videos free for developers. As a compliment to their existing API documentation, wiki, and Q&A section, these videos are more than just a quick start. They deal in depth with coding conventions and best practices for developing high quality Appcelerator apps.

So where do I fit in? I will be in the role of a Platform Evangelist. Yeah, I know, sell out. But hey, at some point you need to pick a horse and commit. And in the advent of the incredible popularity of DOM-less Javascript (see Node.js) and mobile development, it only made sense to pick the platform that is championing both. Plus, with the brief look I got under the hood of Appcelerator’s operations, I see nothing but exciting things coming, things I would love to be part of.

Things to Come

What does this mean for the content of my blog? Not sure yet, but don’t count on it turning into Appcelerator-only love-fest. There’s just too many other things I’m interested in. Obviously much of my work will be geared towards Appcelerator and showing off what it can do. In doing so, though, I’ll fortunately have plenty of opportunities to demonstrate native Android and iOS code, code that can then be turned into Appcelerator modules. Yes, it is a very interesting time indeed.

Stay tuned…

Update 7/29/2011

Searching for the Silver Bullet

So if you haven’t already figured it out, I’m gunning to decide once and for all on a cross platform mobile development framework. While all the Flash gurus I know are singing the praises of the latest versions of Adobe’s mobile platform, I don’t have the patience for an official release and docs to surface. That leaves me with two options among the frameworks I’ve evaluated: PhoneGap and Appcelerator.

If you are interested in my past evaluations, check out these prior posts I wrote:

• A Deeper Look at Appcelerator and PhoneGap
• PhoneGap is Web-based. Appcelerator is Pure Javascript
• Appcelerator vs. PhoneGap vs. Adobe Air

Now judging by those past comparisons, it’s pretty clear that each framework has its place. It doesn’t have to be one or the other. Or does it?

I’m Only One Man

There comes a time after evaluating platforms, tools, and anything else when you have to make a decision. Especially is you are an indie developer like myself. You can end up diluting your potential impact on your target field by trying to be a jack of all trades, master of none. It turns out its a lot more effective to be a jack of all trades, master of at least one.

So I keep circling back to “Appcelerator or PhoneGap?” I’ve done the technical comparison and neither is the wrong choice in any respect. Both have incredibly intelligent people spearheading their development, great productivity tools, and continuous updates and improvements to their framework. So what does it come down to?

• Which one do I spend the most time in?
• Which one do I start pouring my effort into?
• Which one do I start contributing back to?
• Which one do I think is looking out for me, the indie developer?
• Which one, if it went belly up today, could I continue to use and bend to my needs?

As I asked these questions of myself, I found that I was leaning towards PhoneGap. I will say, though, that this is in no small part to how strong the PhoneGap crew’s Twitter presence is. Here’s a list of PhoneGap people to know. I am a Twitter junkie () and being able to ask questions and get near-immediate responses definitely swayed my thinking. They do, in general, with their MIT/BSD license and github’ed everything seem like they side with the developers more than their competitor in this case.

But damn are the native UI components and pure Javascript interface of Appcelerator sexy. I’m not a web developer by trade, so the pure JS appeals to me more than needing to know the finer points of the HTML/CSS/JS stack. And the tools they have are top notch. But that’s where my decision started to be made…

Making My Decision Easy

I just needed a definitive nudge in either direction really. Something the resonated with me and said, “This is the framework you should be using.” Appcelerator gave me that nudge, but not in their direction.

I just received an email from Appcelerator touting their new official release of their Titanium Studio. Its a great piece of software that allows you to create an Appcelerator project and deploy it to multiple mobile platforms. Sounds great, right? I thought so too, until I read on.

Upgrade to Titanium Indie or Titanium Professional to get a full mobile debugger.

Just for reference, that means $49/month for the Indie subscription and $199/developer/month for the Professional subscription. So at its cheapest rate, I’ll be expected to pay almost $600 a year just to debug my mobile applications. That is not something I’m willing to pay.

On the other hand, PhoneGap is currently working with the author of , , to incorporate it into the PhoneGap project. Yes, that’s right, they are working to integrate mobile debugging into their framework for free. Pretty clear to see what an OSS supporter like myself is going to like.

Cheap Bastard

I know what you might be thinking, “Damn, he’s a cheap bastard who isn’t willing to shell out cash for decent software.” Well, yeah, and I’ll bet a lot of my readers are pretty much the same way. But it goes beyond that. It feels a bit like a bait and switch.

They offered Titanium Developer as a means to developer Appcelerator projects in the past. Then they tell everyone that Titanium Studio is the future, so that’s what you need to be developing in if you want to stay on the roadmap. Then they effectively pull the plug on Titanium Developer, make Titanium Studio an official release, then start charging for what I consider to be basic IDE functionality. Seems a little uncool.

EDIT: Kevin and Scott (see comments) are right. This wasn’t a “bait and switch”. Titanium Developer did not have this functionality, therefore it is not deceptive that the official release of Titanium Studio does not either. I will miss it, but it was not at all deceptive.

Soooo…

As you might imagine, my personal cross platform efforts will be using PhoneGap. That’s not to say I won’t be involved in Appcelerator development. I still think its a great way to develop iOS based apps when you or your team is lacking in Objective C and/or XCode experience. Its fast, effective, and Appcelerator nailed the iOS platform. They just rubbed me the wrong way at a critical time in my decision making process. I encourage anyone reading this to not let my assessment make your decision for you as I think Appcelerator is a good fit for many.

PhoneGap is the answer to almost all the questions I posed in my list above. I just really like the team and the open nature of the project. Plus, it lets me sharpen my web developer chops (Appcelerator dev is not web dev) while working in my primary focus of mobile development. It’s just a very good fit for me and the guys I work with on a regular basis.

In the End

Its all up to an educated choice that plays to your personal strengths and proclivities. In this case, both frameworks kinda did. But due to an intense focus on community from PhoneGap, they are going to continue to win over developers like me. Who knows, though, I’m a cheap bastard. Maybe there’s no money in catering to developers like me.

While everyone needs to pay the mortgage, I somehow get the impression that the PhoneGap crew will be OK with it if they all aren’t millionaires. They strike me as guys who strive to maintain a resonance with developers. In in that effort, I say they have excelled.

What’s The Difference?

I’ve seen a lot of confusion out there on what the actual distinction is between PhoneGap and Appcelerator Titanium in terms of programming. Both state that they provide cross-platform mobile development frameworks driven by a Javascript core.  How different can they be?  Turns out, very.

The fundamental difference is that PhoneGap is a web based solution where Appcelerator Titanium is a pure Javascript API that creates native code.  As I’ve gone over the differences between these 2 in detail before, I’m going to very strictly stick to the topic of how their code works. Since people seem to love charts so much, here’s a quick review to show the divergence between the two frameworks:

	PhoneGap	Appcelerator Titanium	Notes
Javascript API			PhoneGap’s API interacts as typical JS does in your web code. Appcelerator Titanium API is NOT web code, it is used to interact with native code.
Supports HTML5/CSS3			PhoneGap is a web app that runs in a native web browser view.
Supports Web Standards			PhoneGap looks, feels, and develops like a standard web page. It is also subject to the same browser compatibility concerns.
Supports DOM based JS libraries			JS libraries that reference the DOM, like jQuery, Prototype, or any of the new based libs will only work with Appcelerator Titanium webviews
Native Code			Appcelerator Titanium creates a truly native app via a JS API that maps to native code.
Native UI/Performance			Appcelerator Titanium performance is limited only by the device. PhoneGap’s is limited by the device’s web view.

What Does This Mean?

• Web developers will have a much easier transition going to PhoneGap than they would Appcelerator Titanium.
• Application developers without serious web development chops will likely gravitate towards Appcelerator Titanium. Why learn HTML, CSS, and Javascript when you can just learn Javascript?
• Designer work will be tougher to integrate into an Appcelerator project as all the layouts and assets are done programmatically. PhoneGap, on the other hand is effectively web development, which designers have been working with for a very long time.
• Appcelerator is always going to win on performance.
• There will be an inevitable flood of web developers calling themselves mobile developers because they are familiar with PhoneGap. Beware.
• Appcelerator has a much deeper and more complex integration with each mobile platform.
  • Pros: Native look, feel, and performance
  • Cons: Platform compatibility will be achieved more slowly. Much harder to “code once, deploy everywhere”.

Summary

The above is a hyper-condensed review of the whole story. As always, I encourage you to try both of these platforms. They both excel in many areas and offer unique features. Neither is the wrong choice, but depending on your scenario, one might be better suited than the other.

Overview

I’d like to start by saying that I think it’s important that both of these frameworks exist.  The more I worked with each, the more I found that it wasn’t a simple question of which mobile framework was better.  Both have some of the features a cross platform framework should have, and each shines in areas that the other frankly does not.  And that will be the focus of this analysis.  What are the key aspects to a great cross platform mobile framework, and how do Appcelerator and PhoneGap stack up.

Cross Platform Support

So this is why we’re all here right? Code once, run every where.  That’s what we want.  Well in this case, one of these solutions gets you a lot closer than the other.

This is PhoneGap’s bread and butter.  By leveraging web views native to the mobile devices, PhoneGap allows you to build as an app as complex and modern as you want while providing the ability to have it gracefully degrade for lower end devices, all in the same code base.  This degradation can be controlled via CSS or even dynamically with javascript and media queries.  You can use the same design and development principles that have guided cross browser development for years.  And the list of mobile platforms they support (which includes iOS, Android, Blackberry, webOS, and Symbian)  is definitely worth bragging about.

Appcelerator, on the other hand, does iOS really, really well.  Android brings some additional headaches and quirks.  Blackberry is still in the beta stage.  They are actually creating native code based on their Javascript API, so the quirks will likely always exist. Appcelerator will constantly be one step behind/removed in their efforts to integrate native functionality.  No fault of their own, it’s just the nature of their product.

This is why I think emphasis on Appcelerator being a cross platform framework is misleading.  While it CAN be a cross platform framework, it is not by nature.  I mean, how can it be? One of its main selling points is access to native UI components, something that is obviously not part of a cross platform solution.  One code base for multiple mobile platforms is totally a possibility with Appcelerator, but you will likely sacrifice a lot of what makes it great (coming in the following sections) to get to that lowest common denominator.

Defined Workflow

The product will only be as good as the tools that support, particularly when you are trying to appeal to an audience as large as mobile developers.  In this respect, Appcelerator is the clear winner.

Earlier this year Appcelerator announced that they had acquired the web development IDE Aptana. Before this point you were stuck with Titanium Developer which did the job, but was only a project deployment tool, not a true IDE.  Just this month they introduced the first version of the new Titanium Studio, an integration of Titanium Developer and Aptana.  There were a few bugs to wrestle with the earliest versions of this software, but I must say that I am loving it.  It has truly integrated the development and deployment workflow, making it more organized and efficient.  It has built in update checking for not only the studio but also the Titanium SDKs.  Oh, and did I mention that all of this is free?

PhoneGap leaves you to your own tools and workflow.  A plus for some, but I would imagine its a minus for those of us who don’t come from primarily a web development background.  They give you some direction in the Tools section of their website, but its not what you would call a workflow.  It a different approach, basically leaving the developer to determine what libraries, IDE, touch frameworks, etc… are most appropriate for their project.  This can be problematic for two reasons. 1, new mobile developers are not going to know which tools are the most appropriate and 2, there are A LOT of available touch and JS libraries out there for mobile development.  Choosing can be a project in its own rite. All that said, of Nitobi, the makers of PhoneGap, created the XUIJS library. Its what I’m using and I’m really digging it so far.

Programming Language

EDIT: Here’s a more recent and more detailed post explaining this section.

Admit it Appcelerator developers, you aren’t interested in the Javascript API so much as you are interested in NOT writing Objective-C!  Yeah, me too.

You would think this topic would be a deadlock, right?  Its just Appcelerator’s Javascript API versus PhoneGap’s use of the standard web stack of HTML/CSS/JS.  It basically the same thing… or is it?  Remember how I said in the last section that PhoneGap gives you free reign to choose whatever framework you want for development?  Well, Appcelerator doesn’t, and it is definitely to the chagrin of many Javascript savvy developers.

PhoneGap is HTML/CSS/JS.  Anything you can do with it on a normal web page you can do in a mobile browser’s web view.  This means any chunk of Javascript you find anywhere that you like can potentially be integrated into you app.  This ranges from your favorite frameworks like jQuery and Prototype, mobile  libraries like Sencha Touch, or even graphical ones like Grant Skinner’s EaselJS or one of these many 3D libraries.  Performance and device support permitting, you can use any Javascript you want.

Appcelerator’s API unfortunately is purely Javascript, is has no ties to the DOM.  But wait, doesn’t the most popular Javascript library in the world assume the presence of the DOM window and document?! Yep, that’s right, you can’t use any part of jQuery that requires the DOM (which is almost all of it) in your Appcelerator code.  The one exception is that you can still use jQuery and other DOM reliant libraries in a Titanium.UI.WebView, but you can’t use it with the actual Appcelerator API.  Annoying to me, but I can see this being REALLY aggravating  to long time web developers accustomed to using jQuery with everything.

Deployment Support

If you’ve spent any time in mobile development, you know that deploying your finished app to markets and app stores can be a truly daunting task.  There’s certificates, app signing, icons, logos, promotional images, supporting text, and the task of keeping it all organized.  It can quickly become a mess.  While both Appcelerator and PhoneGap both give you detailed instructions on how to build app store ready apps from your development environment and offer professional services, PhoneGap takes it one huge step further.

PhoneGap Build is currently a free beta service that you need to get your ass signed up for now.  While I highly encourage you to check it out for yourself, here’s the insanely easy workflow:

1. Upload you PhoneGap project to PhoneGap Build (or use its Github integration)
2. Configure your platform specific accounts with certificates and signing keys (all PhoneGap supported platforms available)
3. Watch as PhoneGap Build creates deployable binaries for each of these platforms and delivers you download links for each

Now that is the type of workflow I’m looking for! A quick note on step #2 is that iOS is the only platform that requires a certificate to get a testable binary.  You’ll want to set up certificates and keys before you deploy the the market/app store, but you can test the binary without them.

Speed of Development

All this flexibility and platform support has to bite PhoneGap in the ass somewhere, right?  Speed of development, if you can’t tell by it name, is another place that Appcelerator excels.

Appcelerator allows developers to start building an app that looks, feels, and performs like a native one very quickly.  Some of the big reasons are the following:

• Their Javascript API is infinitely easier than Objective-C, and some might also say Java (but not me)
• Tons of ready-to-use native UI components
• You are not required to adhere to the MVC architectural pattern
• The double-edged sword of loosely typed Javascript allows you to create custom components like table views and rows very easily
• The new Titanium Studio gives you one place to develop and build for multiple platforms

PhoneGap, though, is a bare bones framework.  It looks to provide mobile API support (things like location, accelerometer, etc…) across all major vendors.  The UI is left up to you and your chops as a web developer.  To that end most people are left to go find another touch framework to layer on top of PhoneGap.  Sencha Touch, jQuery Mobile, JQTouch are all popular options.  There’s even efforts to create web based “native” components.  You can also take my route and build most of it from scratch using XUIJS.

The long and short is that if you are only building for iOS, or maybe also Android, Appcelerator will likely get you from concept to completion faster than PhoneGap.

Documentation

Documentation is key when undertaking any new technology.  Both frameworks have their ups and downs here.

Appcelerator maintains a newly improved collection of there documentation on their new Confluence site.  While it is fairly comprehensive, it is also a bit jumbled, particularly the “Getting Started” section.  Its all there if you have the patience to find what you are looking for.  You’ll find installation, setup, examples, tutorials, the works.  You can also find a comprehensive listing of their mobile API here.  The problems I see with their documentation are the following:

• Its sometimes hard to tell what version of their SDK examples apply to
• Often Titanium objects have properties that don’t apply, or don’t behave as the documentation indicates
• You are sometimes left digging through the Q & A section to find the quirks for specific Titanium objects
• Examples given for Titanium objects are WAY too simplistic
• How ’bout a few more “Hello, World!” scale tutorials before you throw us at the ?!
• Im sure this will change after the Titanium Studio release gets some traction, but the “Getting Started” section is still using Titanium Developer as its chosen workflow

PhoneGap’s “Get Started” section is a thing of beauty.  In a very clean, concise layout, the PhoneGap site walks you through how to set up your computer for each individual platform you wish to develop for.  It list requirements, toolsets, and easy to follow instructions.  It helps ease the intimidation that can come with trying to develop for so many platforms. Once you get it up and running, PhoneGap’s API documentation is incredibly easy to follow.  A simple layout lists everything PhoneGap is capable of doing.  Clicking on these capabilities then takes you to the API specific documentation that lists usage, examples, device support, and any quirks that are currently known.  It takes a lot of the guess work and frustration out of the inevitable troubleshooting that ensues with cross platform mobile development.

PhoneGap definitely shines in the documentation department.  In all fairness, though, Appcelerator has a hell of a lot more to document.  PhoneGap’s lack of UI components accounts for a large part of its documentation being so easy to follow.

Community

An active and knowledgable community is one of my biggest factors in choosing any technology.  Appcelerator and PhoneGap both have a wiki and blog, and also offer these a few more resources.

Appcelerator has their Q & A section of their site.  It allows users to submit questions about Appcelerator to the community.  Users can submit answers, vote on others’ answers, and receive points and badges for participation.  If StackOverflow has taught us anything, its that people like being rewarded for participation, no matter how meaningless.  On top of this free resource, they also offer training, certification, and professional services for those looking to take their Appcelerator’ing to the next level.  I hand out on Twitter a lot, so its worth mentioning that you can get some great help and info regarding Appcelerator by following , , and .

PhoneGap maintains a connection with the community with their and on IRC at irc.freenode.net #phonegap.  They also offer professional services and training.  The core of the PhoneGap team is very involved with the community and I’ve often been found chatting with , , , and on Twitter.

Other than wishing PhoneGap had some kind of a forum system better than a Google group, I think both frameworks do a very good job of listening to and staying engaged in the community.

Extensibility

No developer I have ever known is just happy with the tools he’s given.  We want to be able to add to and modify anything we get our hands on.  Both frameworks are very extendable via modules and offer open source licenses, though PhoneGap’s option of “New” BSD or MIT license is a little nicer than Appcelerator’s Apache 2.0 license.

Appcelerator offers Android and iOS module development guides.  These allow you to build native components in their native SDKs and then be able to access them in your Appcelerator app via the Javascript API.  Anywhere Appcelerator falls short in terms of supporting any API or UI component, you are free to pick it up and make it happen.  Its not the simplest process and effectively removes the possibility of  cross platform code, but can be a strong tool for a single platform scenario.

UPDATE: In addition, Tony Guntharp also gave me this blog post detailing how modules can be developed in other languages as well: http://developer.appcelerator.com/blog/2011/04/tiphp-tipython.html

PhoneGap also supports additional modules, or plugins, to its framework in the same fashion that Appcelerator does.  You can develop native code and then write hooks back to PhoneGap to access it in your project.  Again, this undoes any cross platform compatibility unless you make the native component for all supported platforms.  There’s a guide to creating plugins found here.

Appcelerator on Github:
PhoneGap on Github:

Summary

So as I stated at the beginning, I think both of these frameworks are important and have their place in the mobile landscape.  From my personal perspective, as they both stand now, PhoneGap is the true cross platform solution.  , author of “Mobile Design and Development”, rang the point home throughout his book that the future of mobile development lies in web based applications that adhere to a structure of graceful degradation.  I initially thought he was a web developer who didn’t want to learn Objective-C or Java.  After spending some time with native development and multiple cross platform frameworks, I find myself coming to the same conclusion.

But that’s not to say that PhoneGap is the end all, be all of mobile development.  I happen to think that for iOS & Android projects, Appcelerator could likely be your best choice.  Unless you have prior experience with Objective-C, I would advise anyone with even a basic knowledge of Javascript to give it a shot before resorting to native development.  Trust me, you won’t miss Interface Builder, and outlets, and actions, and all kinds of other iOS MVC fun.  Oh, and you’re sure to enjoy the native UI and performance that Titanium uniquely provides.

NOTE: I would have liked to include Adobe Air as I did in this past comparison of mine, but I honestly have not used it in 2+ months and there have been serious changes since.  I’ve been focusing on cross platform solutions that can hit the big three mobile devices out there: Android, iOS, and Blackberry.  Soon as Blackberry supports Adobe Air you better believe I’m coming back to re-evaluate it.  I’ll take AS3 and/or Flex over HTML/CSS/JS any day.