Kategorien
Uncategorized

Fastbook – a blazing fast HTML5 based Facebook app

Media_httpcdnsenchaio_zlfel

Well Mr Zuckerberg. Maybe before blaming a technology for your app being too slow your developers should learn how to use it properly :p

Kategorien
Uncategorized

Dramatically shorten the time of application setup with Yeoman

Modern Workflows for Modern Webapps

Yeoman is a robust and opinionated set of tools, libraries, and a workflow that can help developers quickly build beautiful, compelling web apps.

[youtube http://www.youtube.com/watch?v=vFacaBinGZ0?hd=1]

via yeoman.ioYour comment

I really like Yeoman. Its has never been easier to create a working skeleton for new webapps…

Kategorien
Uncategorized

NoSQL is Out and NewSQL is In – Says Google (Google Spanner)

Google recently released a paper on Spanner, their planet enveloping tool for organizing the world’s monetizable information. Reading the Spanner paper I felt it had that chiseled in stone feel that all of Google’s best papers have. An instant classic. Jeff Dean foreshadowed Spanner’s humungousness as early as 2009.  Now Spanner seems fully online, just waiting to handle “millions of machines across hundreds of datacenters and trillions of database rows.” Wow.

The Wise have yet to weigh in on Spanner en masse. I look forward to more insightful commentary. There’s a lot to make sense of. What struck me most in the paper was a deeply buried section essentially describing Google’s motivation for shifting away from NoSQL and to NewSQL. The money quote:

We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.

This reads as ironic given Bigtable helped kickstart the NoSQL/eventual consistency/key-value revolution.

We see most of the criticisms leveled against NoSQL turned out to be problems for Google too. Only Google solved the problems in a typically Googlish way, through the fruitful melding of advanced theory and technology. The result: programmers get the real transactions, schemas, and query languages many crave along with the scalability and high availability they require.

The full quote:

Spanner exposes the following set of data features to applications: a data model based on schematized semi-relational tables, a query language, and general purpose transactions. The move towards supporting these features was driven by many factors. The need to support schematized semi-relational tables and synchronous replication is supported by the popularity of Megastore [5].

At least 300 applications within Google use Megastore (despite its relatively low performance) because its data model is simpler to manage than Bigtable’s, and because of its support for synchronous replication across datacenters. (Bigtable only supports eventually-consistent replication across datacenters.) Examples of well-known Google applications that use Megastore are Gmail, Picasa, Calendar, Android Market, and AppEngine.

The need to support a SQLlike query language in Spanner was also clear, given the popularity of Dremel [28] as an interactive data analysis tool. Finally, the lack of cross-row transactions in Bigtable led to frequent complaints; Percolator [32] was in part built to address this failing.

Some authors have claimed that general two-phase commit is too expensive to support, because of the performance or availability problems that it brings [9, 10, 19]. We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions. Running two-phase commit over Paxos mitigates the availability problems.

What was the cost? It appears to be latency, but apparently not of the crippling sort, though we don’t have benchmarks. In any case, Google thought dealing with latency was an easier task than programmers hacking around the lack of transactions. I find that just fascinating. It brings to mind so many years of RDBMS vs NoSQL arguments it’s not even funny.

I wonder if Amazon could build their highly available shopping cart application, said to a be a motivator for Dynamo, on top of Spanner?

Is Spanner the Future in the Same Way Bigtable was the Future?

Will this paper spark the same revolution that the original Bigtable paper caused? Maybe not. As it is Open Source energy that drives these projects, and since few organizations need to support transactions on a global scale (yet), whereas quite a few needed to do something roughly Bigtablish, it might be awhile before we see a parallel Open Source development tract.

A complicating factor for an Open Source effort is that Spanner includes the use of GPS and Atomic clock hardware. Software only projects tend to be the most successful. Hopefully we’ll see clouds step it up and start including higher value specialized services. A cloud wide timing plane should be a base feature. But we are still stuck a little bit in the cloud as Internet model instead of the cloud as a highly specialized and productive software container.

Another complicating factor is that as Masters of Disk it’s not surprising Google built Spanner on top of a new Distributed File System called Colossus. Can you compete with Google using disk? If you go down the Spanner path and commit yourself to disk, Google already has many years lead time on you and you’ll never be quite as good. It makes more sense to skip a technological generation and move to RAM/SSD as a competitive edge. Maybe this time Open Source efforts should focus elsewhere, innovating rather than following Google?

Related Articles

So I guess this will lead the discussion in a new direction…. again 😉

Kategorien
Uncategorized

Jam – The JavaScript package manager

Jam

For front-end developers who crave maintainable assets,
Jam is a package manager for JavaScript.
Unlike other repositories, we put the browser first.

View on GitHub Find packages

Like!

Kategorien
Uncategorized

Javascript Must Read: A gentle introduction to Backbone and Ember

So you’ve accepted the challenge to go thick on the client-side; well done. You’ve considered all the frameworks out there and are unsure which one to choose? You’re not alone. Read on.

My experience, when learning the way of writing client-side apps is proving to be steep and hard. It’s not easy to deliberately choose to use MV* on the client for someone who wrote JavaScript, based entirely on jQuery and its plugins. This is an entirely new paradigm; it requires basic programming skills and a considerable understanding of JavaScript (the language) design. If your experience relates to mine, then read on!

I will be explaining the main differences between two of the most popular JavaScript clientside frameworks: Backbone.js and Ember.js. Each of these tools has strong points, as well as weaknesses that might help you make a more thoughtful choice.

Disclaimer: as software professionals, we must deal with diversity of opinion. Backbone and Ember are results of opinionated and experienced professionals, like you and me. One tool isn’t better than the other; they just serve different crowds and, ergo, solve different problems. Thanks Trek for the solid advice.

The Philosophy

Backbone is much easier to learn than Ember.

First and foremost, you need to understand that Backbone and Ember particularly serve slightly different crowds. Regarding complexity, Backbone is much easier to learn than Ember. However, it’s said that once you learn Ember, it hardly gets any more complex. Take Trek’s word on it. If you’re just getting started with some real JavaScript, then perhaps Backbone is your tool. If, however, you know that you’re going to deal with a lot more than just a simple use case or two, then you might prefer Ember.

Backbone

Jeremy Ashkenas built Backbone so it would be possible totake the truth out of the DOM. What he means by this is: whatever business you did using only jQuery / Mootools / Prototype could and should be better extracted into pure JavaScript structures – objects, if you will. Instead of using DOM elements to define your business elements and behavior, Backbone invites you to do it the other way around. JavaScript objects are the core and the DOM is merely a representation of that data.

With Backbone, you have some given assertions:

  1. Data lies in JavaScript objects, not the DOM
  2. Event handling lies in JavaScript objects, not jQuery event bindings
  3. The way you save data in a backend server is done through the objects that contain the data

You are given complete control over the way you build your app. Backbone was meant to give you a basic way of designing your model objects and how these interact with each other through event bindings.

Rendering HTML to the DOM is of your responsibility. You are free to choose any template engine: Mustache, DoT, Handlebars, Underscore, etc. Backbone contains a View prototype that has the responsibility of articulating the DOM and your JavaScript core.

Ember

When Tilde started building Ember, it did so with a far more challenging goal: to provide standard conventions in client-side development, eliminating as much boilerplate as possible. The result is a much more ambitious framework that aims for a predictable architecture and steady development.

Ember shares some common points with Backbone in the way it tries to pull data and behavior out of the DOM by providing extendable JavaScript prototypes, but it does this in a very different manner than Backbone does.

Ember stands on:

  1. Two-way data binding: objects in Ember are able to register bindings between one another. That way, whenever a bound property changes, the other one is updated automatically.
  2. Computed properties: if you wish to have a property that is a result of a function, you can create them and assign a property as computed by that function.
  3. Template auto-updates: when an object is updated in your app, all the views currently displayed in the screen that are bound to that object automatically reflect the change, with no boilerplate.

The DOM – Views

Both Backbone and Ember have common key concepts, such as views. They both represent DOM communication, respectively. The way they accomplish this concept are somewhat different, though.

I’ll use the Todo use case for the examples below, inspired by the TodoMVC showcase.

Backbone

A Backbone View might something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
var TaskView = Backbone.View.extend({
  tagName : "li"
, template : "task-template"
, render : function() {
    // your code to render here.
  }
, events : {
    "click .mark-done" : "mark_as_done"
  , "change .body"     : "update_body"
  }
, mark_as_done : function() { /* code here */ }
, update_body  : function() { /* code here */ }
});

This is simply the definition of your view. You will need to instantiate one if you want it to be in the page. Something like this will do the trick:

1
2
var task_view = new Task({ model : task_model });
$("body").append(task_view.el);

Notice that we’re passing a model in so you can keep a reference to the data object that feeds the template. The template property inside the view can be used to call an outside template, via an identifier. I’ve used something like this in the past:

1
2
3
4
5
6
7
8
9
var TaskView = Backbone.View.extend({
  template : "#task-template"
, render : function() {
    this.$el.html(
      Mustache.render($(this.template).html())
    , this.model);
  }
  // snip
});

Ember

Ember has a different approach to views. In fact, the convention states that views should talk to controllers and not models directly. This is a good practice, if you intend to follow a stable architecture. I’ll explain the sample for the same view:

1
2
3
4
5
var TaskView = Ember.View.extend({
  templateName : "task-template"
, mark_as_done : function() { /* code here */ }
, update_body  : function() { /* code here */ }
});

That’s it. But where’s all the rendering stuff? Well, Ember lifts that boilerplate for you. Simply say what the template is, the controller that holds the data object, and then you just need to append it to the DOM.

1
2
3
4
var task_view = TaskView.create({
  controller : task_controller // Ember.ObjectController
});
task_view.append();

When creating a new view instance, it will bind the controller’s content (which can be an Ember.Object or a list of them) to the view. When you decide to append the view to the DOM, it will look up the template and place the generated markup for you.

Thoughts

Backbone is more explicit and less magical.

Backbone is more explicit and less magical. You create a View, tell it what template to use and how, register the events and do what you have to do. They own the page. That’s a great start for those coming from a jQuery background. However, when something needs to be updated in the DOM, you will face some boilerplate.

With Ember, updates are automatic. You say what template it is and event callbacks are functions inside the view object. Any time an object is updated, the view automatically updates the page.

Some common event bindings are built into Ember and others must be put into the template. It’s good for those who come from a backend perspective, as it reduces boilerplate in a considerable way.

The Data – Models

Models in Backbone and Ember are quite similar. They hold information for a business entity.

Backbone

An example of a Backbone model looks like this:

1
var TaskModel = Backbone.Model.extend();

With this simple line of code, you have a working model with RESTful communication built-in. You get methods like save to persist the data and fetch to load it for free; no plugin is required. Validation is also built into the way data is saved by providing a validate callback, which returns a boolean that tells the record to be saved or not. The implementation of the validation is still for the developer to do.

To create a new task, you instantiate a new TaskModel.

1
2
3
4
var task = new TaskModel({
  body : "Mow the lawn"
, done : false
});

You may inject as many attributes as you like, because the task’s attribute list isn’t strict (think of it as schemaless). You can still set a defaults property when extending Backbone.Model.

Ember

With Ember, there are no models, just objects. It might look something like this:

1
var TaskObject = Ember.Object.extend();

Similar to Backbone, you need to extend from Ember.Object to create an object class. It inherits all the basic functionality for a class with callbacks for when it gets changed, created and destroyed, amongst other features. It does not, however, have backend communication out of the box. Ember.Data is being developed as an extension of Ember.Object by the Ember core team to fulfill that need. It’s already usable but not stable as far as the documentation tells.

Ember objects are also considered to be schemaless. To inject defaults into Ember objects, you extend Ember.Object by passing an object with as many attributes as you require.

1
2
3
4
var TaskObject = Ember.Object.extend({
  body : "Mow the lawn"
, done : false
});

Thoughts

Backbone has a consolidated way of syncing up with a persistence layer over REST and that’s a good convention there. It’s one less thing you have to configure in order to work with a backend server.

Ember is working its way toward making Ember.Data ready for production use, and it looks promising. Even so, the particularity of Ember objects having two way bindings makes it dead easy to perform connections between objects.

At this point in your reading, you have an inflection point between Backbone’s stability in communicating with the backend server and Ember’s bindings. Whatever’s most important to you should determine your decision.

The Glue – Controllers

This is where the frameworks part ways. They have a huge conceptual gap on how to glue things together in your app. While Backbone strives to remain as simple and flexible as possible, Ember sacrifices codebase size for a better architecture. It’s a tradeoff, really.

Warning: the following examples don’t contain HTML template samples.

Backbone

As I noted, Backbone aims for simplicity that converts to flexibility and it achieves such attributes precisely through the lack of a controller class. Most of the workhorse is distributed around views, collections, models and the router (should you choose to use Backbone’s Router).

Considering a list of tasks that needs to be managed, it would require:

  • A Collection to store the tasks.
  • A Model to store a task’s information.
  • A View to represent the collection.
  • Another View to represent each task.
  • A Router to manage URLs.

Most of the application logic will live in the views, as they connect models to the DOM. There is no clear distinction of responsibilities, as the view does everything. It can be good for small applications that don’t require a solid architecture.

To display a list of tasks, you would end up with something like this:

Collection

1
2
3
var TaskList = Backbone.Collection.extend({
  model : Task
});

Model

1
var TaskModel = Backbone.Model.extend();

Views

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
var TaskListView = Backbone.View.extend({
  render: function() {
    this.$el.empty();
    for (_i = 0, _i < this.collection.length; _i++) {
      var task = this.collection.models[_i];
      this.$el.append(this.renderItem(task));
    }
    var tasks = this.$el.html();
    this.$el.html(Mustache.to_html(template, {
      tasks: tasks,
      no_tasks: !this.collection.length
    }));
  },
  renderItem: function(task) {
    var view = new Row({ model: task });
    var el   = view.render();
    return el.el;
  },
});
1
2
3
4
5
6
7
var TaskView = Backbone.View.extend({
  tagName: "tr",
  render: function() {
    this.$el.html(M.to_html(template, this.model.attributes));
    return this;
  }
});

Router

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
var Router = Backbone.Router.extend({
  initialize: function() {
    this.tasks = new TaskList;
    this.view = new TaskListView({
      collection: this.tasks
    });
  },
  routes: {
    "": "tasks_list",
  },
  tasks_list: function() {
    this.view.render();
    $(".bucket:first").html(this.view.el);
  },
  start: function() {
    Backbone.history.start({
      pushState: true,
      root: "/tickets/"
    });
  }
});

Notice that the collection doesn’t have a template of its own; rather, it delegates to a single task view being rendered and appended to the final result being put on the page.

Ember

The number of classes required to have the same setup is slightly bigger.

  • Instead of a Collection, you would have an ArrayController, which works very much alike.
  • You would have an extra ObjectController for managing a single task.
  • Instead of a Model, you would have an Object / DS.Model, which work alike.
  • You would have the same kind of Views.
  • A Router is also responsible for managing URLs.

You might be thinking that the two frameworks are not too different from one another. It’s rather tempting, but it’s not exactly true. Some particular differences are:

  1. The controller is responsible for interacting with the data objects, not the View.
  2. The views are responsible for handling the DOM, not the controller.
  3. The views communicate with the controller, not directly to the data objects.
  4. The data that feeds the view template is actually a binding to the controller’s data.
  5. The router is more of a state manager, which includes much more than handling URLs.

The separation of concerns is good in the long term. Controller handles data, views handle the DOM, period. This kind of decoupled and cohesive, boilerplateless design allows for more focused testability.

The implementation to display the same list of tasks would be something like the following, considering a full Ember application:

Application root architecture

1
2
3
4
5
window.App = Ember.Application.create();
App.ApplicationController = Ember.ObjectController.extend();
App.ApplicationView       = Ember.View.extend({
  templateName: "application"
});

Object

1
App.Task = Ember.Object.extend();

Controllers

1
2
3
App.TasksController = Ember.ArrayController.extend({
  content: []
});

View

1
2
3
App.TasksView = Ember.View.extend({
  templateName: "my-list"
});

Router

1
2
3
4
5
6
7
8
9
App.Router = Ember.Router.extend({
  root : Ember.Route.extend({
    index: Em.Route.extend({
    route: '/',
    connectOutlets: function(router){
      router.get('applicationController').connectOutlet('tasks');
    }
  })
});

In Ember’s case, there’s not much being said about how things are done inside. All of that boilerplate is taken away so you can focus on what really matters in your app: you define a task object, a task list controller with an array called content, your view and the router simply combines them all together and puts it in the page.

Thoughts

After realizing how Ember really works, it starts to become liberating.

Predictably, this segment was the hardest to grasp on both frameworks. Backbone was definitely easier to learn and its flexible nature gives control over the way objects and DOM interact. This might be good for you, if you really need that kind of flexibility but still want to maintain a structure for your app’s logic in the JavaScript side.

As for Ember, its breathtaking implementation might be scary at first. However, after realizing how Ember really works, it starts to become liberating. All the conventions the framework sets for you releases you from boilerplate and configuration, letting you focus on your app. This is similar to what Rails did for serverside development that caught so much attention.

What Sets Them Apart?

Ember was meant to lift the common burdens of JavaScript development in the browser.

So far, the whole point of showing the two tools off has been to acknowledge their single and noble purpose: to delegate power to the client-side, through both structure and method.

Backbone core strength is definitely its KISS approach. It provides you with the minimum to let go of the DOM as the core supporter of your app, and start using real JavaScript objects that can be tested and designed properly.

Backbone comes packed with collections, models, views and the router, amongst other small utilities. You are free to do what you please with them.

Ember, on the other hand, was built with a different mindset, as it aims for a much more conventional and opinionated way of building web apps. It tackles a set of common problems, such as boilerplate, data binding and DOM templating so you don’t have to worry about them from the start. Ember was meant to lift the common burdens of JavaScript development in the browser.

Ember comes packed with objects, controllers, auto-updating views, state machines, bindings, observers and a router (which is also a state machine), all of them conjured with a good dose of conventions. You have an architecture already designed and ready to begin working without losing focus.

Conclusion

Mind the learning gap. Your experience and cultural heritage will strongly dictate how fast you join the client-side. If you’re scared of what to do or which one to pick, then I struck a nerve of yours and that’s good! Want a good answer on which to choose? Both.

It’s all about the JavaScript

If you’re unsure how even jQuery does all its magic, then start learning Backbone. It’s easier to begin with, and the documentation is dead simple to read and understand. After you’re done, start building something. Go dirty. Check these tutorials if you need some help.

If you’re still in the dark, read Yehuda Katz’s entries on how JavaScript works.

Once you get a better vision of how the JavaScript works as a language, you will begin to gain a better grasp of how the objects interact with each other. When you do, go for Ember. It’s more complicated at first, but don’t give up. Start reading the docs and the guides. You might want to check Trek Glowacki’s blog entry just before getting your hands dirty.

My bottom line

Personally, I’m leaning towards Ember; I enjoy its robustness at a macro scale, and I also prefer its conventions. Backbone is a more malleable and easier tool for smaller apps or small features inside an existing app.

I’m still learning both, and have a few challenges to tackle:

  • Automatic tests: how to do them and which testing suite is better. Qunit or Jasmine? Headless (thinking PhantomJS), Node or browser test runner? Not sure yet.
  • File uploads
  • Internationalization

What are your thoughts on this whole debacle? Do you have any challenges in mind? Any difficulties or impediments? Let me know!

A nice introduction to the two JavaScript Frameworks Backbone and Ember

Kategorien
Uncategorized

Guidelines For Mobile Web Development | Smashing Magazine

Media_httpmediasmashi_dhpbq

A nice collection of articles on mobile web development

Kategorien
Uncategorized

Some nice facts about website performance

Media_httpwwwderschep_uuhyd

Sums it up nicely 😉

Kategorien
Uncategorized

The best Mobile Frameworks Comparison Chart

Mobile Frameworks Comparison Chart

Find the right framework for mobile development using this awesome comparison chart of mobile frameworks

Kategorien
Uncategorized

Comparing Titanium and PhoneGap « Appcelerator Developer Center

A common question I get asked at developer events and conferences is how Titanium compares to PhoneGap. I thought I would take some time to explain how each technology works at a high level, and assess how the two technologies compare to one another.

From 10,000 feet, PhoneGap and Titanium appear to be similar. They both provide tools for cross-platform mobile development. Both also require the use of JavaScript and web technologies in some capacity. Both Titanium and PhoneGap are open source software with permissive licenses (the Titanium Mobile SDK is released under the Apache 2.0 license – PhoneGap, which might also be called a “distro” of the Apache Software Foundation-governed project “Cordova”, is similarly licensed).

But that’s really where the similarities end. While both technologies exist to enable cross-platform mobile development, the philosophies and approaches to solving this problem have very little in common. Also, the business goals driving each project from the perspective of the sponsoring companies (Adobe for PhoneGap and Appcelerator for Titanium) are very different. I will attempt, from my perspective, to describe these technical, philosophical, and business model differences in some detail in the text to follow.

Also, if you weren’t already aware, I am a long time Appcelerator contributor and employee. That said, I have worked hard to keep my technical and philosophical assessments based in technical fact and the explicitly expressed goals of the teams involved. If you feel I have made any points that are factually incorrect or misleading in some way, please let me know in the comments and I will update this post as appropriate.

I will first describe at a high level how both technologies work. I will also describe how both technologies are extended with additional native functionality. For each technology, I will also summarize the key strengths and weaknesses with their chosen approach to cross-platform. The technical differences will quickly become obvious, but after these overviews and comparisons, I will also describe what I feel are the philosophical and strategic differences between the platforms and where they are going.

Let’s start by exploring PhoneGap and how it works.

What is PhoneGap Trying To Accomplish?

The purpose of PhoneGap is to allow HTML-based web applications to be deployed and installed as native applications. PhoneGap web applications are wrapped in a native application shell, and can be installed via the native app stores for multiple platforms. Additionally, PhoneGap strives to provide a common native API set which is typically unavailable to web applications, such as basic camera access, device contacts, and sensors not already exposed in the browser.

At a higher level, PhoneGap might be considered the vanguard of the emerging W3C Device API standards, as they attempt to bring that future to web developers in the present. Today, no platform makes web applications first class citizens, though Mozilla’s promising Boot To Gecko platform has a chance to change that. Microsoft is also making interesting strides for Windows 8 with regard to first-class API access to web applications. But the goal of PhoneGap is to seize a subset of these rights for web applications today.

End User Workflow, Tooling and Interface for PhoneGap

To develop PhoneGap applications, developers will create HTML, CSS, and JavaScript files in a local directory, much like developing a static website. In fact, some PhoneGap developers cite as a bonus of the tool that they can develop in a desktop web browser most of the time, without needing the native toolchain at all.

To run a PhoneGap application on a native emulator/simulator, developers will generate a project for each of the native platforms they wish to support, configure that project’s “web root” directory in Xcode, Eclipse, or whatever native toolchain is needed, and then run the project using that tool. The precise steps are outlined in their getting started guides, per platform. Often, symbolic links are used to route the “www” folder across multiple native projects to a common directory location.

Installing a native-wrapped PhoneGap application to a device requires a similar workflow. However, to augment that process and alleviate the need to have native SDKs installed locally, Nitobi (recently acquired by Adobe) had created a service called PhoneGap Build, which will generate installable applications in the cloud. Functionality to support PhoneGap build deployment has recently been integrated into Adobe’s Dreamweaver tool.

The tools used with PhoneGap are the standard tools of web development, such as Firebug, Web Inspector, and your text editor of choice. There is also an emerging tool for remote debugging known as Weinre that is becoming more commonly used. Overall, the fact that you are developing a native application at all is mostly abstract during the development process.

How PhoneGap Works

As we mentioned previously, a PhoneGap application is a “native-wrapped” web application. Let’s explore how the web application is “wrapped”.

Many native mobile development SDKs provide a web browser widget (a “web view”) as a part of their UI framework (iOS and Android, for example). In purely native applications, web view controls are used to display HTML content either from a remote server, or local HTML packaged along with the native application in some way. The native “wrapper” application generated by PhoneGap loads the end developer’s HTML pages into one of these web view controls, and displays the resulting HTML as the UI when the application is launched.

If JavaScript files are included in a page loaded by a web view, this code is evaluated on the page as normal. However, the native application which creates the web view is able to (in different ways, depending on the platform) asynchronously communicate with JavaScript code running inside of the web view. This technology is usually referred to as “the bridge” in the context of PhoneGap architecture – the “bridge” means something slightly different in Titanium, as we will see later.

PhoneGap takes advantage of this to create a JavaScript API inside a web view which is able to send messages to and receive messages from native code in the wrapper application asynchronously. The way the bridge layer is implemented is different per platform, but on iOS, when you call for a list of contacts, your native method invocation goes into a queue of requests to be sent over the bridge. PhoneGap will then create an iframe which loads a URI scheme (“gap://”) that the native app is configured to handle, at which point all the queued commands will be executed. Communication back into the web view is done by evaluating a string of JavaScript in the context of the web view from native code.

There is much more to PhoneGap than that, but the messaging from web view to native code via the bridge implementation is the key piece of technology which allows local web applications to call native code.

Extending PhoneGap

Writing native extensions for PhoneGap requires that you:

  1. Write a JavaScript interface for your extension which will use PhoneGap’s API to queue up messages to be sent to native code.
  2. Register your extension with the native project in some way – on iOS this is done in the Cordova.plist file.
  3. Write native code that PhoneGap will route requests to from the web view, and implement any native code needed

Basically, developers can participate in the same asynchronous messaging system which powers the core PhoneGap native APIs.

Strengths of the PhoneGap Approach

In my estimation, PhoneGap’s primary architectural strength is that it is so small and simple. It does what it does, and it does that well. The PhoneGap team has intentionally implemented only the lowest common denominator of native APIs for the web browser-based app. Because the native API set is so small, it has been relatively easy to port PhoneGap to many different environments. Basically any native platform that supports a web view or web runtime can be a PhoneGap platform.

Non-visual native extensions in PhoneGap are also very simple. The requirements for registering native code to receive messages from the web view are very modest. Simple native extensions can be developed rapidly. This plug-in architecture was also well executed in my opinion.

There is also strength in the fact that native APIs and native app development are almost completely abstract to the end developer. Anyone who can write HTML, CSS, and even a small bit of JavaScript can wrap up a web page in a native app and distribute it as such. The barrier to entry in using PhoneGap to package web pages as native apps is extremely low.

Weaknesses of the PhoneGap Approach

The quality of the user interface in a PhoneGap application will vary based on the quality of the web view and rendering engine on the platform. The Webkit-based rendering engine on iOS is strong, and provides the best performance. The Android web view is functional, but has some notable limitations. On other platforms, the web view performance can be suspect depending on the OS version.

There are also the standard cross-browser issues web developers have always had to deal with. UIs will need to employ progressive enhancement, media queries, and that entire bag of tricks to remain usable on multiple platforms. It helps that many mobile platforms are adopting Webkit, but there are still significant differences even in Webkit based environments.

Mobile browsers are getting better all the time, which will help mitigate those problems. But approaching native-quality UI performance in the browser is a non-trivial task – Sencha employs a large team of web programming experts dedicated full-time to solving this problem. Even so, on most platforms, in most browsers today, reaching native-quality UI performance and responsiveness is simply not possible, even with a framework as advanced as Sencha Touch. Is the browser already “good enough” though? It depends on your requirements and sensibilities, but it is unquestionably less good than native UI. Sometimes much worse, depending on the browser.

PhoneGap also cannot be extended with native user interface. The end developer’s application its self lives inside a web view, and user interface is rendered in HTML. One can message to native code and create native UI that goes on, over, above, or adjacent to the web view, but it’s difficult or impossible to integrate a dynamic, HTML DOM-based UI with native UI components. Appcelerator would know – we tried to associate native UI with DOM elements early on, and needed to scrap that effort as the results were unpredictable and of insufficient quality.

There is also the other edge of the “lowest common denominator” sword. Very few native APIs are exposed to PhoneGap applications by default, which makes platform integration limited. There are a variety of plug-ins that exist to plug some of these holes, but in my personal experience they have varied in quality and maintenance. This could very well continue to improve over time though – there is a strong community around PhoneGap.

We’ll dive more into the philosophical aspects of PhoneGap soon, but let’s explore these same technical areas for Titanium first.

What is Titanium Trying to Accomplish?

The goal of Titanium Mobile is to provide a high level, cross-platform JavaScript runtime and API for mobile development (today we support iOS, Android, and the browser, with BlackBerry 10 and Windows Phone coming soon and eventually, respectively). Titanium actually has more in common with MacRuby/Hot Cocoa, PHP, or node.js than it does with PhoneGap, Adobe AIR, Corona, or Rhomobile. Titanium is built on two assertions about mobile development:

  • There is a core of mobile development APIs which can be normalized across platforms. These areas should be targeted for code reuse.
  • There are platform-specific APIs, UI conventions, and features which developers should incorporate when developing for that platform. Platform-specific code should exist for these use cases to provide the best possible experience.

So for those reasons, Titanium is not an attempt at “write once, run everywhere”. We think there are great, user-experience enhancing features across multiple platforms that developers should be using. We think that native apps should, where appropriate, take advantage of familiar, high-performance native UI widgets. However, we think it is unnecessary that native developers need to learn platform-specific APIs to draw a rectangle, or make an HTTP request.

Titanium is an attempt to achieve code reuse with a unified JavaScript API, with platform-specific features and native performance to meet user expectations. When you write a Titanium application, you are writing a native application in JavaScript. Titanium should be considered a framework for writing native apps, versus an abstraction from the actual platform you are targeting.

End User Workflow, Tooling, and Interface for Titanium

To develop native applications with Titanium, the developer is required to install the native tool chains for iOS and Android. After those tools are installed, however, the developer usually only interacts with the Titanium SDK’s scripting interface (today Python based). This is done either directly through the command line or (more commonly) through Titanium Studio, our Eclipse-based IDE.

Using the Titanium tool set, you will generate an application project directory which contains a configuration file, localization files, and a directory to contain the images, assets, and JavaScript source you will be writing to power your application. You will not, by default, be editing HTML and CSS files, unless you intend to create a hybrid-type application which contains both native and HTML-based UI. Titanium applications can and often do employ a “hybrid” (native and web) UI, like Facebook’s native application for instance. In this way, one could actually implement PhoneGap with Titanium, but that’s out of scope for this discussion.

Using this toolchain, your application is run using the actual em/simulators for the platforms you’re targeting. Titanium Studio also provides step-through debugging, code completion, and other IDE-level features.

Installing to a device for testing is also typically done using our build system. In Studio we provide a wizard interface to configure any code-signing dependencies, and then handle the deployment of your application to a connected device. You can also use the native toolchains to deploy or package your applications, if that is your preference.

When it comes time to ship your application to the stores, our build system will handle the creation of the final application packages for you. This is done locally on the developer’s machine using the native toolchains. The upload process will be the same as it is for native-only developers.

While developing a Titanium application, the underlying tool chains are mostly abstract. They must be present for development, but the end developer is rarely required to use them directly. The fact that native apps are being developed, however, is not abstract. User interfaces are created with cross-platform AND platform-specific components, and your applications should be dealing with things like background services, local notifications, app badges, configuration, activities/intents (on Android)… all things that are exposed via the Titanium JavaScript API.

How Titanium Works

There’s quite a bit happening behind the scenes in a Titanium application. But basically, at runtime, your application consists of three major components – your JavaScript source code (inlined into a Java or Objective-C file and compiled as an encoded string), the platform-specific implementation of the Titanium API in the native programming language, and a JavaScript interpreter that will be used to evaluate your code at runtime (V8 (default) or Rhino for Android, or JavaScriptCore for iOS). Except in the browser, of course, where the built-in JavaScript engine will be used.

When your application is launched, a JavaScript execution environment is created in native code, and your application source code is evaluated. Injected into the JavaScript runtime environment of your application is what we call “proxy” objects – basically, a JavaScript object which has a paired object in native code. Colloquially we will often refer to “JavaScript land” and “native land” in a Titanium application, as they are kind of parallel universes to one another. The proxy object exists both in JavaScript land and native land, and serves as the “bridge” between the two.

In your JavaScript code, when you call a function on the global Titanium or Ti object, such as var b = Ti.UI.createButton({title:'Poke Me'});, that will invoke a native method that will create a native UI object, and create a “proxy” object (b) which exposes properties and methods on the underlying native UI object to JavaScript.

UI components (view proxies) can be arranged hierarchically to create complex user interfaces. Proxy objects which represent an interface to non-visual APIs (like filesystem I/O or database access) execute in native code, and synchronously (or asynchronously for APIs like network access) return a result to JavaScript.

Hopefully this helps directly address two common misconceptions about Titanium – at no point does Titanium require the use of a web view component. The developer can create a web view as a native UI widget, but the web view is not used to evaluate Titanium source code. Nor is JavaScript code cross-compiled to Objective-C or Java in Titanium. Your JavaScript source is evaluated at runtime.

Extending Titanium

Titanium is extensible with both non-visual and UI capabilities in native code. By implementing a Proxy and/or View Proxy interface in native code, developers can create new native functionality for Titanium applications exposed in JavaScript. We expose the same interface we use to create Titanium’s own internal interface to module developers both on iOS and Android.

Strengths of the Titanium Approach

Since the goal of Titanium is to provide a higher level API for native mobile development across platforms, you will get access to a wide array of native features and functionality out of the box, from user interface components to socket interfaces to notification system integration. The goal of Titanium is to reduce the functionality gap between Titanium and pure native apps to something approaching zero. We’re likely to never support an entire platform’s API out of the box, but we want to cover 90% of the most common use cases and provide a platform where the other 10% can be added by people that need it.

Since Titanium can be extended with visual components that plug into the same view hierarchy as the rest of the application, you’re able to (ultimately) implement any user interface that is possible on the underlying native platform. Need a TableView to scroll at 60fps with special native code? You can do that. Want to seamlessly integrate an OpenGL drawing surface for a game, and keep the logic for the run loop in JavaScript? You can do that. You can integrate these UI extensions directly into the rest of your application built with the core Titanium APIs.

The look and feel of a Titanium application, when using common UI widgets, is also a strength of the platform. There is no visual emulation going on (either through the application of CSS, or rendering of UI widgets using OpenGL or Flash). When you create a NavigationGroup, it is backed by an actual UINavigationController on iOS. The animations and behavior match what a native app user will expect, because you’re using the same UI control.

Since Titanium provides a high level native programming API in JavaScript, the barrier to entry for native programming is significantly reduced for anyone who has used an ECMAScript based language (which is a lot of developers). Atwood’s Law is alive and well through Titanium.

Weaknesses of the Titanium Approach

The scope of the Titanium API makes the addition of new platforms difficult – implementing the Titanium API on a new native platform is a massive undertaking. For that reason, the Titanium platform is only available on what have been deemed the most critical mobile platforms at present: iOS, Android, and the web.

Our mobile web browser support is not yet of GA quality – we are continuing to work on the performance and feel of our UI widget set, as well as rounding out the implementation of our core Titanium APIs.

Because the layer of abstraction provided by Titanium is large, sub-optimal API implementations remain in our own internal framework. Some user interface components do not yet perform as well as their native counterparts under some circumstances, such as very large table views with highly customized layouts. Optimizing our core user interface components remains the primary engineering task for our team. As we fix bugs and hardware improves, we are seeing this become less of an issue. We also find that information architecture, especially for large data sets, needs to be applied in many cases.

Also owing to the ambitiousness of the Titanium platform, extending Titanium is non-trivial. A good working knowledge of Titanium’s architecture and the environment is necessary to effectively integrate a new native control or API. The developer experience, API docs, and high level guides for module developers were improved a lot with our latest 2.0 release, but remain an area of focus for us.

Philosophical Differences

By now, I would hope that the technical differences between PhoneGap and Titanium are pretty clear. But beyond those differences, the goals and direction of each project are different as well. The stated goal of the PhoneGap project is to, eventually, cease to exist. As stated earlier, PhoneGap is intended to be the leading implementation of emerging browser standards around device APIs. In theory, once browser vendors implement the features of PhoneGap, the platform will no longer be necessary. PhoneGap its self isn’t intended to be a platform – it’s a shim to add native app-like functionality to web applications. The web is intended to be the platform.

PhoneGap’s new sponsoring organization, Adobe, is also very much interested in the advancement of the web as a platform. In recent months, Adobe has been aggressively building out tools to enable the development of HTML 5/CSS 3 web applications. It seems obvious to me (and many others) that Adobe sees a diminishing role for Flash as standard web technologies evolve.

At it’s core, Adobe is a tools business. Platforms are a channel through which Adobe can sell tools. Once, that platform was Flash. Now, that platform is the web browser (in addition to Flash). I don’t know precisely how PhoneGap factors into Adobe’s product roadmap, but in a lot of ways it serves a similar purpose as Flash. PhoneGap is an attempt to create an abstract runtime environment to enable cross-platform deployment.

If Adobe can sell tools to develop for the web, and the web can be used to develop more types of applications, then that’s a clear win for Adobe. Which is fine, by the way – nothing wrong with selling tools.

It’s worth noting, however, that Adobe is not the governing body of the Cordova project, on which PhoneGap is now based. That project is owned and governed by the Apache Software Foundation. It remains to be seen what the interplay is going to be between the two projects, but my gut instinct is that they won’t diverge much. I think their goals will remain philosophically aligned.

Appcelerator is also interested in and supportive of the advancement of the web as a platform. Everyone wins when the web gets stronger as an application platform. The difference is that we view the web as one great platform among others, with a unique character and set of strengths and weaknesses. We don’t expect the web to become the only mobile application platform. We think that platforms like iOS, Android, BlackBerry, Windows Phone, and the like will continue to be influential, and will provide great experiences for users. That choice and competition will be a good thing for consumers, but will remain a problem for developers.

What we expect to provide for developers through Titanium is a way to target the web and native platforms from a single codebase, while retaining the features, performance, and tight platform integration that the users of that platform expect. We expect to build an enduring platform for mobile client development, with services and tools to speed up that process. We are not a tools company – we are a platform company, and our success will be linked to the success of developers on top of our platform. Over time, we hope to build an open source platform company in the spirit of Red Hat and other giants in that space.

Which tool or approach is right for you? Like all things in software development, it depends. There are no silver bullets. But hopefully this description and comparison will help you make the right choice for your situation.

A comparison of phonegap and titanium frameworks for cross plattform app development

Kategorien
Uncategorized

Screen Scraping with Node.js | Nettuts+

Media_httpd2o0t5hpnwv_upajb

A great way to scrape web pages using node.js