Mobile Apps with Javascript

Why Apps?

Why Apps?

  1. Access to all the various App Stores

    Consumers are actually willing to pay for Apps, less so for Web Sites.

  2. Access to hardware & software features you might not otherwise

    Camera, Microphone, Telephony, Contacts, Filesystem, etc...

  3. Client demand

    Hey, you have to make a living somehow...

  4. Performance

    But this is less and less a factor as JavaScript performance increases, leading us to...

The HTML5 Singularity

Apps are an evolutionary step. We will be approaching a transition point in 2012

Says who?

Says Mozilla

(Ok, they have a vested interested)
WebAPI

What is an App?

  1. Not: Something that looks like an app

    We have plenty of web frameworks designed to recreate the "native" look and feel along with hardware accelerated transitions.

  2. Not: something that works offline

    We already have local storage and offline storage via cache manifests

  3. Not: something that you can launch from your home screen

    We already have iPhone meta tags and stuff like mobile-bookmark-bubble

  4. Somewhat: Access to native hardware

    But we saw that is changing fast...

  5. Definitely: something you can get in an App store

    This is the one defining factor for many apps.

So...

Screw everything else
(Obj-C, Java)

Let's use the tools we already know and love (HTML, CSS, and Javascript) to build stuff we can put in the app store

The Players

  1. Titanium Appcelerator

    A Javascript API for building Mobile apps

  2. PhoneGap

    A thin wrapper around a WebKit browser with native augmentation

  3. AppMobi

    PhoneGap-like augmentation + plus commercial support

  4. Impact.js

    Specialized use-case: Games. But neat idea...

Unicorns and Rainbows?

Not Quite...

Titanium and PhoneGap in Depth

From primarily an iOS perspective

Titanium: Overview

A Javascript API for writing mobile (and desktop) applications

Titanium: Overview

  1. Xcode required for iOS development, Eclipse for Android

    Handles deployment to simulators and devices for you

  2. Creates an Xcode project behind the scenes and builds automatically

    This works about as good as you expect: works great when it works, leaves you searching the forums for some archaic error message when it doesn't.

  3. Uses native components wherever possible

    Compiles down to native code. Does not use HTML/CSS styled to look like native. Stuff Splitview are native.

  4. Switched from a simple builder app to a full-blown IDE

    ...which sorta sucks. If we're developing Javascript we probably already have our tools and editors we like. And now configuration options are buried inside of hacked-on IDE (Aptana built on Eclipse)

Titanium: Coding Details

  1. Documentation and forums are a bit spotty, but the KitchenSink is great

    Look at the KicthenSink app first, probably before the Google. New features get added to the App, then documented

  2. Good support for services like Facebook & Twitter

    Better than PhoneGap (which has none and needs stuff like ChildBrowser)

  3. At the "community" level JSLint and log statements are your debuggger

    Better tools come with a not-that-cheap monthly subscription

  4. Two primary ways to develop in Titanium:

    1. Using a single global scope.
    2. Using independent scopes and message passing.

Code Break

Some notes on Coding Titanium

  1. When stuff doesn't work, press the debug and run button again

  2. When stuff continues to not work, delete the build/iphone directory

    And build again. Titanium auto populates the necessary frameworks, but sometimes when you add new code it doesn't rebuild correctly. Especially do this if you get errors for unknown API methods that are spelled correctly.

  3. You'll pine for Interface Builder pretty quickly

    Building all your stuff by hand gets boring. Can try stuff like Xib2js. People say a native titanium one is coming.
    You'll want to build up some functions for calculating your element positions (especially forms) so you don't end up with a bunch of magic numbers in you code.

  4. Mess up a function name and your app just quits

    ...without any real good feedback

  5. Options parameters are not validated

    So when something isn't working right, look to your options and use the intelliSense if necessary

  6. Factory methods are used to create everything

    But the details are always in the objects themselves

Titanium API Notes

  1. use Ti. instead of Titanium.

    Lower code noise

    Ti.UI.createButton( ... )
    Titanium.UI.createButton( ... )
    
  2. Store persistent values with Ti.App.Properties

    Ti.App.Properties.setString('APIKey','12334456');
    var val = Ti.App.Properties.getString('APIKey');
    
  3. Be careful with Ajax (and any Web) Requests

    Always make sure you have a error handler as you don't want your app stalling forever if someone goes in a tunnel.
    If you are updating a UI element - make sure it still exists by the time the request comes back as the user may have moved on.

Ti API Notes #2

  1. Sending and receiving JSON is a little tricky:

    var xhr = Ti.Network.createHTTPClient(); 
    
    xhr.onload = function(e) {
          var json = this.responseText == '' ? JSON.parse(this.responseText) : {};
          // Do stuff
    };
    xhr.onerror = function(e) {
          // Catch error, show an alert
    };
    
    xhr.open('POST','http://site.com/update_data.json');
    xhr.setRequestHeader("content-type", "application/json");
    xhr.send(JSON.stringify(data));
    
  2. Binary data is difficult to work with

    Not really Titanium's fault, but Javascript's fault. Expect to be a little far removed from the binary data for files, sounds, images, etc. and expect to have access to them be a bit slow.

PhoneGap: Overview

An native-augmented Web Browser

PhoneGap: Overview

  1. The Good: Mobile Webkit & Firefox are great browsers!

    Generally fast with great HTML5 & CSS3 Support, WebSockets. It has good looking native Audio & Video elements. Hardware accelerated CSS3 Animation support makes stuff look native.

  2. The Good: Choice of Frameworks (jQuery Mobile, Sencha, Backbone.js ...)

    You can use the tools that your are comfortable with already.

  3. The Good: Accessing native hardware is easy

    Just make sure you've waited for onDeviceReady and then follow the docs.

  4. The Bad: Debugging on device is a royal PITA

    You generally want to build and debug your main app on the Desktop (with Firebug) and then worry about mobile.

  5. The Bad: Once you step outside iPhone and Android, it's a bit Ghetto

    WP7 Support isn't great, BlackBerry, same thing

  6. The Bad: Generally native hardware is at a one-size-fits-all granular level

    And there are some weird bits as well with some callbacks not support closures, etc.

Code Break

jQuery Mobile Examples

Some notes on PhoneGap

  1. Some of the same mobile browsers limitations we've always had

    The position:fixed; + overflow:auto; issue (Fixed in iOS5)
    Lot's of workarounds exist (Scroll view using iScroll4)

  2. Many intentional browser restrictions are still there

    No video auto-play, no audio auto-play. No manual keyboard (input field only)

  3. Ajax, however, is unrestricted

    No more JSONp hacks. Can make Ajax calls to any domain and pull and push data at will (using $.ajax)

  4. Can't execute code not included in the application

    According to Apple - you shouldn't download and execute JS unless you do it in a Child Browser window. This makes things like OAuth little painful.

Which makes PhoneGap sound bad...

But it's not, just know the restrictions

AppMobi

Like PhoneGap, only not open-sourced and more polished. Includes a automated online-build process.

Impact.js

Compiled in his own JavasScriptCore (which is included by a Private library) - All Graphics use OpenGL and sound users OpenAL. Must be built using stock Impact engine code.

iOS Deployment Notes

  1. You'll need a $99/yr Developer Account

  2. Read the App Store Review Guidelines before starting a project

    Please, take the time to read them before agreeing to a client project...

  3. You'll need to add devices by UDID to your provisioning profile.

    (Find your UDID)

  4. You'll need to update and download your provisioning profiles

  5. You'll need to rebuild your app with the new profile

  6. You'll need to upload your generated IPA to something like TestFlight or Diawi

  7. They will then have to accept and install it

  8. If you are near the device, plugging it in and using it for development is much easier

Android Deployment Notes

  1. Send them the file, have them install it

Thanks! Questions?

Pascal Rettig
@cykod
Cykod (Consultancy)
GamesForLanguage (Online Language Learning)