Understanding MVC And MVP (For JavaScript And Backbone Developers)

Publicat per hyde on dimarts, 17 de gener del 2012 / Etiquetes de comentaris: / Comments: (0)
Before exploring any JavaScript frameworks that assist in structuring applications, it can be useful to gain a basic understanding of architectural design patterns. Design patterns are proven solutions to common development problems and can suggest structural paradigms to help guide us in adding some organization to our application.

I think patterns are exciting as they’re effectively a grass roots effort that build upon the collective experience of skilled developers who have previously faced similar problems as we do now. Although developers 10 or 20 years ago may not have been using the same programming languages for implementing patterns, there are many lessons we can learn from their efforts.
In this section, we’re going to review two popular patterns – MVC and MVP. The context of our exploration will be how these patterns are related to the popular JavaScript framework Backbone.js, which will be explored in greater detail later on.

MVC

MVC (Model-View-Controller) is an architectural design pattern that encourages improved application organization through a separation of concerns. It enforces the isolation of business data (Models) from user interfaces (Views), with a third component (Controllers) (traditionally) managing logic, user-input and coordinating both the models and views. The pattern was originally designed by Trygve Reenskaug during his time working on Smalltalk-80 (1979) where it was initially called Model-View-Controller-Editor. MVC went on to be described in depth in “Design Patterns: Elements of Reusable Object-Oriented Software” (The “GoF” or “Gang of Four” book) in 1994, which played a role in popularizing its use.

Smalltalk-80 MVC

It’s important to understand what the original MVC pattern was aiming to solve as it’s mutated quite heavily since the days of it’s origin. Back in the 70′s, graphical user-interfaces were far and few between and a concept known as Separated Presentation began to be used as a means to make a clear division between domain objects which modelled concepts in the real world (e.g a photo, a person) and the presentation objects which were rendered to the user’s screen.
The Smalltalk-80 implementaion of MVC took this concept further and had an objective of separating out the application logic from the user interface. The idea was that decoupling these parts of the application would also allow the reuse of models for other interfaces in the application. There are some interesting points worth noting about Smalltalk-80′s MVC architecture:
  • A Domain element was known as a Model and were ignorant of the user-interface (Views and Controllers)
  • Presentation was taken care of by the View and the Controller, but there wasn’t just a single view and controller. A View-Controller pair was required for each element being displayed on the screen and so there was no true separation between them
  • The Controller’s role in this pair was handling user input (such as key-presses and click events), doing something sensible with them.
  • The Observer pattern was relied upon for updating the View whenever the Model changed
Developers are sometimes surprised when they learn that the Observer pattern (nowadays commonly implemented as a Publish/Subscribe system) was included as a part of MVC’s architecture many decades ago. In Smalltalk-80′s MVC, the View and Controller both observe the Model. As mentioned in the bullet point above, anytime the Model changes, the Views react. A simple example of this is an application backed by stock market data – in order for the application to be useful, any change to the data in our Models should result in the View being refreshed instantly.
Martin Fowler has done an excellent job of writing about the origins of MVC over the years and if you are interested in some further historical information about Smalltalk-80′s MVC, I recommend reading his work.

MVC For JavaScript Developers

We’ve reviewed the 70′s, but let us now return to the here and now. In modern times, the MVC pattern has been applied to a diverse range of programming languages including of most relevance to us: JavaScript. JavaScript now has a number of frameworks boasting support for MVC (or variations on it, which we refer to as the MV* family), allowing developers to easily add structure to their applications without great effort. You’ve likely come across at least one of these such frameworks, but they include the likes of Backbone, Ember.js and JavaScriptMVC. Given the importance of avoiding “spaghetti” code, a term which describes code that is very difficult to read or maintain due to its lack of structure, it’s imperative that the modern JavaScript developer understand what this pattern provides. This allows us to effectively appreciate what these frameworks enable us to do differently.
We know that MVC is composed of three core components:

Models

Models manage the data for an application. They are concerned with neither the user-interface nor presentation layers but instead represent unique forms of data that an application may require. When a model changes (e.g when it is updated), it will typically notify its observers (e.g views, a concept we will cover shortly) that a change has occurred so that they may react accordingly.
To understand models further, let us imagine we have a JavaScript photo gallery application. In a photo gallery, the concept of a photo would merit its own model as it represents a unique kind of domain-specific data. Such a model may contain related attributes such as a caption, image source and additional meta-data. A specific photo would be stored in an instance of a model and a model may also be reusable. Below we can see an example of a very simplistic model implemented using Backbone.
view plaincopy to clipboardprint?
  1. var Photo = Backbone.Model.extend({  
  2.     // Default attributes for the photo  
  3.     defaults: {  
  4.       src: "placeholder.jpg",  
  5.       caption: "A default image",  
  6.     viewed: false  
  7.     },  
  8.     // Ensure that each photo created has an `src`.  
  9.     initialize: function() {  
  10.        this.set({"src": this.defaults.src});  
  11.     }  
  12. });  
The built-in capabilities of models vary across frameworks, however it is quite common for them to support validation of attributes, where attributes represent the properties of the model, such as a model identifier. When using models in real-world applications we generally also desire model persistence. Persistence allows us to edit and update models with the knowledge that its most recent state will be saved in either: memory, in a user’s localStorage data-store or synchronized with a database.
In addition, a model may also have multiple views observing it. If say, our photo model contained meta-data such as its location (longitude and latitude), friends that were present in the a photo (a list of identifiers) and a list of tags, a developer may decide to provide a single view to display each of these three facets.
It is not uncommon for modern MVC/MV* frameworks to provide a means to group models together (e.g in Backbone, these groups are referred to as “collections”). Managing models in groups allows us to write application logic based on notifications from the group should any model it contains be changed. This avoids the need to manually observe individual model instances.
A sample grouping of models into a simplified Backbone collection can be seen below.
view plaincopy to clipboardprint?
  1. var PhotoGallery = Backbone.Collection.extend({  
  2.     // Reference to this collection's model.  
  3.     model: Photo,  
  4.     // Filter down the list of all photos  
  5.     // that have been viewed  
  6.     viewed: function() {  
  7.         return this.filter(function(photo){  
  8.            return photo.get('viewed');  
  9.         });  
  10.     },  
  11.     // Filter down the list to only photos that  
  12.     // have not yet been viewed  
  13.     unviewed: function() {  
  14.       return this.without.apply(this, this.viewed());  
  15.     }  
  16. });  
Should you read any of the older texts on MVC, you may come across a description of models as also managing application ‘state’. In JavaScript applications “state” has a different meaning, typically referring to the current “state” i.e view or sub-view (with specific data) on a users screen at a fixed point. State is a topic which is regularly discussed when looking at Single-page applications, where the concept of state needs to be simulated.
So to summarize, models are primarily concerned with business data.

Views

Views are a visual representation of models that present a filtered view of their current state. A view typically observes a model and is notified when the model changes, allowing the view to update itself accordingly. Design pattern literature commonly refers to views as ‘dumb’ given that their knowledge of models and controllers in an application is limited.
Users are able to interact with views and this includes the ability to read and edit (i.e get or set the attribute values in) models. As the view is the presentation layer, we generally present the ability to edit and update in a user-friendly fashion. For example, in the former photo gallery application we discussed earlier, model editing could be facilitated through an “edit” view where a user who has selected a specific photo could edit its meta-data.
The actual task of updating the model falls to controllers (which we’ll be covering shortly).
Let’s explore views a little further using a vanilla JavaScript sample implementation. Below we can see a function that creates a single Photo view, consuming both a model instance and a controller instance.
We define a render() utility within our view which is responsible for rendering the contents of the photoModel using a JavaScript templating engine (Underscore templating) and updating the contents of our view, referenced by photoEl.
The photoModel then adds our render() callback as one of it’s subscribers so that through the Observer pattern we can trigger the view to update when the model changes.
You may wonder where user-interaction comes into play here. When users click on any elements within the view, it’s not the view’s responsibility to know what to do next. It relies on a controller to make this decision for it. In our sample implementation, this is achieved by adding an event listener to photoEl which will delegate handling the click behaviour back to the controller, passing the model information along with it in case it’s needed.
The benefit of this architecture is that each component plays it’s own separate role in making the application function as needed.
view plaincopy to clipboardprint?
  1. var buildPhotoView = function( photoModel, photoController ){  
  2.     var base        = document.createElement('div'),  
  3.         photoEl     = document.createElement('div');  
  4.      base.appendChild(photoEl);  
  5.      var render= function(){  
  6.         // We use a templating library such as Underscore  
  7.         // templating which generates the HTML for our  
  8.         // photo entry  
  9.         photoEl.innerHTML = _.template('photoTemplate', {src: photoModel.getSrc()});  
  10.      }  
  11.      photoModel.addSubscriber( render );  
  12.      photoEl.addEventListener('click', function(){  
  13.         photoController.handleEvent('click', photoModel );  
  14.      });  
  15.      var show = function(){  
  16.         photoEl.style.display  = '';  
  17.      }  
  18.      var hide = function(){  
  19.         photoEl.style.display  = 'none';  
  20.      }  
  21.      return{  
  22.         showView: show,  
  23.         hideView: hide  
  24.      }  
  25. }  
Templating
In the context of JavaScript frameworks that support MVC/MV*, it is worth briefly discussing JavaScript templating and its relationship to views as we briefly touched upon it in the last section.
It has long been considered (and proven) a performance bad practice to manually create large blocks of HTML markup in-memory through string concatenation. Developers doing so have fallen prey to inperformantly iterating through their data, wrapping it in nested divs and using outdated techniques such as document.write to inject the ‘template’ into the DOM. As this typically means keeping scripted markup inline with your standard markup, it can quickly become both difficult to read and more importantly, maintain such disasters, especially when building non-trivially sized applications.
JavaScript templating solutions (such as Handlebars.js and Mustache) are often used to define templates for views as markup (either stored externally or within script tags with a custom type – e.g text/template) containing template variables. Variables may be deliminated using a variable syntax (e.g {{name}}) and frameworks are typically smart enough to accept data in a JSON form (of which model instances can be converted to) such that we only need be concerned with maintaining clean models and clean templates. Most of the grunt work to do with population is taken care of by the framework itself. This has a large number of benefits, particularly when opting to store templates externally as this can give way to templates being dynamically loaded on an as-needed basis when it comes to building larger applications.
Below we can see two examples of HTML templates. One implemented using the popular Handlebars.js framework and another using Underscore’s templates.
Handlebars.js:
view plaincopy to clipboardprint?
  1. <li class="photo">  
  2.   <h2>{{caption}}</h2>  
  3.   <img class="source" src="{{src}}"/>  
  4.   <div class="meta-data">  
  5.     {{metadata}}  
  6.   </div>  
  7. </li>  
Underscore.js Microtemplates:
view plaincopy to clipboardprint?
  1. <li class="photo">  
  2.   <h2><%= caption %></h2>  
  3.   <img class="source" src="<%= src %>"/>  
  4.   <div class="meta-data">  
  5.     <%= metadata %>  
  6.   </div>  
  7. </li>  
It is also worth noting that in classical web development, navigating between independent views required the use of a page refresh. In Single-page JavaScript applications however, once data is fetched from a server via Ajax, it can simply be dynamically rendered in a new view within the same page without any such refresh being necessary. The role of navigation thus falls to a “router”, which assists in managing application state (e.g allowing users to bookmark a particular view they have navigated to). As routers are however neither a part of MVC nor present in every MVC-like framework, I will not be going into them in greater detail in this section.
To summarize, views are a visual representation of our application data.

Controllers

Controllers are an intermediary between models and views which are classically responsible for two tasks: they both update the view when the model changes and update the model when the user manipulates the view.
In our photo gallery application, a controller would be responsible for handling changes the user made to the edit view for a particular photo, updating a specific photo model when a user has finished editing.
In terms of where most JavaScript MVC frameworks detract from what is conventionally considered “MVC” however, it is with controllers. The reasons for this vary, but in my honest opinion it is that framework authors initially look at the server-side interpretation of MVC, realize that it doesn’t translate 1:1 on the client-side and re-interpret the C in MVC to mean something they feel makes more sense. The issue with this however is that it is subjective, increases the complexity in both understanding the classical MVC pattern and of course the role of controllers in modern frameworks.
As an example, let’s briefly review the architecture of the popular architectural framework Backbone.js. Backbone contains models and views (somewhat similar to what we reviewed earlier), however it doesn’t actually have true controllers. Its views and routers act a little similar to a controller, but neither are actually controllers on their own.
In this respect, contrary to what might be mentioned in the official documentation or in blog posts, Backbone is neither a truly MVC/MVP nor MVVM framework. It’s in fact better to consider it a member of the MV* family which approaches architecture in its own way. There is of course nothing wrong with this, but it is important to distinguish between classical MVC and MV* should you be relying on advice from classical literature on the former to help with the latter.

Controllers in Spine.vs vs Backbone.js

Spine.js
We now know that controllers are traditionally responsible for updating the view when the model changes (and similarly the model when the user updates the view). As the framework we’ll be discussing in this book (Backbone) doesn’t have it’s own explicit controllers, it can be useful for us to review the controller from another MVC framework to appreciate the difference in implementations. For this, let’s take a look at a sample controller from Spine.js:
In this example, we’re going to have a controller called `PhotosController which will be in charge of individual photos in the application. It will ensure that when the view updates (e.g a user editd the photo meta-data) the corresonding model does too.
Note: We won’t be delving heavily into Spine.js at all, but will just take a ten-foot view of what it’s controllers can do:
view plaincopy to clipboardprint?
  1. // Controllers in Spine are created by inheriting from Spine.Controller  
  2. var PhotosController = Spine.Controller.sub({  
  3.   init: function(){  
  4.     this.item.bind("update", this.proxy(this.render));  
  5.     this.item.bind("destroy", this.proxy(this.remove));  
  6.   },  
  7.   render: function(){  
  8.     // Handle templating  
  9.     this.replace($("#photoTemplate").tmpl(this.item));  
  10.     return this;  
  11.   },  
  12.   remove: function(){  
  13.     this.el.remove();  
  14.     this.release();  
  15.   }  
  16. });  
In Spine, controllers are considered the glue for an application, adding and responding to DOM events, rendering templates and ensuring that views and models are kept in sync (which makes sense in the context of what we know to be a controller).
What we’re doing in the above example is setting up listeners in the update and destroy events using render() and remove(). When a photo entry gets updated , we re-render the view to reflect the changes to the meta-data. Similarly, if the photo gets deleted from the gallery, we remove it from the view. In case you were wondering about the tmpl() function in the code snippet: in the render() function, we’re using this to render a JavaScript template called #photoTemplate which simply returns a HTML string used to replace the controller’s current element.
What this provides us with is a very lightweight, simple way to manage changes between the model and the view.
Backbone.js
Later on in this section we’re going to revisit the differences between Backbone and traditional MVC, but for now let’s focus on controllers.
In Backbone, one shares the responsibility of a controller with both the Backbone.View and Backbone.Router. Some time ago Backbone did once come with it’s own Backbone.Controller, but as the naming for this component didn’t make sense for the context in which it was being used, it was later renamed to Router.
Routers handle a little more of the controller responsibility as it’s possible to bind the events there for models and have your view respond to DOM events and rendering. As Tim Branyen (another Bocoup-based Backbone contributor) has also previously pointed out, it’s possible to get away with not needing Backbone.Router at all for this, so a way to think about it using the Router paradigm is probably:
view plaincopy to clipboardprint?
  1. var PhotoRouter = Backbone.Router.extend({  
  2.   routes: { "photos/:id": "route" },  
  3.   route: function(id) {  
  4.     var item = photoCollection.get(id);  
  5.     var view = new PhotoView({ model: item });  
  6.     something.html( view.render().el );  
  7.   }  
  8. }):  
To summarize, the takeaway from this section is that controllers manage the logic and coordination between models and views in an application.

What does MVC give us?

This separation of concerns in MVC facilitates simpler modularization of an application’s functionality and enables:
  • Easier overall maintenance. When updates need to be made to the application it is very clear whether the changes are data-centric, meaning changes to models and possibly controllers, or merely visual, meaning changes to views.
  • Decoupling models and views means that it is significantly more straight-forward to write unit tests for business logic
  • Duplication of low-level model and controller code (i.e what you may have been using instead) is eliminated across the application
  • Depending on the size of the application and separation of roles, this modularity allows developers responsible for core logic and developers working on the user-interfaces to work simultaneously

Delving deeper

Right now, you likely have a basic understanding of what the MVC pattern provides, but for the curious, we can explore it a little further.
The GoF (Gang of Four) do not refer to MVC as a design pattern, but rather consider it a “set of classes to build a user interface”. In their view, it’s actually a variation of three other classical design patterns: the Observer (Pub/Sub), Strategy and Composite patterns. Depending on how MVC has been implemented in a framework, it may also use the Factory and Decorator patterns. I’ve covered some of these patterns in my other free book, JavaScript Design Patterns For Beginners if you would like to read into them further.
As we’ve discussed, models represent application data whilst views are what the user is presented on screen. As such, MVC relies on Pub/Sub for some of its core communication (something that surprisingly isn’t cover in many articles about the MVC pattern). When a model is changed it notifies the rest of the application it has been updated. The controller then updates the view accordingly. The observer nature of this relationship is what facilitates multiple views being attached to the same model.
For developers interested in knowing more about the decoupled nature of MVC (once again, depending on the implement), one of the goal’s of the pattern is to help define one-to-many relationships between a topic and its observers. When a topic changes, its observers are updated. Views and controllers have a slightly different relationship. Controllers facilitate views to respond to different user input and are an example of the Strategy pattern.

Summary

Having reviewed the classical MVC pattern, we should now understand how it allows us to cleanly separate concerns in an application. We should also now appreciate how JavaScript MVC frameworks may differ in their interpretation of the MVC pattern, which although quite open to variation, still shares some of the fundamental concepts the original pattern has to offer.
When reviewing a new JavaScript MVC/MV* framework, remember – it can be useful to step back and review how it’s opted to approach architecture (specifically, how it supports implementing models, views, controllers or other alternatives) as this can better help you grok how the framework expects to be used.

MVP

Model-view-presenter (MVP) is a derivative of the MVC design pattern which focuses on improving presentation logic. It originated at a company named Taligent in the early 1990s while they were working on a model for a C++ CommonPoint environment. Whilst both MVC and MVP target the separation of concerns across multiple components, there are some fundamental differences between them.
For the purposes of this summary we will focus on the version of MVP most suitable for web-based architectures.

Models, Views & Presenters

The P in MVP stands for presenter. It’s a component which contains the user-interface business logic for the view. Unlike MVC, invocations from the view are delegated to the presenter, which are decoupled from the view and instead talk to it through an interface. This allows for all kinds of useful things such as being able to mock views in unit tests.
The most common implementation of MVP is one which uses a Passive View (a view which is for all intense purposes “dumb”), containing little to no logic. MVP models are almost identical to MVC models and handle application data. The presenter acts as a mediator which talks to both the view and model, however both of these are isolated from each other. They effectively bind models to views, a responsibility which was previously held by controllers in MVC. Presenters are at the heart of the MVP pattern and as you can guess, incorporate the presentation logic behind views.
Solicited by a view, presenters perform any work to do with user requests and pass data back to them. In this respect, they retrieve data, manipulate it and determine how the data should be displayed in the view. In some implementations, the presenter also interacts with a service layer to persist data (models). Models may trigger events but it’s the presenters role to subscribe to them so that it can update the view. In this passive architecture, we have no concept of direct data binding. Views expose setters which presenters can use to set data.
The benefit of this change from MVC is that it increases the testability of your application and provides a more clean separation between the view and the model. This isn’t however without its costs as the lack of data binding support in the pattern can often mean having to take care of this task separately.
Although a common implementation of a Passive View is for the view to implement an interface, there are variations on it, including the use of events which can decouple the View from the Presenter a little more. As we don’t have the interface construct in JavaScript, we’re using more a protocol than an explicit interface here. It’s technically still an API and it’s probably fair for us to refer to it as an interface from that perspective.
There is also a Supervising Controller variation of MVP, which is closer to the MVC and MVVM patterns as it provides data-binding from the Model directly from the View. Key-value observing (KVO) plugins (such as Derick Bailey’s Backbone.ModelBinding plugin) tend to bring Backbone out of the Passive View and more into the Supervising Controller or MVVM variations.

MVP or MVC?

MVP is generally used most often in enterprise-level applications where it’s necessary to reuse as much presentation logic as possible. Applications with very complex views and a great deal of user interaction may find that MVC doesn’t quite fit the bill here as solving this problem may mean heavily relying on multiple controllers. In MVP, all of this complex logic can be encapsulated in a presenter, which can simplify maintenance greatly.
As MVP views are defined through an interface and the interface is technically the only point of contact between the system and the view (other than a presenter), this pattern also allows developers to write presentation logic without needing to wait for designers to produce layouts and graphics for the application.
Depending on the implementation, MVP may be more easy to automatically unit test than MVC. The reason often cited for this is that the presenter can be used as a complete mock of the user-interface and so it can be unit tested independent of other components. In my experience this really depends on the languages you are implementing MVP in (there’s quite a difference between opting for MVP for a JavaScript project over one for say, ASP.net).
At the end of the day, the underlying concerns you may have with MVC will likely hold true for MVP given that the differences between them are mainly semantic. As long as you are cleanly separating concerns into models, views and controllers (or presenters) you should be achieving most of the same benefits regardless of the pattern you opt for.

MVC, MVP and Backbone.js

There are very few, if any architectural JavaScript frameworks that claim to implement the MVC or MVC patterns in their classical form as many JavaScript developers don’t view MVC and MVP as being mutually exclusive (we are actually more likely to see MVP strictly implemented when looking at web frameworks such as ASP.net or GWT). This is because it’s possible to have additional presenter/view logic in your application and yet still consider it a flavor of MVC.
Backbone contributor Irene Ros (of Boston-based Bocoup) subscribes to this way of thinking as when she separates views out into their own distinct components, she needs something to actually assemble them for her. This could either be a controller route (such as a Backbone.Router, covered later in the book) or a callback in response to data being fetched.
That said, some developers do however feel that Backbone.js better fits the description of MVP than it does MVC
. Their view is that:
  • The presenter in MVP better describes the Backbone.View (the layer between View templates and the data bound to it) than a controller does
  • The model fits Backbone.Model (it isn’t greatly different to the models in MVC at all)
  • The views best represent templates (e.g Handlebars/Mustache markup templates)
A response to this could be that the view can also just be a View (as per MVC) because Backbone is flexible enough to let it be used for multiple purposes. The V in MVC and the P in MVP can both be accomplished by Backbone.View because they’re able to achieve two purposes: both rendering atomic components and assembling those components rendered by other views.
We’ve also seen that in Backbone the responsibility of a controller is shared with both the Backbone.View and Backbone.Router and in the following example we can actually see that aspects of that are certainly true.
Our Backbone PhotoView uses the Observer pattern to ‘subscribe’ to changes to a View’s model in the line this.model.bind('change',...). It also handles templating in the render() method, but unlike some other implementations, user interaction is also handled in the View (see events).
view plaincopy to clipboardprint?
  1. var PhotoView = Backbone.View.extend({  
  2.     //... is a list tag.  
  3.     tagName:  "li",  
  4.     // Pass the contents of the photo template through a templating  
  5.     // function, cache it for a single photo  
  6.     template: _.template($('#photo-template').html()),  
  7.     // The DOM events specific to an item.  
  8.     events: {  
  9.       "click img" : "toggleViewed"  
  10.     },  
  11.     // The PhotoView listens for changes to  
  12.     // its model, re-rendering. Since there's  
  13.     // a one-to-one correspondence between a  
  14.     // **Photo** and a **PhotoView** in this  
  15.     // app, we set a direct reference on the model for convenience.  
  16.     initialize: function() {  
  17.       _.bindAll(this, 'render'); 
  18.       this.model.bind('change', this.render); 
  19.       this.model.bind('destroy', this.remove);  
  20.     },  
  21.     // Re-render the photo entry  
  22.     render: function() {  
  23.       $(this.el).html(this.template(this.model.toJSON()));  
  24.       return this;  
  25.     },  
  26.     // Toggle the `"viewed"` state of the model.  
  27.     toggleViewed: function() {  
  28.       this.model.viewed();  
  29.     }  
  30. });  
Another (quite different) opinion is that Backbone more closely resembles Smalltalk-80 MVC, which we went through earlier.
As regular Backbone user Derick Bailey has previously put it, it’s ultimately best not to force Backbone to fit any specific design patterns. Design patterns should be considered flexible guides to how applications may be structured and in this respect, Backbone fits neither MVC nor MVP. Instead, it borrows some of the best concepts from multiple architectural patterns and creates a flexible framework that just works well.
It is however worth understanding where and why these concepts originated, so I hope that my explanations of MVC and MVP have been of help. Call it the Backbone way, MV* or whatever helps reference its flavor of application architecture. Most structural JavaScript frameworks will adopt their own take on classical patterns, either intentionally or by accident, but the important thing is that they help us develop applications which are organized, clean and can be easily maintained.

Fast facts

Backbone.js

  • Core components: Model, View, Collection, Router. It enforces its own flavor of MV*
  • More complete documentation than some frameworks (at the time of writing e.g Ember.js) with more improvements on the way
  • Used by large companies such as SoundCloud and Foursquare to build non-trivial applications
  • Event-driven communication between views and models means more complete control over what’s happening. It’s relatively straight-forward to add event listeners to any attribute in a model meaning more control over what changes in the view
  • Supports data bindings through manual events or a separate Key-value observing (KVO) library
  • Great support for RESTful interfaces out of the box so models can be easily tied to a backend
  • Extensive eventing system. It’s trivial to add support for pub/sub in Backbone
  • Prototypes are instantiated with the new keyword which some enjoy
  • No default templating engine, however Underscore’s micro-templating is often assumed for this. Also works well with solutions like Handlebars if you drop them in
  • Doesn’t support deeply nested models out of the box, but like many common problems there exist Backbone plugins such as this which can easily help
  • Clear and flexible conventions for structuring applications. Backbone doesn’t force usage of all of its components and can work with only those needed.
To continue reading, see Backbone Fundamentals.

Source: http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/

The this keyword on Javascript

Publicat per hyde / Etiquetes de comentaris: / Comments: (0)
One of the most powerful JavaScript keywords is this. Unfortunately it is hard to use if you don't exactly know how it works.
Below I explain how to use it in event handling. Later on I'll add some information about other uses of this.

Owner

The question that we'll discuss for the remainder of the page is: What does this refer to in the function doSomething()?
function doSomething() {
   this.style.color = '#cc0000';
}
In JavaScript this always refers to the “owner” of the function we're executing, or rather, to the object that a function is a method of. When we define our faithful function doSomething() in a page, its owner is the page, or rather, the window object (or global object) of JavaScript. An onclick property, though, is owned by the HTML element it belongs to.
This "ownership" is the result of JavaScript's object oriented approach. See the Objects as associative arrays page for some more information.
------------ window --------------------------------------
|                                          / \           |
|                                           |            |
|                                          this          |
|   ----------------                        |            |
|   | HTML element | <-- this         -----------------  |
|   ----------------      |           | doSomething() |  |
|               |         |           -----------------  |
|          --------------------                          |
|          | onclick property |                          |
|          --------------------                          |
|                                                        |
----------------------------------------------------------
If we execute doSomething() without any more preparation the this keyword refers to the window and the function tries to change the style.color of the window. Since the window doesn't have a style object the function fails miserably and produces JavaScript errors.

Copying

So if we want to use this to its full extent we have to take care that the function that uses it is "owned" by the correct HTML element. In other words, we have to copy the function to our onclick property. Traditional event registration takes care of it.
element.onclick = doSomething;
The function is copied in its entirety to the onclick property (which now becomes a method). So if the event handler is executed this refers to the HTML element and its color is changed.
------------ window --------------------------------------
|                                                        |
|                                                        |
|                                                        |
|   ----------------                                     |
|   | HTML element | <-- this         -----------------  |
|   ----------------      |           | doSomething() |  |
|               |         |           -----------------  |
|          -----------------------          |            |
|          |copy of doSomething()|  <-- copy function    |
|          -----------------------                       |
|                                                        |
----------------------------------------------------------
The trick is of course that we can copy the function to several event handlers. Each time this will refer to the correct HTML element:
------------ window --------------------------------------
|                                                        |
|                                                        |
|                                                        |
|   ----------------                                     |
|   | HTML element | <-- this         -----------------  |
|   ----------------      |           | doSomething() |  |
|               |         |           -----------------  |
|          -----------------------          |            |
|          |copy of doSomething()|  <-- copy function    |
|          -----------------------          |            |
|                                           |            |
|   -----------------------                 |            |
|   | another HTML element| <-- this        |            |
|   -----------------------     |           |            |
|               |               |           |            |
|          -----------------------          |            |
|          |copy of doSomething()|  <-- copy function    |
|          -----------------------                       |
|                                                        |
----------------------------------------------------------
Thus you use this to the fullest extent. Each time the function is called, this refers to the HTML element that is currently handling the event, the HTML element that "owns" the copy of doSomething().

Referring

However, if you use inline event registration
<element onclick="doSomething()">
you do not copy the function! Instead, you refer to it, and the difference is crucial. The onclick property does not contain the actual function, but merely a function call:
doSomething();
So it says “Go to doSomething() and execute it.” When we arrive at doSomething() the this keyword once again refers to the global window object and the function returns error messages.
------------ window --------------------------------------
|                                          / \           |
|                                           |            |
|                                          this          |
|   ----------------                        |            |
|   | HTML element | <-- this         -----------------  |
|   ----------------      |           | doSomething() |  |
|               |         |           -----------------  |
|          -----------------------         / \           |
|          | go to doSomething() |          |            |
|          | and execute it      | ---- reference to     |
|          -----------------------       function        |
|                                                        |
----------------------------------------------------------

The difference

If you want to use this for accessing the HTML element that is handling the event, you must make sure that the this keyword is actually written into the onclick property. Only in that case does it refer to the HTML element the event handler is registered to. So if you do
element.onclick = doSomething;
alert(element.onclick)
you get
function doSomething()
{
 this.style.color = '#cc0000';
}
As you can see, the this keyword is present in the onclick method. Therefore it refers to the HTML element.
But if you do
<element onclick="doSomething()">
alert(element.onclick)
you get
function onclick()
{
 doSomething()
}
This is merely a reference to function doSomething(). The this keyword is not present in the onclick method so it doesn't refer to the HTML element.

Examples - copying

this is written into the onclick method in the following cases:
element.onclick = doSomething
element.addEventListener('click',doSomething,false)
element.onclick = function () {this.style.color = '#cc0000';}
<element onclick="this.style.color = '#cc0000';">

Examples - referring

In the following cases this refers to the window:
element.onclick = function () {doSomething()}
element.attachEvent('onclick',doSomething)
<element onclick="doSomething()">
Note the presence of attachEvent(). The main drawback of the Microsoft event registration model is that attachEvent() creates a reference to the function and does not copy it. Therefore it is sometimes impossible to know which HTML currently handles the event.

Combination

When using inline event registration you can also send this to the function so that you can still use it:
<element onclick="doSomething(this)">

function doSomething(obj) {
 // this is present in the event handler and is sent to the function
 // obj now refers to the HTML element, so we can do
 obj.style.color = '#cc0000';
} 
 
 
Source: http://www.quirksmode.org/js/this.html

Threads in IOS Objective-C

Publicat per hyde on divendres, 2 de desembre del 2011 / Etiquetes de comentaris: , / Comments: (0)

I have some data calculation method (let it be "myMethod:"), and I want to move the call to another thread because I don't want to block my main UI functionality. So, started to do some research on how to call my method on another thread. As far as I see, currently, there are a lot of different ways for doing that. Here's a list:
a) using pure threads (available since iOS 2.0):
[NSThread detachNewThreadSelector:@selector(myMethod:) toTarget:self withObject:_myParamsArray];
b) using a simple shortcut (available since iOS 2.0). Available from inherited NSObject but the method belongs to NSThread class too:
[self performSelectorInBackground:@selector(myMethod:) withObject:_myParamsArray];
c) using a new approach of Grand Central Dispatch queues (available since iOS 4.0):
dispatch_async(dispatch_get_global_queue(0, 0),
  ^ {
      [self myMethod:_myParamsArray];
    });
d) somehow, using some classes such as NSOperation, NSBlockOperation or NSOperationQueue, though not sure how exactly to do it (some example would be appreciated)
Currently, I have used case "b" but curious about pros and cons and other related suggestions on that.
==========================
Answer:
Usually, you would prefer the GCD approach.
It's simpler when it comes to synchronization/locking than pure threads (NSThread - pthread), and it may be more accurate in a performance perspective.
When using pure threads, the problem is you may have performance issues, depending on the number of available cores/processors.
For instance, if you have only one core, creating many threads may slow down your application, because the CPU will spend most of its time switching from one thread to another, saving the stack, registers, etc.
On the other hand, if you have a lot of cores available, it may be nice to create a lot of different threads.
This is where GCD helps, as it manages this for you. It will create the appropriate number of threads, based on the available system resources, to guarantee an optimal utilization, and schedule your actions appropriately.
However, for that reason, tasks launched with GCD may not be real-time.
So if you REALLY needs that a detached task runs immediately, use an explicit threads. Otherwise, use GCD.
Hope this will help you : )
EDIT
A note about performSelectorInBackground: it simply creates a new thread. So there's basically no difference with the NSThread approach.
EDIT 2
NSOperation related stuff are a bit different. On Mac OS X, they are implemented using GCD since version 10.6. Previous versions uses threads.
On iOS, they are implemented using threads only.
Reference
All of this is very well explained in the Concurrency Programming Guide. It discusses the GCD and thread approaches, with a lot of details about the uses and implementations.
If you haven't read it already, you should take a look.

Original post: 

SupressWarnings

Publicat per hyde on divendres, 25 de novembre del 2011 / Etiquetes de comentaris: , , / Comments: (0)

Definition

The @SuppressWarnings annotation is defined in the Java Language Specification section 9.6.1.5. This section states:
The annotation type SuppressWarnings supports programmer control over warnings otherwise issued by the Java compiler. It contains a single element that is an array of String. If a program declaration is annotated with the annotation @SuppressWarnings(value = {S1, ... , Sk}), then a Java compiler must not report any warning identified by one of S1, ... , Sk if that warning would have been generated as a result of the annotated declaration or any of its parts.
Unchecked warnings are identified by the string "unchecked".
The subsequent section on @Deprecation also mentions that these warnings can be suppressed with@SuppressWarnings("deprecation").


Valid Warning Types

The only two warning strings that are mentioned in the specification itself are "unchecked" and "deprecation". However, the Sun JDK uses a larger set of strings in the compiler. You can determine the current set by executing:
javac -X

which will show you (among other things) the valid settings for -Xlint.

For example, Sun JDK 1.5 shows:
  • all - suppress all warnings from this code
  • deprecation - suppress warnings from using deprecated code
  • unchecked - suppress warnings from an unchecked call or an unchecked cast
  • fallthrough - suppress warnings if a switch falls through without finding a valid case (and no default)
  • path -
  • serial - suppress warnings if a Serializable class does not define a serialVersionUID
  • finally - suppress warnings from return within a finally (which will ignore return with the try)

And Sun JDK 1.6 adds:
  • cast
  • divzero - suppress warnings if integer divide by zero is detected
  • empty
  • overrides
  • none

IDEs and static analysis tools typically support a large number of other possible values for @SuppressWarnings. These values correspond to specific static analysis checks performed by the IDE.


Eclipse

The Eclipse warning values for Eclipse 3.3 are documented in the JDT docs.
  • all - suppress all warnings
  • boxing - suppress warnings relative to boxing/unboxing operations
  • cast - suppress warnings relative to cast operations
  • dep-ann - suppress warnings relative to deprecated annotation
  • deprecation - suppress warnings relative to deprecation
  • fallthrough - suppress warnings relative to missing breaks in switch statements
  • finally - suppress warnings relative to finally block that don't return
  • hiding - suppress warnings relative to locals that hide variable
  • incomplete-switch - suppress warnings relative to missing entries in a switch statement (enum case)
  • nls - suppress warnings relative to non-nls string literals
  • null - suppress warnings relative to null analysis
  • restriction - suppress warnings relative to usage of discouraged or forbidden references
  • serial - suppress warnings relative to missing serialVersionUID field for a serializable class
  • static-access - suppress warnings relative to incorrect static access
  • synthetic-access - suppress warnings relative to unoptimized access from inner classes
  • unchecked - suppress warnings relative to unchecked operations
  • unqualified-field-access - suppress warnings relative to field access unqualified
  • unused - suppress warnings relative to unused code


IntelliJ



NetBeans



Examples

An example of specifying a single warning:

@SuppressWarnings("unchecked")
public void methodWithScaryWarnings() {
List rawList = new ArrayList();
List stringList = (List)rawList;
}

An example of using two warnings:
@SuppressWarnings({"unchecked","deprecation"})
public void methodWithScaryWarnings() {
callDeprecatedMethod();
}