Android Enhancements

• Google Maps v2
  •  Support “userLocationButton” property
    • Allows developers to turn on/off the user location button.
  •  Support “regionchanged” event
    • Provides the delta of the latitude and longitude.
  • Support “isGooglePlayServicesAvailable”
    • Allow developers to determine if Google Play Services are available for the app
• Camera
  • Support “savePhotoToGallery” property. Previously, photos were automatically stored in the gallery. This property gives you the control to store or not store the photos.

BlackBerry Beta

This release also includes the latest version of our BlackBerry SDK beta, with integrated Studio support for creating and running BlackBerry apps.

Changes That Require Your Attention

• Android SDK 2.3.3
  • We have increased the minimum Android SDK support from 2.2 to 2.3.3.
• iOS 5.x
  • We have increased the minimum supported version of iOS from 4.3.x to 5.x.
• Change of the calendar namespace
  • If you are using the calendar in Android our namespace has changed from Titanium.Android.Calendar to Titanium.Calendar. This means that you will have to change any areas of your code referencing Titanium.Android.Calendar to Titanium.Calendar.

Downloading 3.1.1

For new users, download Titanium 3.1.1 by clicking here.

For existing Titanium Studio users, you will be prompted to update automatically on the next restart. You can also manually check for updates by selecting the “Check for Titanium SDK Updates” from the “Help” menu within Titanium Studio.

If you previously installed the Release Candidate versions of the Titanium CLI and Alloy, that is, npm install titanium@3.1.1-cr, or any -beta or -cr packages, you need to first uninstall these components before installing or updating to 3.1.1.GA. The release notes contain specific instructions on how to do so.

As always I want to thank our 470,000 strong community of developers for your constant feedback and support.

Application User Session Expiration

An application user session never expires today.  We are introducing the policy of expiring and removing sessions that have been inactive for 6 months.

How does it affect your application?  If your application logins a user and saves the session_id, normally stored in a cookie, every time it makes a REST call to ACS using the same session_id, the expiry clock is reset and the user gets another 6 months. As long as the ACS user is active using the same session_id within 6 months, there is no impact on your application and current logged in user. If an application user is completely inactive for 6 months or more, this user session is removed and any subsequent ACS call that requires user login such as create.json, update.json and delete.json will get a 404 error. We recommend your application can handle an invalid user session error and prompts a login screen to the user to login again.

Geo Query

ACS also currently supports MongoDB’s $nearSphere Geo Query.  Geo Query requires a field to be indexed with a geo index.  The ACS fields you can perform $nearSphere on are lnglat (pre-defined location data and only available in places and events) and coordinates (list of custom defined location data and available in all objects).  It implies that places and events have two geo indexes in the same collection and that prevents us from supporting $geoNear operation that is more powerful than $nearSphere.  We will consolidate lnglat value with coordinates values and remove geo index on lnglat field.

How does it affect your application?  For events and places, even if you never explicitly copied lnglat value to coordinates, lnglat will appear as the first element of coordinates.  Performing $nearSphere on coordinates field will return a match if it matches the lnglat value.  $nearSphere query on lnglat or coordinates will continue to work as before.

Questions?

Please post your questions on Appcelerator Q&A forum with “ACS” tag or leave your comments on this blog post.

On my previous post we went through the process of setting up a Node.ACS app, and understanding the basics of its built-in MVC framework. It’s now time to integrate ACS back-end services. Our main goal for this mini-project is to use a responsive framework (Bootstrap) to provide a custom, clutter-free front-end for ACS. Think about it this way: You’re using ACS to store locations. Why give your client access to ALL of ACS, just to curate data? ACS’ interface is designed for the developer, not for the end-user. We’ll build a phone and tablet-friendly web user interface what will allow them to easily enter data into the system. So let’s get started!

Structure of our website:

We’ll have a Login screen that will be used to login against the ACS User service. Upon successful login, the user will see a screen displaying a list of places that will be part of the ACS Places service. This screen will provide options for Adding and Deleting places, as well as launching a “Google Map” when a location is clicked. On the top navigation area we’ll have two links, About and Contact with sample content only to illustrate linking and session management. The website will look like this:

App.js

In this file you initialize your website and your session with ACS.

var ACS = require('acs').ACS;
var ACS_KEY='YOUR_ACS_KEY';
var ACS_SECRET='YOUR_ACS_SECRET';

// initialize app
function start(app, express) {
     app.use(express.favicon(__dirname + '/public/images/favicon.ico'));          //set favicon

     // this line is explained @
     // http://docs.appcelerator.com/cloud/latest/#!/guide/node_mvc
     app.use(express.session({ key: 'node.acs', secret: ACS_SECRET }));

     ACS.init(ACS_KEY, ACS_SECRET);
}

Config.json

{
  "routes":
  [
    { "path": "/", "callback": "application#index" },
    { "path": "/error", "callback": "application#error" },
    { "path": "/home", "callback": "home#home" },
    { "path": "/login", "method":"post", "callback": "useraccess#login" },
    { "path": "/logoff", "callback": "useraccess#logoff" },
    { "path": "/about", "callback": "application#about" },
    { "path": "/contact", "callback": "application#contact" },
    { "path": "/api/delete", "callback": "api#deleterec" },
    { "path": "/api/addplace", "method":"post","callback": "api#addrec" }
  ],
  "filters":
  [
    {"path": "/home", "callback": "session_filter#validateSession"},
    {"path": "/about", "callback": "session_filter#validateSession"},
    {"path": "/contact", "callback": "session_filter#validateSession"},
    {"path": "/api/delete", "callback": "session_filter#validateSession"},
    {"path": "/api/add", "callback": "session_filter#validateSession"}
  ],
  "websockets":
  [
    { "event": "", "callback": ""}
  ]
}

This file is in many ways the heart of your app. Here you define how the user is allowed to interact with the website, or how a page should interact with another. The first section, the routes, are a fundamental part of an MVC website. Defining this section is part of your website planning process and provides you a clear idea of how your website will behave.

I have stored functions in different files, but only for organization purposes. This is more an issue of your personal programming style. You can certainly use a single file for all your functions. This table should be read like: When the user browses to /home, I will execute the home function inside /controllers/home.js and the data will be available via GET.

Now let’s look at the filters section, which has a similar format.

All entries are using the same function inside the same file. This block is actually providing a way for us to protect certain areas of our website. Instead of having to validate the user session by code on every page, we set a filter on the pages we want to protect. The validateSession function simply verifies the validity of the session. If invalid redirects to error page, if valid, control is returned to the page controller.

function validateSession(req, res, next) {
  if(!req.session.session_id) {
    res.redirect('/error');
  } else {
    next();
  }
}

ACS

Access to ACS methods is consistent with the way you’d used them with Titanium, where you call the method and pass an object and a callback.

For our login method, we grab data from the HTTP POST and then send to ACS.

function login(req,res){
    ACS.Users.login({
        // grab data from http post
        login: req.body.username,
        password: req.body.password
    }, function(data) {
    	if (data.success){
    		// set session data to be used later througout the app
		req.session.session_id=data.meta.session_id;
                req.session.user_id=data.users[0].id;
		req.session.fullname=data.users[0].first_name + ' ' +
data.users[0].last_name;
                // the "home" controller will pick it up
		res.redirect('/home');
    	}else{
    		res.redirect('/error');
    	}
    });
}

When the user successfully logs in, he/she is taken to Home, where a list of Places is displayed. The controller for the “Home” template looks like this:

function home(req, res) {
	ACS.Places.query({
        order: "-created_at" // new on top
    }, function(data) {
        if(data.success) {
            console.log(data);
            res.render('home', {
                                title: 'Beer Places',
                                places:data.places,
                                page:'Home',
                                fullname:req.session.fullname
                                });
        } else {
            res.send('Error occured. Error code: ' + data.error + '.
Message: ' + data.message);
        }
    })
}

The line that reads res.render(‘home’,{}) is sending some data to the View, and one of these pieces is the actual places array that was returned by ACS. This Array is send as a static, client-side array to the view. The templating engine can now loop through the array and write the rows in HTML.

<tbody>
<% places.forEach(function(place){ %>
  <tr id="<%=place.id%>">
    <td><%=place.name%></td>
    <td><%=place.city%></td>
    <td><%=place.phone_number%></td>
    <td><a href="http://maps.google.com/?q=<%=place.name%>@
<%=place.latitude%>,<%=place.longitude%>" target="_blank"
title="Map">Map</a></td>
    <td><a href="javascript:void(0);" onClick="deleterec('<%=place.id%>')"
title="Delete"><div style="text-align: center">
<i class="icon-remove-circle"></i></div></a>
</td>
  </tr>
<%    }) %>
</tbody>

If you look closely, you’ll see that the places array effectively is available to the template. Also notice that you can execute Javascript code by encapsulating it in tags, in this case performing a forEach loop on the Places array, and displaying HTML rows. Just remember, when you want to execute Javascript code you use <%= your_code %> and to echo values you use <% your_variable %>.

An API on top of an API

You could use Node.ACS to provide high-level methods, an API if you like, that interact with the ACS API. An example of this technique is providing a “delete” method that in turn will call the ACS delete place method. Why do this? Well, for one, you don’t want to have your API key available in your Javascript source. With this method, your API key resides inside Node.ACS, that is in the server-side. Another reason could be because you’d like to perform other operations with the data returned by ACS, perhaps even return a new JSON string to your front-end. If you look at our Javascript code for deleting a record, it looks like this:

function deleterec(recid){
      var r=confirm("Delete this record?");
      if (r==true){
          $.ajax({
            url: '/api/delete/?id=' + recid,
            type: 'GET',
            success: function(data) {
              location.href='/home';
            },
            error: function(XMLHttpRequest, textStatus, errorThrown) {
                //alert("Status: " + textStatus);
                //alert("Error: " + errorThrown);
            }
        });
      }
    }

NOTE: In a real-world scenario you’d want to provide a more secure way of deleting your records and not by simply calling a Delete URL with your record id, but those security measures are out of the scope of this post.

Using Node.ACS’ built-in is really fun. The fact of not having to install a web server is a very convenient feature, and being able to take advantage of node.js definitely provides virtually endless possibilities.

The full source code for this example is available at https://github.com/ricardoalcocer/nodeacs_sample_website, simply fork/clone, add your own ACS Key and Secret, and hack away. This is a sample/proof-of-concept so feel free to send me pull request with error corrections or features you’ve added to the project.

Judging from the reaction, there’s no reason to believe that iOS 7 won’t fulfill Tim Cook’s promise of being “the most significant update to the mobile operating system since its introduction on the iPhone in 2007″.

New features in this release include:

• Improved controls and notifications
• Multi-tasking interface and responsiveness to motion for apps
• AirDrop content sharing
• In-car integration
• Personal security enhancements

We have already downloaded the beta and have successfully recompiled and run a few simple apps on top of it. No doubt you’ll be doing the same and looking for new and innovative ways to take advantage of these new capabilities.

Rest assured that we are committed to delivering support in the Appcelerator Platform and Titanium on the day it is released.

In the meantime, please share with us and the rest of the community your feature requests and requirements for iOS7-specific support, as well as any issues, via the Titanium Community JIRA. https://jira. appcelerator.org/browse/TC

Stay tuned for more information as we get closer to the general availability of iOS 7 in the fall.

Why did you pick Titanium for your development needs?

Titanium is awesome. It’s open unlike other platforms and can be modified as we want, when we want.

We didn’t chose native SDKs because we wanted flexibility, fast development speed and extensibility; we are Javascript-gurus and have background as architects using node.js-powered Cloud-solutions. (scalable web-apps, innovative database solutions and real time communication)

Tell us a little bit about choosing your development option

So we had the basic concept of “that” soccer app. We asked how we could do something really innovative and beautiful, while keeping spent resources low, and creativity and flexibility at maximum.

There were many development options we considered, including Sencha Touch and PhoneGap. We even considered Adobe’s “Publish to iOS” feature. We explored these options because everyone on our team feared the Objective-C mess that would happen if we tried to use it in an extremely dynamic way.

Ultimately, this is why we chose Titanium and the ability to leverage Javascript to build solid and native experiences for mobile devices.

Can you describe the app in more detail?

We wanted an innovative soccer app that combined real-time information with user-interaction. This includes information about every player – his interests, pictures, per-game information, live-ticker, etc. and a platform on which everything could thrive.

We didn’t just build an app, we built an app sandbox! Titanium makes it extremely easy to customize an app so that we could not only implement several teams into one app, but also have the opportunity to easily extend the app to be a white-label product: this allows us to build unique experiences for as many teams as possible — without reinventing the wheel each time.

What development problems did you face prior to using Titanium?

We faced several problems with the app including memory leaks that we had to chase down, the complexity of plain Objective-C compromising our creativity and lastly the deployment time of updates and hotfixes.

Can you walk me through how your team developed this application?

We sat down with our designer and built a concept for many pages. We then decided on the the most efficient way of implementation. Do we use deep-nested Views, templated Views, etc. We even thought about using UIWebViews.

We wanted a truly dynamic application, so we built a skeleton which got data from the server and outputted it. Then we made that data redundant, making it available offline.

We then started the design of the app. First, we got the navigation bar beautiful, then we placed the logo on top of everything. We split our scrum into each window and feature. It was astonishingly easy from there on – development from top to bottom.

We even were able to build functions generating a whole window subsystem … something which would be extremely messy and complex in Objective-C. For instance, when we want to display game information, we have a global controller which dynamically checks every parameter before the window is generated: orientation, current page, usage history, etc. This generates each window as dynamically as possible.

The development took 6 months, which boils down to 3 1/2 months if we leave out logistical problems (contact with the team, their ideas and feedback, and of course other projects).

How does Titanium fit into your future development plans?

Through this process we gained a ton of experience using Titanium. To keep our skills sharp, we have a hackathon each month and recently we were able to build an app in just 5 hours. It was a home automation application (the backend was implemented with node.js, a few Raspberry Pi’s, serial connectors and some hacked-together on-off controllers (for light) and one thermometer sensor).

The development is so easy and straightforward that we can build everything our creativity allows us to do. We go from idea to concept in one or two days, and then to a finished app in one month (depending on complexity — the dynamic nature of the soccer app is waaay more complicated than the home-automation system).

What kind of database, content, or cloud services are you accessing?

For the database we’re using PHP/MySQL on one server as a data aggregation for news and other static data. For dynamic data (i.e. publish-subscribe messaging system for the live-ticker), it’s determined based on the device (performance, capacity, internet speed, etc.) what type of connection routine is used. We also use a server side parser of the static data and data streams from third-party sources, a content provider for dynamic data like games and we use a plain Node.js / LevelDB configuration for everything which has to be quick and fast.

For the content we’re using a database for in-app data. We built an update distribution system which can update the app without losing our AppStore rating. With Titanium this is easy since we are unable leave the Javascript-sandbox and can’t in any way execute malicious code.

We’re using Titanium Analytics, Google Analytics and a self-built analytics system. Our own backends and cloud-solutions are backed by Level3, AWS EC2 and Elastic Load Balancing.

What kind of native features are you using in your app?

We’re using the native UI, video (MP4s from YouTube), the camera, a SQL database and geolocation for analytics and cache data using direct file system access with indices stored as JSON.

Big thanks to Kenan for taking the time to give us some insight into his experience and success with Titanium app development. Interested in having your Titanium app showcased? Send us an email at community@appcelerator.com and share your story with us!

With Titanium you use Javascript to build native mobile Apps. With Node.ACS you now can use Javascript to write your back-end code, with super easy access to ACS database and storage, all hosted on our secure and scalable cloud infrastructure. As an added advantage, your local Node.ACS installation is a self-contained environment, that doesn’t require you to install a local web server for testing. As you will see later on, when you run a Node.ACS app, it is automatically listening for requests on a given HTTP Port; you just have to point your browser to it!

Getting started

Assuming you have Node and NPM, open up a terminal/command window and type:

This will install Node.ACS globally on your computer. To start using it you need to login to your appcelerator account by typing:

Now that you have successfully logged in, you’re ready to create your first app. Change to the folder where you’d like your app to live, for example cd ~/Documents/MyApps and type:

This command will create for you a new folder with the name of your new app. Now change to that folder (cd MyFirstApp) and you’ll see the files that were created for you. I’ll explain them later.

To run the app, simply type:

Your terminal/command window will show something like this:

When you run your app, Node.ACS is actually setting up a local server for you and at this point it is waiting for connections. As you can see in the screenshot above, ACS is listening on port 8080. This means that all you need to do is browse to that address. Launch up your web browser and point it to http://localhost:8080 and you’ll see this:

This HTML page is being served by your local Node.ACS server, but it’s much more than this. Node.ACS has a full-featured MVC framework based on ExpressJS. If you go to your application folder you’ll see that some files and folders were created for you.

These folders/files are explained in more detail in this page, so make sure you check it out. However, I’ll explain how to work with some of these files from a practical standpoint, and in the process we’ll create a complete website.

Building a Website

If you’re new to MVC this will probably take some time reading the code, testing and re-reading, but simply because of how MVC separates concerns. With an MVC framework, your pages(views) are static. When you want to make them dynamic, you pass static information to them. A templating engine then takes over to render the static page with new dynamic data. If you come from a background of developing websites using a “traditional” paradigm, MVC may feel weird at first. If you have worked with other MVC frameworks before, they you will feel right at home. In any case, MVC is arguably the best way of writing scalable applications.

If you go to your “Views” folder, you’ll see a file named “index.ejs”. Instead of an HTML extension, it is using EJS. The reason for this is that Node.ACS is using Embedded Javascript as its templating engine.

<!DOCTYPE html>
<html>
  <head>
     <title><%= title %></title>
    <link rel='stylesheet' href='/css/style.css' />
  </head>
  <body>
       <h2>Node.ACS</h2>
    <p><%= title %></p>
  </body>
</html>

Notice <%= title %> inside the Title Tag and the Body. This is the way you tell EJS to insert dynamic data into your template. Title in this case is a variable that was sent to the template before getting it rendered and sent to the browser. The benefit of using these templates is that you build your HTML as a static page, and use placeholders during your design process to represent dynamic data. When your page is ready to be implemented, you simply change the dynamic parts to use the corresponding variable name and save the file with .ejs extension. To show the page with dynamic data, you use the page controller, which you can find under controllers/application.js.

function index(req, res) {
     res.render('index', { title: 'Welcome to Node.ACS!' });
}

This function is receiving two objects: req and res. As their names imply, req has information about how the user got here (the request), and res holds information and provides methods to take the user some place else (the response).

In this example we’re using the “render” method of the res object. This method is receiving the name of the view, and an object with all the variables that you’d like to make available to your view, in this case title, and the static template gets rendered with this new data. If you change the value of title, you’ll see it changing on the browser. However your server is still running with a previous version of your files. You need to stop the server and restart it because that part of the Javascript function is already running and changes will not take effect until you run it again. This is as simple as going to your terminal, hitting CTRL+C to break the execution, and running “acs run” again; or simply pressing the “up” key on your keyboard which will type it for you.

We’re still missing one important detail. How do we tell the framework that the “main” page of your app will be handled by the index function that lives inside application.js? You configure these mapping (or route as they’re called) in config.json.

{
  "routes":
  [
    { "path": "/", "callback": "application#index" }
  ],
  "filters":
  [
        { "path": "/", "callback": "" }
  ],
  "websockets":
  [
       { "event": "", "callback": ""}
  ]
}

In this file we’re saying that when you browse to the home page, it will execute the function index inside application.js. We’ll see more about filters in the second part of this post, and websockets are explained here.

For simplicity, let’s create a trivial page that will be displayed when navigating to /newpage.

Step 1: Create your route by adding it to your config.json

[
    { "path": "/", "callback": "application#index" },
    { "path": "/newpage", "callback": "newpage#newpage" }
]

Step 2: Write the “newpage” function in newpage.js. I’m using a separate file for illustration purposes.

function newpage(req,res){
     res.render('newpage', { greeting: 'I am the new page' });
}

Step 3: Create the template called newpage and make sure it is using the new variable “greeting”.

<!DOCTYPE html>
<html>
  <head>
     <title><%= greeting %></title>
    <link rel='stylesheet' href='/css/style.css' />
  </head>
  <body>
       <h2>Node.ACS</h2>
    <p><%= greeting %></p>
  </body>
</html>

Restart your server and browse to your page. Then change the URL to http://localhost:8080/newpage and you’ll see the new page.

These are the basic principles for building websites using Node.ACS. To learn more about the EJS templating engine and how you can use loops, arrays and other fun Javascript features, go to http://embeddedjs.com/getting_started.html. To learn more about the “response” and “request” objects, you can go to http://expressjs.com/api.html#req.params.

If you want to publish your website for everyone to see, simply type

Node.ACS will give you a public URL in return. The next time you publish, use the --force parameter to tell Node.ACS to overwrite your previous pages.

Final thoughts

This is a full-featured web MVC framework. You can use anything you’d normally use when developing websites, such as JQuery or Bootstrap. Just make sure that any library you use, or any dependency for that matter, is saved in the /public folder. From your views, the /public folder is the root folder, so if you placed an image at /public/image.png, from your view you would reference it like <img src=”/image.png” />

Stay tuned for the second part of this post, where we’ll apply this concepts to build a custom front-end to ACS.

Have fun!

Note: This is a pre-production release, and as such may contain regressions or other issues. Please do not use it in production, and keep backups of all important projects and data. If you find an issue, please report it in JIRA with a reproducible test case. We ask you provide feedback by Wednesday, 5/29.

How to Update

These are links to continuous integration builds. To install them, choose “Help Menu > Install Specific Titanium SDK…” from inside Titanium Studio.

• OSX
• Linux
• Windows

To update Studio, please visit http://preview.appcelerator.com and follow the instructions to update to the RC stream, or to download a new install.

NPM Packages

npm install -g alloy@1.1.3-alpha
npm install -g titanium@3.1.1-alpha

npm remove -g titanium
npm install -g titanium
npm remove -g alloy
npm install -g alloy

Updates in Titanium 3.1.1

Read the complete Release Notes. A full list of updates is available here.

Changes in supported OS versions

3.1.1 now has a minimum supported Android version of 2.3.3 (API level 10). The minimum iOS supported version is 5.x, which requires Xcode 4.3 or later.

API Changes

We’ve updated Titanium.Calendar, and deprecated Titanium.Android.Calendar.

Tooling updates

Support for Android r22 tooling. See Updating to Android r22 Tools for information about supporting older SDKs. Note that this beta still has some issues with r22 tooling on Windows, but this will be addressed in the final release.

Google Maps Support

We added a new userLocationButton property and updated the regionchanged event.

BlackBerry Support

We’ve folded in the latest version of our BlackBerry platform to this release. It’s no longer a separate download.

How do I know if I’ve run into this issue?

See TIMOB-13944. You’ll get a failure similar to “TypeError: argument of type ‘NoneType’ is not iterable”

How do I fix this problem?

There are a number of different ways to address the issue, depending on your goals:

If you want to use just the very latest version of the SDK, download the pre-release 3.1.1 build from http://builds.appcelerator.com.s3.amazonaws.com/index.html#3_1_X

If you need  to use prior versions of the SDK:

• You can create symlinks between the old and new locations of the test tools:
  • ln -s /Applications/Android-sdk/build-tools/17.0.0/aapt aapt ln -s /Applications/Android-sdk/build-tools/17.0.0/dx dx
• You can download the previous version of the tools:
  • Linux: http://dl.google.com/android/android-sdk_r21.1-linux.tgz
  • OS X: http://dl.google.com/android/android-sdk_r21.1-macosx.zip
  • Windows: http://dl.google.com/android/android-sdk_r21.1-windows.zip

We’d like to share with you our story on how we built ArtistBox and to give you some insights on how we solved the (not a few) issues that we had.

What’s ArtistBox?

Artistbox is an iPhone application that finds the most complete information about your favourite artists: their biography, discography, news, concerts in your area and worldwide, videoclips, pictures and similar artists.

We strive to gather way more information than any other music discovery app on the market – for example by adding up-to-date news or hi-res pictures – and for the next versions we will add more cool features.

Why Titanium and why not native?

The app has two components: a client side – the app itself – and a server side. The whole app was build in five months by just two programmers @dan_tamas and @nosoloweb and we feel that coding it in objC wouldn’t have given us such an advantage from the time point of view.

There are many other reasons we chose Titanium:

• depending on how the app sells we might want to go cross platform and build an Android version. In this case we will only have to work on the UI side of the app while anything else will remain untouched and working out of the box.
• the fact that with a few lines of code we could have a working proof of concept was an amazing advantage over doing mockups and then implementing them in the code.
• we are very proficient with Appcelerator but we don’t know objC so we used what we knew best
• we bootstrapped this so the development cost was only in hours of work and not having to pay one or more objC programmers was a real boost.
• we developed the server in NodeJS at the same time with the app. Developing both the app and the server side in Javascript instead of JS and objC helped us keep the focus on the building proccess.

What issues did you need to overcome

At this point we’d like to get a little more technical and explain how we managed to overcome the problems we had with the app.

One issue was the amount of the XHR calls we had to make. When the app opens it fetches all the artists in the device’s music library and also basic data for each of them. As you can see in the screenshot the application is very visual, we have a lot of images and each artis will have a lot of information:

Way too many XHR calls

Our main goal was to make a very responsive app and due to the amount of server calls we had to find a balance between the information sent from the server and the number of calls. So we decided to go with many calls that return a small amount of information. The overall time the user has to wait might be bigger in this case but the app doesn’t lock and the feedback received is really fast.

We hit a wall here because the ASIHttpRequest – the objC library Titanium uses on the native side – has a limit of 4 concurrent requests. The rest of the requests are put in a queue and executed when the previous calls finish.

What ASI does is perfectly correct, there is no point in overloading the network with too may concurrent requests but in our case the user would have had to wait for ALL the images from the previous windows to load in order to be able to receive the current window information.

We modified the XHR library to be able to handle a queue and priorities and we set the images to have the lowest priority while the artist information (JSON data) has the highest priority. At the JS level we limit the simultaneous requests for the images at only 3 so we always have a free slot on the native side for the data – higher priority requests are passed to ASI immediately.

Of course we take advantage of the caching that XHR does and we have a request to the server only once: the first time a new resources is requested or when the time to live expired. This way after the initial load the number of global requests decreases drastically.

Blocking the UI

The images are diplayed in tableViewRows and if we had put the source of the image directy in the imageView the UI would have locked until the image was loaded.

What we did was create the image **but without** the source property, download the image locally and save it then populate the source with the local file URL. This way the table will scroll normally and the pictures will be loaded one by one giving the user a way better experience.

Youtube clips

We have to display lots of videoclips from Youtube which can be done in two ways:

1. open the clip in mobile Safari or the Youtube app. This meant making the user leave ArtistBox and it was not an acceptable option.
2. use webviews to load the clip – not a good approach as we had to keep the memory footprint as low as possible.

We came with a different approach: each time the user taps on a clip the app makes a call to the mobile version of the Youtube site, finds the streaming link and opens a videoplayer with the source URL set to this streaming link.

The disadvantage is that the user will have to wait for an extra request to the Youtube servers but the overhead is not too big. The fact that he/she can see the videoclip right inside the app makes it worth it.

There were a few more aspects we had to take care of. The first one was to show very clearly that the videos are coming from Youtube so we designed the thumbnails with the big “Youtube” watermark. We also had to filter the results within the Youtube APIs to return only the videos allowed to run on mobile and also in the user’s country.

You can download the module from Github, it is MIT licensed.

We believe that the complexity of ArtistBox pushed the Titanium framework to the limits as we are using a large number of its APIs in our app (tableViews, videoPlayer, audioPlayer, lots of imageViews, scrollableViews, httpClient, localStorage, UI transtions, webviews, etc) and not always in a common way. But we also believe that Titanium was the right choice and it reached our expectations :)

There are also a few modules we used and we want to thank their creators:

- a modified version of XHR by Raul Riera
- TiNetworkHelpers by Ben Bahrenburg
- a modified version of TiMiniBrowser by Rafael Kellermann Streit

Enough talking, let’s see some action

ArtistBoxApp from ArtistBox App on Vimeo.

ArtistBoxApp from ArtistBox App on Vimeo.

Final words

ArtistBox is a very complex application that has to deal with a huge amount of information while also being memory leaks free. Making it stable and very fast were our main purposes because the users are very sensitive when it comes to huge loading times and repeated crashes. Being able to offer them so much info about their favourite artists while displaying the UI in an instant were two very challenging tasks that we hope we completed successfully. You can see we’re not trying to be modest here, test the app for yourselves and let us know what you think.

We are proud that a few teams from the Appcelerator community participated in the International Space Apps Challenge, and we are excited to showcase their work. Great job, everyone!

by Ketan Majmudar

Project: T-10 (pronounced “T-Minus Ten”)

Team (Appcelerator community):
Kate Arkless Gray @SpaceKate
João Neves @jpgneves
Ketan Majmudar @ketan
Dario Lofish @dariolofish

The Challenge: Spot the Station

NASA recently launched the Spot the Station website, which allows people to spot the space station and sign up for alerts when it flies overhead. The tasks were to:

• “Extend the functionality of the Spot the Station site by building an app that allows you to share your sightings with others.”
• “Create a visualization with Spot the Station data.”

The Solution:

T-10 from João Neves on Vimeo.

Overview

Our goal was to set up an alert to help astronauts on the International Space Station (ISS) take images of planet Earth under their specific desired circumstances. For example, they might want a picture of London with clear skies or a picture of New York during a thunderstorm.

The T-10 app allows astronauts to select cities of interest, time of day and the weather condition required. This data is then sent to our server, which waits for the correct conditions and finds the next scheduled times the ISS will be over the city in question. When both city and weather conditions are met, a push notice is sent to the app and provides an alert 10 minutes before the ISS will enter visibility of that city, giving astronauts enough time to prepare to take the photo.

When the T-10 countdown begins, it also sends a push alert to any ground users who have the app installed and would like to send a digital wave back to the ISS and the astronauts aboard. This two-way communication creates a social connection and sense of unity, promoting the knowledge that people on Earth and in space are waving at each other.

In future updates, we hope to add the ability to add the #ISSWave hashtag to share pictures to and from the ISS and Earth. We also intend to add more complex controls to manage when and how alerts get stored and shared with others.

Getting Started

I signed up for the International Space Apps Challenge in London, held at the Google Campus in East London. I had been invited to take part in a European space apps hack recently, but due to working commitments, I completely missed it. When I saw the announcement for the International Space Apps challenge, I signed up as quickly as I could. Being a NASA-driven event just added to the awesomeness of the hackathon. My main goal was just to participate, and I wasn’t even intending to take part seriously in the challenge aspect. I was more than happy to network and tinker with some cool ideas and people over the weekend.

A very early start on Saturday morning was a challenge in itself, having been up late every night for the past two weeks working on the SCI-FI-LONDON film festival app, but I felt it was my duty to make the effort for this hackathon. To be honest, I didn’t know what kind of people would be present or if I would have the energy to stick through a whole weekend. I went in expecting to build an app using the Patino game engine for Titanium, as I’m on the private beta – perhaps a cosmic windchime or mapping related to a comet or near-Earth object. But in the midst of the opening pitches and the multitude of available broad challenges to choose from, fate and social connections led us to form our team and the app T-10.

I tweeted Kate Arkless Gray (@SpaceKate) – whom I’d met through Bill Thompson (@billt), a technology journalist who works for the BBC Click Radio programme – and we connected with an idea to build an alerting app system which related to current earth weather patterns. Although my original idea was more Earth-bound, Kate had actually asked astronauts from the ISS if they would use an app that would tell them when the weather was good so they could take snaps of the planet! This was a cool plan, and we set it in motion.

Kate’s friend Joao Neves (@jpgneves), a software engineer and Android hacker from Stockholm, came on board, and we decided to use Titanium as the core of the application and build a server component. What I most enjoy about the Titanium platform is that it allows me to take the foundation of my learned skill sets and apply it to something amazing that is inclusive within the mobile community. Targeting multiple platforms is awesome, and being JavaScript-based, Titanium has helped me embrace the language in a way I never would have before.

The Process

We had to make sure we had the right APIs on hand and a suitable user-flow. We found a table that would be our home for the next 12 hours and had an open recruitment office in the form of stickies on the edge of our table. We sat and began coding an app that would use ACS push notifications and a bunch of open-source Titanium scripts. We had so much fun building, designing and conceptualising the app and solution that we wanted to weave a few more ideas in, knowing that we could never achieve the Flickr pool upload, share integration and Earth-based “wave” functionality that would enable people on the ground to send a virtual wave to the ISS as it flew over.

When our fourth team member, designer Dario Lofish (@dariolofish), logged on, our dream team was complete. We all connected online, made sure we were in tune with the concept and approach, then got back to our roles.

As fate would have it, the ISS was due to fly over London at around 9:30, and Kate dragged us (plus about 10 others) so we could see it fly over. Then back to the hacking. Under normal circumstances, we would have stayed all night, but by 22:30, I bailed to the far recesses of North London, promising to return the following morning.

App design during hackathons can be crazy, but we managed to have clear roles and had a simple core concept that we were all behind. Titanium made it easy to prototype ideas and integrate design ideas on the fly quickly.

Highlights & Insights

Our demo at the end of the day went really well, and I demonstrated the functionality of setting and sending the event from my iPhone 4S plugged directly into the projector, with push notification responses. It was a real joy to be part of the team behind T-10, and I’m proud of the ease and speed with which our team locked into the development process and how easy we made all of our jobs seem.

I was pleased to see a lot of mobile solutions come out of the weekend, many of them trying to take complex space data and put them into the hands of ordinary people in a way that makes sense. There were some superb, inspiring solutions that bridged the gap between software and hardware. It was also incredible to see the cooperation and coordination of people, some in the same room, some located all over the world. Since I was 10, I have had this odd dream to become a developer – back then it was just a desire to be a computer programmer. Mobile development has suddenly become a huge business and one that has moved in from the fringe of society into an evolving and ever-shifting set of features and parameters. With every year, new concepts, gestures and devices evolve and play a role in how our societies interact with the world around us. It is very cool and exciting to be part of that change.

At the end of the hackathon, we were so excited when they announced that we had been chosen by the judges as one of the two winning London Challenge teams! We are hoping that we will do well in the global round coming up and that our app will be featured in the Victoria and Albert Museum as part of the Digital Futures: Urban Open Space event.

We are now in the People’s Choice voting phase, so you can vote for T-10 via Twitter. Wish us luck!

app.js

navigation.js

Bad – Memory leak in line 55

Good – Memory leak avoided in line 65

zoomable.js

function Zoomable(image) {
    var scroll = Ti.UI.createScrollView({
        width: Ti.UI.FILL,
        height: Ti.UI.FILL,
        contentWidth: 'auto',
        contentHeight: 'auto',
        
    });
    var image = Ti.UI.createImageView({
        image: image,
        width: Ti.UI.SIZE,
        height: Ti.UI.SIZE
    });
    
    function onLoad() {
        image.removeEventListener('load', onLoad);
        
        var ratio = 0,
            width = image.rect.width,
            height = image.rect.height;
            
        if(width > height) {
            ratio = scroll.rect.width / width;
        } else {
            ratio = scroll.rect.height / height
        }
        scroll.minZoomScale = ratio;
        scroll.zoomScale = ratio;
        image.image = image.image;
    }
    image.addEventListener('load', onLoad);
    scroll.add(image);
    return {
        view: scroll,
        image: image
    }
}

To use this, now we need to create our gallery, this is the commonJS module that will be dropped into our code to show the gallery:

gallery.js

function Gallery(images, startAt) {
    images = images || [];
    startAt = startAt || 0;
    var views = [];
    var imgs = [];
    
    for(var i = 0, len = images.length; i < len; i++) {
        var zoomable = Zoomable(images[i]);
        views.push(zoomable.view);
        imgs.push(zoomable.image);
    }
    
    var scrollable = Ti.UI.createScrollableView({
        views: views,
        currentPage: startAt
    });
    
    return {
        view: scrollable
    }
}

And finally, an example on how to use it:

app.js

/** 
 * To be used this way
 */

var Log = require('log');

Log.Info('This is an info log');
Log.Error('This is an error log');
Log.Debug('This is a debug log');

// ... more code ...

Log.emailLogFile({
    developer: 'dev@example.com',
    message: 'Something intelligent',
    subject: 'Here is the log'
});

var DEBUG = true;
var WRITES = true;

function logFile() {
	return Ti.Filesystem.getFile(Ti.Filesystem.applicationDataDirectory,'titanium_log.txt');
}
 
function logMsg(type, str) {
	if (typeof str == 'object') {
		try {
			str = JSON.parse(str);
		} catch(e) {
			str = JSON.stringify(str);
		}
	}
	return '['+type+' ' + new Date().getTime() + '] ' + str;
}
 
exports.Info = function(str) {
    if(DEBUG){
        if(WRITES)
            logFile().write(logMsg('INFO', str), true);
        Ti.API.info(str);
    }
};
 
exports.Debug = function(str) {
    if(DEBUG){
        if(WRITES)
            logFile().write(logMsg('DEBUG', str), true);
        Ti.API.debug(str);
    }
};
 
exports.Error = function(str) {
    if(DEBUG){
        if(WRITES)
            logFile().write(logMsg('ERROR', str), true);
        Ti.API.error(str);
    }
};
 
/**
 * Gets the actual log file
 */
exports.getLogFile = function() {
    return logFile();
};
 
/**
 * Gets the log file path
 */
exports.getLogFile = function() {
    return logFile().nativePath;
};
 
/**
 * Returns the text of the log file
 */
exports.getLogText = function() {
    return logFile().read();
};
 
/**
 * Opens an email dialog to send the log to the developer
 * @param {Object} params {
 *                  @param developer    Email to be sent to
 *                  @param message      Message to send
 *                  @param subject      Subject in the message
 *                }
 */
exports.emailLogFile = function(params) {
    var developer = params.developer || '';
    var message = params.message || 'Please see attached';
    var subject = params.subject || 'Log file from app';
    
    var email = Ti.UI.createEmailDialog({
        subject: 'Log file from app',
        messageBody: 'Please see attached',
        toRecipients: [developer]
    });
    email.addAttachment(logFile());
};
 
exports.deleteLog = function() {
	logFile().deleteFile();
};

exports.setDebug = function(_bool) {
	DEBUG = _bool;
};

exports.setWritesToFile = function(_bool) {
    WRITES = _bool;
}

On the phone with someone who gave my app a bad rating is a post from: SavageLook.com

For about a week there my MMA fighter app for Android, Knucklehead, has been out of commission. The reason is that the site that I scrape for data, Sherdog was completely redesigned. I needed to rework a lot of my PHP-based screen scraping code to make it work. My PHP is rusty, but fortunately, my regular expression chops are always sharp. In any case, it’s back to working order now.

Maybe with a little luck I can get people to re-rate those 1-star ratings I got while it was down. If not, perhaps I can guilt people into giving me good ratings by saying that it’s my newborn son’s fault I didn’t get to it sooner. I mean, really, are you going to give the father of this child a hard time? Don’t be so heartless.

Screen Scraping Tips

As we all know, screen scraping is pretty much the most volatile way to supply your apps with data. While no amount of planning can permanently future-proof your screen scraper, there’s some things you can do to make it easier.

• Define a data model for what you are scraping. What made my project relatively easy to get working again was that I had a clearly defined data model shared by both the backend and frontend. In my case, this is a LAMP stack and distributed Android app respectively. Now my users don’t need to download a new version of my app in order to get the fix. It just works now.
• Code the scraper on a backend proxy, not in the app itself. That way, when your scraper inevitably gets broken at some point (after a year in my case), you only need to change the code in one place. This goes hand-in-hand with defining a data model.
• Keep it simple stupid. Don’t over-architect a screen scraper. Most data processing code will change over time, but a screen scraper may need a total rewrite at some point. Put all your software engineering skills into controlling what leaves the scraper, but play it pretty loose with what the scraper is going to be processing.
• Using JSON? You better be using jsonlint.com too. jsonlint.com can save you a lot of time and aggravation when it comes to creating and processing your scraped data. Not only does it validate your JSON, but it will also pretty print it so it’s easy to read through yourself.

That’s just a couple things that made fixing my scraper a lot less painful. You guys out there have any tips? I’d love to hear them. All things being equal, I hope I never have to screen scrape for data ever again. But since that’s pretty unlikely, it’s good to be prepared for the inevitable obstacles that scraping will present.

The Joys of Screen Scraping is a post from: SavageLook.com

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
• Full source code on Github

Video

Path menu with Appcelerator Titanium is a post from: SavageLook.com

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 <canvas> and Three.js
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

3D, Sockets, and Native Android with Appcelerator Titanium is a post from: SavageLook.com

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

• Forms app on Github
• Forging Titanium Episode 1: CommonJS Modules

Forms with Appcelerator Titanium is a post from: SavageLook.com

Adobe Acquires Nitobi

So if you haven’t heard yet, Adobe acquired Nitobi, the company that is responsible for PhoneGap. This was announced at Adobe’s big MAX conference. If you are unfamiliar with PhoneGap, then this post is going to be wildly uninteresting to you. At a high level, they provide a cross platform mobile development solution that leverages native webviews with HTML5, CSS, and Javascript to create native mobile apps.

Not Hard To See Coming

Well, for one thing, Adobe was obviously hedging its bets on Flash/Air’s viability in the long term with mobile when they started introducing HTML5 capabilities through Edge. I mean, if Adobe’s planning to offer interactive, Flash-like development with HTML5, who is going to believe that Flash itself has a real future with mobile? Or as Gizmodo put it, Adobe Edge may become the beginning of the end for Flash. Yeah, it will likely always exist, but it is not the de facto standard for delivering interactive web (or mobile) content anymore.

And of course there’s the whole Adobe Air for mobile thing. Android was obliging enough to make Air a first class citizen. Install Air, run Air apps… simple. And while the Adobe Air install is a bit hefty, it’s hardly something worth worrying about with today’s storage capabilities on mobile devices.

“Flash has been labeled an outlaw and Air is smuggled in like an illegal immigrant”

The more harrowing journey for Adobe has been iOS. Basically, Flash has been labeled an outlaw and Air is smuggled in like an illegal immigrant. There’s been a staring contest between Adobe and Apple for a while now, but I think it’s safe to say Adobe blinked. Apple has continually proven that is has the most marketable mobile devices available, and has done so without any back pedaling on what they will and will not allow (minus letting 3rd parties build apps).

Something had to give if Adobe was going to get a real foothold in the mobile world, and it obviously wasn’t coming in the form of their current solutions. Enter PhoneGap…

But PhoneGap is not Without Its Challenges

Image by Tyson Cadenhead

PhoneGap fills a lot of holes for Adobe, but its going to need a lot of help itself. I think PhoneGap has gone about as far as it can on its own. It has achieved its goal of abstracting most native functionality for many different mobile platforms, but starting developers are wanting more.

PhoneGap has no user interface components. This is not fun for new developers… or veteran ones for that matter. You need to build everything from scratch or go out and find a UI framework that works for you. The 2 front-runners, Sencha Touch and jQuery Mobile, bring their own glitches and idiosyncrasies. Also, now you find yourself learning 2 frameworks that have a noticeable lack of cross-over documentation.

There’s also a seemingly purposeful lack of direction in terms of tooling and best practices. New developers, often web developers, are left to their own devices to find the workflow that works best for them. There’s no sanctioned IDE or set of tools suggested from PhoneGap to build your mobile apps. Infinite flexibility can be a real drag when you just want to know the most effective way to get things done.

But let’s put this even more plainly…

What are the pros and cons of PhoneGap?

And what are the pros and cons of Adobe?

Anyone else seeing a pretty clear yin-yang thing going on here?

So What Does It All Mean?

Well, for one thing, it means PhoneGap is becoming an Apache project. Yep, they are donating PhoneGap to Apache, which puts them one step closer to their altruistic goal of PhoneGap itself becoming obsolete. PhoneGap’s own Brian Leroux stated in his PhoneGap 1.0 presentation that:

“The purpose of PhoneGap is for PhoneGap to cease to exist”

Why, oh why, did Adobe buy it then? I think it’s because they want to be your one stop shop for purchasing IDEs, frameworks, professional services, etc… Adobe is likely banking on the ongoing popularity of PhoneGap and web-based native mobile development. “Web-based native”… sounds a little like an oxymoron, but whatever.

A Match Made in Heaven, Right?

Sounds like a perfect match. The 2 companies seem to complement each other very well. But…

There’s just a few questions I still have regarding the acquisition. Rather than drone on any longer inserting my own conjecture, I’ll just list my questions here and leave them as talking points for you, my readers.

“I can already hear the `It’s back to AS1` complaints starting…”

• What happens to Flash/Air for mobile? It obviously won’t be forsaken, but this can’t sit real well with developers who have so far devoted themselves to this workflow.
• How does Adobe deal with the inevitability that current developers will revolt against using Javascript? I can already hear the “It’s back to AS1″ complaints starting…
• Does Adobe even have any interest in getting existing AS3 developers using PhoneGap? I know they are saying that they weill support both solutions, but come on, someone is gonna get more love than the other.
• How long until we finally see a defined workflow and IDE for PhoneGap. Is Dreamweaver integration the best we get?
• What will the PhoneGap guys do next? They are actively working to put themselves out of a job, so I’m curious what the next move is.

What’s Next?

I have no clue, but it’s sure to be interesting. I’m hoping for good things on both sides as it’s only going to make mobile development in general more exciting.

Will Adobe’s ability to create great tools translate to mobile success? Will PhoneGap’s strict adherence to the open web model jive well with Adobe’s history of closed, proprietary tools? Will the inevitable merge of the open web and existing Adobe community be a bumpy one?

Stay tuned…

Adobe & PhoneGap: Makes Sense, Mostly is a post from: SavageLook.com

Let me start by saying that among the 250+ new features added in Lion, there are some really useful ones. Some of my favorites include:

• Accessible from App Store – The fact that the upgrade itself is accessible from the App Store is extremely convenient. Granted, you could argue that Lion is little more than the equivalent of a Windows Service Pack, which are free and automatically delivered.
• Face Time – Face Time is no longer beta as it was with Snow Leopard and is fully integrated into Lion.
• Document locking – This grants you the ability to lock documents to prevent unwanted modifications. Not groundbreaking (see ‘read-only’), but the stuff Lion does behind the scenes, like automatically locking old documents, is pretty nice.
• Full disk encryption – No more is only your Home path safe. As of Lion, FileVault has been totally revamped and your entire disk will now be encrypted.
• Full screen apps
• Resize windows from any edge

In addition to these nicer features, Lion did some really annoying stuff to user interaction and the user interface. I’m all for change for the better, but most of these fall under the category of “If it ain’t broke, don’t fix it.” Fortunately, there’s ways to get back the settings you expect. Here’s 5 I specifically ran into.

Unhide ~/Library

For whatever reason, Apple decided to hide your ~/Library path. This is a real pain the ass if you find yourself in there a lot. For example, Appcelerator installs its SDK and other files in ~/Library/Application Support/Titanium. I’m constantly tinkering in that directory and it would be nice to see it in Finder.

Execute this line in Terminal and you’ll have your Library visible once again. USERNAME is your username:

chflags nohidden /users/USERNAME/Library

Disable “Natural” scrolling

Lion has included “natural” scrolling. I use quotations around “natural” because it feels anything other than natural for the average user. The content you are scrolling will now move in the direction you scroll, which is essentially the opposite of how it has always worked.

I have no problem with this functionality. What I do take issue with is that this was made the default behavior. To set scrolling back to the way most of us expect it, open System Settings, go to Trackpad/Mouse, and in the Scroll/Zoom tab uncheck “Scroll direction: natural”.

Fix 3 finger horizontal swipe navigation

The trackpad gesture I use more than any other is navigation using 3 finger swipes. I don’t even remember the last time I manually pressed the back button in a browser. No wait, yes I do. It was when I got my MacBook Air and it had Lion on it.

Turns out Apple mapped 2 finger horizontal swipes to its “Swipe between pages” functionality by default. Unfortunately, unless you switch this value to use 3 finger horizontal swipes, it won’t work for browser navigation. Check out the image below to see how:

Get Rid of LaunchPad

If I wanted what is effectively a “Show Desktop” button combined with an applications list, I’d use Windows. Just remove that thing from your Dock and be done with it.

Do yourself a favor. If you really want an effective way to find and run apps, check out Alfred or Quicksilver. You can thank me later.

Get a Fresh Restart

I don’t know about you, but I reboot my Mac really infrequently. When I do, though, it’s generally because I want a clean slate. I want all my apps closed and everything to go back to a fresh state. Lion disagrees with me.

By default Lion will remember every app you had open and make sure everything is just as you left it when you restarted your computer. For those of you who would also like a fresh restart, open System Settings and go to General. In there you just need to uncheck the “Restore windows when quitting and re-opening apps” checkbox.

5 Annoying Things About Mac OS X Lion and How To Fix Them is a post from: SavageLook.com

• Android Intents on the Appcelerator Developer Blog

Here We Go Again

OK, well I just did a post on how to use Android Intent Filters with Appcelerator, so why not the other side of the coin. This time you’ll learn how you can send Intents instead of receiving them. With this powerful native functionality you’ll be able to leverage existing apps on your Android device to do some of your heavy lifting, like sharing images, sending text, and a whole bunch of other things.

Android Intents in Appcelerator is a post from: SavageLook.com

• 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.

Android Intent Filters in Appcelerator is a post from: SavageLook.com

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 Kevin Whinnery 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. Jeff Haynie, 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.

Code Once, Adapt Everywhere is a post from: SavageLook.com