Monday, December 31, 2012

Titanium First Look and Calculator

Appcelerator's Titanium Studio (Titanium) is an interesting mobile development environment. Writing code in it isn't like anything else I've coded in it. This isn't necessarily bad, but it does take some getting used to. This post will be a multi-part review and tutorial. My goal is to learn the system by writing a calculator app. I am working with version 3.0 of Titanium. If you have read any of my previous posts, you may know that I have written a calculator app in jQuery Mobile for mobile websites and then easily ported it to PhoneGap for both iOS and Android. The question is how hard is it to build the calculator in Titanium.

This isn't a getting started tutorial. Titanium already has excellent tutorials to do that on their site. Instead, it is an exploration. If you need a tutorial check out the ones on Titanium's site at: Quick Start.


What is Titanium?
A lot of people have the incorrect assumption that Titanium is the same thing as PhoneGap, it is not. Yes, they both make it possible to write cross platform  mobile code in JavaScript for iOS and Android, but that is about all that they have in common. I like PhoneGap, it is essentially mobile web development moved onto mobile devices. Everything familiar to web developers is there, including the dreaded DOM. 

Instead Titanium wraps native UI in JavaScript calls. This enables skilled Titanium programmers to creates apps which are indistinguishable from native ones. This is very different from PhoneGap. At best PhoneGap enables the you to create programs which fake the appearance of native apps, but lack their speed.

In order to build iOS code, you will need an Intel Mac, the same basic requirement that traditional iOS programming requires. Both PhoneGap and Icenium now make it possible to bypass the Mac requirement, but Titanium does not. But this isn't all bad. Just like traditional iOS, you can pick your deployment target. It can be a provisioned iPhone or iPad or their simulator.

User Interface
Titanium is something different. First off, there is no DOM. That's right the worst API ever designed, the Document Model Object, doesn't exist in Titanium. While that should be good news, it does create a problem. How do you create UI? Unfortunately it is via code, which quite frankly sucks. I've been coding a long time, I remember the early days of UI programming, how fun it was to code out each and every UI element. Then I remember what is was like when NextStep arrived. It had the Interface Builder, it wrote the UI code for you, brillant. And while HTML/CSS isn't the ideal UI creation combo, it is leaps and bounds above building UI in code. Plus, it has the additional advantage of being well documented.

Now, in all fairness, I can see references in the documentation and website to something called, Alloy. And it appears that Alloy builds UI with XML, like Android or Windows Phone. I will check it out in a later post. But if Appcelerator really wants to make Titanium world class, it has to make a UI builder for it. 

Debugging
One of the worst parts of PhoneGap is debugging. No matter how good your code is, eventually you will need to debug it and nothing beats being able to set good old fashion breakpoints. PhoneGap doesn't really have a debugger. Wait - before people flood the comments - I know that there are ways to do debugging in PhoneGap. But none of them are optimal, none. Being able to stop the code at any arbitrary point and examine the environment - is a great help and a necessary part of development.

With Titanium you have it. I can set a breakpoint and run the code on either an Android or iOS device, emulator, or simulator. Being able to set a breakpoint is a real boon and helped me several issues already, especially since I refused to RTFM.

The Calculator
I began building the application by selecting the Single Window Application template. This template creates several versions of ApplicationWindow.js. Titanium doesn't try to create one code base for all systems. Instead it gives the developer a way to share a great deal of code between environments, but not all of the code. Each version of ApplicationWindow is tailored for a different platform. It also creates a view, FirstView. Think of windows as HTML pages and views as divs. 

I renamed FirstView to KeyPad. All of the View code, this time view as MVC, goes in it. Titanium's support of CommonJS Modules makes it very easy to implement separation of concerns. The is no global space like traditional DOM programming. All of the communication between modules has to be planned.

My plan for the calculator is that KeyPad will be the view. App the controller. And a still unwritten module named Logic will be the model. Communication between the different modules will be mainly via events. And here is where I finally needed to RTFM. 

In DOM programming to do communication between modules I would normally fire a custom event off of the Document, but there is no document in Titanium. I didn't want to do it off of the KeyPad, since the model should have no knowledge of the KeyPad. Finally, I found that you can fire events off via Ti.UI.fireEvents/addEventListener. I coded this up and tried it out. It worked under iOS, but not Android. I read the documents over and over but there wasn't any information about why this doesn't work under Android. Finally I googled it. Seems I'm not the only one who has encountered this issue. The solution is to use Ti.App.fireEvent/addEventListener instead. No explanation given as to why. This is part of the reason why I don't like to google things, I want to why not just how.

So far I have the code working in the KeyPad firing events. And some temporary code in app.js receiving them. Most of the time spent so far has been in hand coding the UI. It sucks but at least things work better than in DOM programming. I decided to use percentages for the buttons. In DOM programming width percents work correctly but height only works if you hard code the height of the parent container. In Titanium height percents work is exactly as you would think they should intuitively. This makes it a lot easier to code UI to be flexible based on its environment.

Summary
So far I like Titanium. It was a lot easier to get the environment up and running than PhoneGap. Plus I like being able to build for Android or iPhone in the same environment. I haven't finished the calculator yet, but I will. The complete source code is on GitHub at: Titanium Calculator. Please check it out. I will finish it sometime in January 2013 and let everyone in a future post. 

Here is the link to second part of this post: Titanium Second Look.

Here is the KeyPad as it exist now:

Sunday, December 30, 2012

5 Quick JavaScript Improvement Tips

Here are the slides from a presentation I gave earlier this year, some quick and easy ways to speed up your JavaScript code. 

Saturday, December 29, 2012

Octane JavaScript Benchmark Scores

Apple iPhone 5
Nokia 920
Google Nexus 4
In my last post, I showed HTML5 and CSS3 test scores for three super phones. Modern web apps consist of three parts: content, presentation, and behavior. HTML5 is the content. CSS3 is the presentation and JavaScript, the final leg of this tripod, is the behavior. The iPhone 5 and Nexus 4 are essentially tied in their implementations of HTML5 and CSS3, with the Nokia 920 hot on their tails. But what happens when we throw JavaScript performance into the mix?

Benchmarks can be problematic. They normally chose to narrow of a focus, which allows them to be exploited. More than one manufacturer has modified their code to exploit weaknesses in a benchmark and make themselves appear faster. Octane is Google's new JavaScript benchmark. Unlike others, it runs a suite of tests which mimic the behavior of real world modern websites. If you would like to know more about Octane, here is the link: Chromium Blog About Octane. If you would like to run the benchmark yourself, go here: Octane.

Here are the Octane scores for the super phones. Please take these score with a grain of salt. 


  • Apple iPhone 5 -  1403
  • Google Nexus 4 -  1267
  • Nokia 920      -   601 
  • Chrome 23 (OSX)- 12410


It isn't surprising to see the iPhone 5 leading the pack here. Apple spends a lot of time and resources keeping their JavaScript engine top-notch. The Nexus 4 is 10% slower, which is a bit surprising since desktop Chrome is so fast. But the total surprise is how far behind the Nokia is. Now it is entirely possible that I didn't execute the benchmark correctly. The other two phones, I own and know how to work. The 920 was borrowed and their may have been apps running in the background, stealing cycles from the benchmark. But then again, JavaScript performance has always been a weak spot for Microsoft.

I wouldn't base my decision to buy or not buy any phone solely on benchmarks. I would consider how the phone fits into my lifestyle a better measure. But benchmarks are cool. If you decide to benchmark your own device, please let me know the results in the comments section.




Thursday, December 27, 2012

HTML5, CSS3 Test Redux

HTML5 and CSS3 are full of lots of sweet features. But it can be tricky to determine which features your device supports. Luckily there are sites out there which will report on the features  your device support.

To test HTML5 features, there is the  appropriately named, HTML5Test.com and for CSS3, there is the equally appropriately named, CSS3Test.com. Back in August, I ran three phones through the two tests and reported on their scores. Back then the phones were: the Apple iPhone 4, the Google Nexus One, and the Samsung Focus Flash. They represented iOS, Android, and Windows Phone 7 respectively.  If you are curious here's link to that post:


Well, I have a new crop of phones on hand, this time all flagship phones for their respective O/S. I have Apple's iPhone 5, Google's Nexus 4, and representing Windows Phone 8 (WP8), the Nokia 920. 

  • Apple iPhone 5 - HTML5 386 and  9 bonus points - CSS3 55%
  • Google Nexus 4 - HTML5 385 and 11 bonus points - CSS3 54%
  • Nokia 920      - HTML5 320 and  6 bonus points - CSS3 54% 
  • Chrome 23 (OSX)- HTML5 448 and 13 bonus points - CSS3 63%


The biggest surprise in the crop is the Nokia 920. Windows Phone 7 had very marginal support for HTML5 or CSS3. Its score was drastically lower than the iPhone 4 and even the Nexus One which came out much earlier. Well, the 920 isn't anyone's whipping boy. It ties the Nexus 4 in its CSS3 score and falls only one percentage point below the iPhone 5. In HTML5, Windows Phone 8 still lags behind the iPhone but it is only by 66 points, not 166 points of the last test. 

Vs. Desktop
Google's offering still lags behind Apple's iPhone 5, but now it is only by one point in the HTML5 test and one percentage point in the CSS3 test. For comparison, Chrome 23 running on Mac OSX Mountain Lion gets scores of 448 on the HTML5 test and 63% on the CSS, so there is still a lot of room for improvement for mobile browsers. Plus, this should serve as a caution to those of us doing mobile development and testing our apps on the desktop. Desktop browsers are still more capable than those on mobile devices, so testing on the device is still mandatory.

What about JavaScript?
JavaScript is the language of the web and there are also websites to test your device's JavaScript implementation speed and capabilities. In an upcoming post, I will reveal how well these devices do with JavaScript.

Tuesday, December 25, 2012

Introduction to Node.js Talk

My good friend Chander Dhall, has asked me to fill in for him on Monday, January 14th, in front of the Meetup group, HTML5/Node.js Los Angeles. The title of the presentation is, Introduction to Node.js. I am really excited to do this talk, as you might guess by some of my posts, I am a huge JavaScript fan. It is my favorite language and the language of the web. Using Node allows me to code in my favorite language on both sides of my web apps. 

It can be difficult, to figure out how to Node via most of the standard Hello World websites floating around on the net. In this talk, I will show how to construct a basic, but useful website and add a backend REST service to it. I will also demonstrate my workflow. How I build and test on my local box, before and pushing out to my public server. I will also provide a list of my tools, which editor, unit test framework, and Git clients I use everyday.

So if you are in the area, please come to this talk. Information and directions are on the Meetup page at: http://www.meetup.com/nodela/events/91265402/. After the talks is done, I will make my source code and slides available. Hope to see you there.

Thanks again to all who attended. It was great meeting all of you. Here is the link to the source code on GitHub.


If you attended the talk, please rate it:

Saturday, December 22, 2012

Turning Off Google+ Community Notifications


Nothing here about Community Notifications
I like the new Community feature of Google+. It is great having another cool way to keep up with developers worldwide, but I hate all the notifications. I neither need nor want an email every time a member leaves a post.  Unlike other parts of the Google+ world, there is no setting for turning on or off Community notifications in the Accounts -> Google+ section. But don't despair, the switch is hiding in plain sight. 

On Community page itself, below the community's logo and membership total, next to the Action drop down, there is a button with a bell icon. Clicking the button turns notification on and off.