Appcelerator Titanium is an open source mobile application development tool for iPhone and Android which allows you to code apps with HTML, CSS and JavaScript. I tested out the platform this morning. Having developed an iPhone application with Objective C before, I can tell you that Titanium makes the iPhone development process a whole lot easier. Getting the Android SDK working was a bit tricky but development itself is simple. I love being able to compile native applications by writing standard web code!
Here’s an example of just how easy it can be:
Code for a simple Titanium App
The Titanium app in iPhone
The Titanium app in Android
.
Getting the Andriod emulator installed correctly can be a real pain. After you have downloaded the Android SDK, open the Android SDK and AVD Manager and make sure you install all of these:
- Android SDK Tools
- SDK Platform Android 1.5, API 3
- Google APIs by Google Inc., Android API 3
In your Titanium Developer profile, set the Android API location to /Applications/android-sdk-mac_86. Also, I found the Android emulator to be frustratingly slow, but I don’t think that’s Titanium’s fault.
To create useful mobile applications I think it would be a good idea to start with the following:
I have included some screenshots of the Kitchen Sink application built in Titanium below so you can get an idea of what can be done.
Slider UI
Entering text input
Saving data on the device
Barriers to mobile app development are getting so low they are almost non-existent. As web developers today we have no excuse not be creating for mobile. We don’t need to wait for Flash CS5. The tools to create rich, responsive mobile apps for iPhone, Android and Nokia are already available with HTML5. If we have to deploy a native app there are open source tools available to convert web standards like HTML and JavaScript into native iPhone, Android, Blackberry, Palm and Nokia applications.
There are a number of advantages to developing with HTML5 instead of writing native Objective C applications for iPhone. You have probably already heard these:
- Developing with web technology is much faster than with Objective C,
- Bug fixes and updates can be deployed instantly,
- We can utilize our existing HTML, CSS & JavaScript talent.
But what you might not have realised is:
Of course there are still differences between the various mobile devices, but with a bit of tweaking the same HTML5 app can be made to run on iPhone, Android, Palm and Nokia devices because they all use the Webkit browser engine.
Sometimes we might need to generate native applications, to sell the application in Apple’s App Store for example. But even that doesn’t mean we have to resort to Objective C or Java. There is a clever open source tool called Appcelerator Titanium which deploys native applications to iPhone and Android – and we can code them in standard HTML, CSS and JavaScript. Of course deploying as native apps removes some of the benefits inherent to web apps – such as rapid deployment and development iteration. But this approach still dramatically reduces barriers to development. Phone Gap is another open source tool for deploying native mobile applications from standard web technologies. Unlike Appcelerator, Phone Gap supports Blackberry, Palm and Nokia as well as iPhone and Android. However it doesn’t offer as rich of a feature set as Appcelerator. Rhomobile offers yet another framework, but it is targeted towards Ruby developers.
So when you next have an idea for a mobile app, don’t give up on it because you don’t know Objective C or Java, or because it is too difficult to create a cross-platform app. Put your existing HTML, CSS and JavaScript skills to use and take advantage of HTML5 or an open source web-to-native compiler. I will have a play around with Appcelerator and Phone Gap and post my findings on this blog.
Comparison of mobile application development methods
| Native apps |
Web apps |
Native apps compiled from standard web code |
- Fast, best method for games
- Easily monetised
- Slow, separate development process for each platform
|
- Instant deployments of bug fixes and updates
- Can be cross-platform
- Uses web standards
- Avoid the App Store gatekeeper
|
- Easily monetised
- Easily deployed to multiple platforms
- Uses web standards
|
When you work for an agency, you need to work hard and work a lot. To help you focus you need to find ways to blow off steam and enjoy a little. We’ve found many creative ways to do that and one of them is the prankwar. The prankwar just started on it’s own between @samzzi and @coolz0r and then started to take over the whole agency … I expect many people will fall victim to our pranks. And since more people will be involved, we made a small page with an overview of what has happened so far. This way we can tell our stories to our children and their children’s children and … ok nm that 
Just go see for yourself: http://labs.thesedays.com/prankwar/
I ran into a ‘bug’ in jQuery that only occurs in IE and under specific circumstances. Actually, it’s not really a bug in jQuery… it’s more a funky “feature” of our beloved* browser: Internet Explorer. (* yeah right, muaha 
)
In jQuery you can easily get the href attribute value off of a link by doing $("mylink").attr("href"); but sometimes in IE this isn’t reliable. For example: normally, if the href value is “#myAnchor”, jQuery will return —surprise, surprise— the string: “#myAnchor”. But in some cases with IE, you’ll get the full URL path of the page you’re currently on, with the anchor string value appended to it (for example: “http://labs.thesedays.com/#myAnchor”).
This bug is specifically annoying when you use the href value in a selector in jQuery. For example, you should never do the following, because it may result in unexpected results when browsing in IE: $("a[href='#myAnchor']").click(...);
Workaround? Instead of using the href attribute, you could use the rel or xref attributes of a link, but these attributes aren’t supposed to be used for this purpose and if you disable javascript, the anchors won’t work anymore.
The jQuery devs should fix this issue ASAP, because I think that issues like these are the main reason why people use javascript libraries like jQuery: they make hacky javascript work!
For me, this proves once again that Internet Explorer totally fails at DOM management.
We didn’t only do an internal auction for Music For Life, we also made a little website where we need your help… to kill a mosquito! Check it out and raise money!
