“If a tree falls in a forest and no one is around to hear it, does it make a sound?“

Likewise if a software project is delivered and no one has looked at security, can it be said to be secure?

If a tree falls… by Dunc(an)

When a customer commissions Ibuildings for a new application, he usually has plenty of functional demands (I need it to do X and also Y and Z… oh and can I get A?).
And maybe some thoughts have been given to performance metrics, but security?

Well… it “needs to be secure”.

What is ‘secure’ anyway?

It is said, conveniently enough mostly by software engineers, that building software is perhaps one of the most complex activities that humans have ever undertaken.
Looking at some of the questions one might ask an engineer on secure coding, you get the idea that these software engineers may have a point:

• Have you encoded all output? What is output anyway? Is what we send to our own database output? And Redis?
• Have you filtered all input? What is input anyway? Is what we get from our own database considered input ? Is what we get from a third party news feed or SOAP service?
• Is every unsafe action protected from Cross Site Request Forgery?
• Is every AJAX call that requires authorisation protected from access by unauthorised users?
• Are all your expensive operations rate limited to prevent Denial Of Service attacks?
• Are passwords stored ‘securely’? Securely being salted (with user specific salts) Blowfish encrypted values with significant rounds?
• How safe is third party software used? Who applies security patches?

I would say ‘etcetera’ here, but it doesn’t quite cover how many questions one can ask of engineers when they build an application.

To help our engineers we currently do the following:

1. Hold regular Web Application Security workshops where we remind old staff and inform new staff of application threats.
2. Hold frequent code reviews, and will be working with the GitHub Pull Request system to make sure no unverified code makes it to master.
3. Have a Secure Software Specialist dedicate time to helping the company release secure software.

But even with that, I have a saying:

Repeat after me: “If it hasn’t been tested, it doesn’t work.” And: “If it hasn’t been documented it doesn’t exist”

— relaxnow (@relaxnow) February 2, 2010

Security isn’t a checkbox, it’s a dropdown

Remember all those questions we asked the engineer on secure coding?
Turns out engineers don’t have a fixed set of questions they ask themselves. Team Leads don’t have a specific set of questions they ask their engineers. Customers hire security auditors (like us) and they all have their own set of questions.

In order to help organisations come to an agreement on what should be the ‘minimal’ required set of questions to ask, several people got together and created the Application Security Verification Standard (ASVS) project and donated it to the Open Web Application Security Project (OWASP).

From the introduction:

The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications.

ASVS gives the customer, and us, a negiotable ‘Security Minimum’ that can be verified.

It defines 4 levels of rigor:

1. Automated verification, a ‘quick’ automated (dynamic and static) check of only of the custom code.
2. Manual verification, a ‘normal’ check, verify all custom code and security relevant third party code manually.
3. Design verification, a ‘business-critical’ check, verify all custom and all third party code.
4. Internal verification, a ‘life-or-death-critical’ check, every piece of code that touches the application (including build tools).

And 14 chapters:

1. Security Architecture Documentation, you have documented all requirements and third party components in your code… right?
2. Authentication, it’s okay to cheat with the OWASP Cheat Sheet.
3. Session Management, session timeouts are a good thing.
4. Access Control, if I upload a private picture, can only I access it?
5. Input Validation, rule number one.
6. Output Encoding, rule number two.
7. Cryptography, “Applications should always use FIPS 140-2 validated cryptographic modules, or cryptographic modules validated against an equivalent standard”
8. Error handling and logging, should someone get through your defenses, can you track what they did?
9. Data protection, how do you protect sensitive information?
10. Communication Security, have you properly implemented SSL?
11. HTTP Security, “a set of requirements that can be used to verify security related to HTTP requests, responses, sessions, cookies, headers, and logging”
12. Security Configuration, have you stored your configuration in a safe place?
13. Malicious Code Search, was anyone able to inject malicous code?
14. Internal Security, it should be hard to mess up.

Every chapter defines it’s own set of rules and the levels pick and chose from these (level 1 will only pick the first simple requirements from each chapter, while level 4 will require them all).

At Ibuildings we pick a level with the customer at the start of a project. So far, we haven’t seen too many medical or life-critical projects, so they tend to be level 1 or 2.
And we make sure to verify that the project complies before the final go-live.

Now let me make this clear, as an engineer myself, we don’t look at a requirement like:

V5.7 Verify that all input validation failures are logged.

and say “Well, that’s a 2B requirement that is. This project is Level 1 only, so no logging for this app!”.

Where feasible, engineers will always hold themselves to the highest standards.
But we certainly won’t rewrite a third party application to support this rule, unless the customer explicitly wants us too.

Security still is not a solved problem

While ASVS is a wonderful addition, it has it’s issues:

1. Verification and reporting, done to it’s fullest extent, can take a significant amount of time.
2. Verification rules are not specific enough in use of tools and techniques.
3. It is slightly outdated (2009).

The first and second issue are rather big issue for us. We’re commercial company making software for other (mostly) commercial companies. Budget is always an issue. Fortunately this is where automation and a bit of templating can come in quite handy!

It’s still early, but you can find a sneak peak of what we’re doing with ASVS at our GitHub repo: ibuildingsnl/ibuildings-owasp-asvs-report-generator (warning, still very alpha).
More on that later!

As for the third issue, ASVS 2.0 is in progress and looking for volunteers!

Tl;dr

Security is hard. We’re constantly improving, we already:

1. Give security workshops
2. Do code reviews
3. Have a senior engineer spend R&D time

And now we’ve added OWASPs ASVS, which is pretty cool, check it out!

Let us know how you’ve embedded Software Security in your Software Development LifeCycle in the comments below or on the PHP Security Technical Group.

PhoneGap to the rescue

In July 2011 Nitobi (now acquired by Adobe) released a stable version of a small library called PhoneGap. It’s main purpose was to close the gap between web- and native applications. This was achieved by wrapping web applications in a native app for each supported platform. Another feature to close the gap is to expose Javascript API’s for functionality which is otherwise only available to native applications.

From this day on PhoneGap gained more and more enthousiasm from developers around the world, and boosted the development of mobile browsers as people started to make use of the features HTML 5, CSS and Javascript have to offer. At the time of writing PhoneGap 2.3 has been released, and the basic PhoneGap implementation is an incubator project at the Apache Foundation with the name Cordova.

For people who are confused with the names; PhoneGap is Adobe’s implementation, Cordova is the Apache Foundation implementation. At this time it actually doesn’t matter what is being used. Both implementations are still in sync with eachother. In the future Adobe might decide to create commercial additions or additions which are based on their other products.

The pain of deploying with PhoneGap

Even though PhoneGap solves the problem of developing for multiple platforms, the deployment itself is still a painful process. You’d have to install the native SDK’s, tools and create a project for each platform in which you add the PhoneGap framework and your web-application. Next to that you’d have to invest time to investigate and stay up-to-date with the deployment requirements for each platform. This makes the deployment of these applications a tedious task that might even take weeks to get your application out there for all the supported platforms.

Adobe to the rescue

Adobe has seen the pain that developers and app publishers have with this way of deploying and they came up with a solution for this; a build farm in the cloud. They named it PhoneGap Build and after an extensive beta-period it is now a stable platform, ready for anyone to use. PhoneGap Build can be linked to your Github account or you can use an AdobeID to login to the service. One of the benefits of linking your Github account is that you can build your public projects (open source) for free! The free plan also includes 1 private project. So you can start test-driving PhoneGap Build without paying a single dollar. If you’re satisfied and like to add more private applications you can update your plan.

The main functionality is simple; insert your html/javascript application, let PhoneGap Build do it’s magic, and get a package for the native platforms which are supported. You can look at it as a conveyor belt in a factory.

Currently PhoneGap Build has support for iOS, Android, Windows Phone, BlackBerry, WebOS and Bada.

Getting started with PhoneGap Build

Once you’ve setup your Github account or Adobe ID account on the PhoneGap Build website you’ll be able to access your dashboard.

The first things you’ll want to do is adding your application code. PhoneGap Build will ask you to add a public repository from Github, or a private repository/zip file to create a private build project.
Once you’ve picked your project you can change the name in the next step and add a description to clarify what your app is about. When pressing the “Ready to build” button your first build will be initiated, and you can see the results in the bar beneath your project description.

We see icons having 3 colors, this quickly identifies the state of your builds:

• Grey: Your build is not finished yet, the page will be automatically updated when a build is finished.
• Blue: Your build has succeeded, you can download the native package
• Red: An error occurred, further action and a new build is required

The grey icons can be ignored for the time being, they will finish up at some point in time which usually translates to just a few minutes. The red’s are more of a concern, once we click the red icon we will see the detailed view of the project where we can inspect further.

This is where PhoneGap Build really shines, it shows you exactly why your build has failed and provides you with a link on how to possibly resolve the issue. From here on you can work your way through the errors, up to the moment where the builds for your applicable platforms are all blue.

From within the detail view you can fine-tune the metadata settings for your project (like the project icon, package name, package version etc) or add collaborators if you’re working on an app with a team, this is all pretty straight forward.

Distributing the build

Once you’ve set up your project and all applicable keys are in place, you can start distributing your app. There are 2 types of distribution which need to be taken into account; development distributions and public distributions.

The development distributions can be used to test your applications on physical devices, or to showcase the state of the product to your customer. To setup the devices you’ll need to setup the proper keys and settings as you would when building a native application. There is no silver bullet to circumvent these rules created by the platform manufacturers. Once you’ve setup the proper keys or device settings you can open the PhoneGap build dashboard and scan the QR-code with your favorite scanner on your testing device. The application installer will now launch and place the application on your device. No cable connections or desktop applications are required, which makes it super easy to load your test build.

Next to that there is also a link you can share to testers, or you can visit the PhoneGap build dashboard with your phone, which uses a responsive design, and use the install-button from there. This easy to use functionality is a huge time saver.

Just click on one of the platforms icons and the package will download to your computer. Unfortunately like with setting up the test devices there is also no silver bullet to send these packages directly to an App Store. Who knows what the future might have in store for us, but up until today this process is still bound to the platform manufacturer’s system.

Advancing your build with a config.xml

Usually when working on a small project the information from the Getting started should be enough. But once you start building larger projects you might want to fine-tune your builds further and add a configuration to your source-code repository.

You can do this by adding a config.xml file to your project root directory which conforms to the W3C Widget Specification. The PhoneGap team has already created a boilerplate file to get you up and running:

https://gist.github.com/5063962

This sets up the basic project just like you would after reading the getting started. The real magic is happening in this file when you’re having specific deployment requirements, like “Do not show the default spinner when loading the app on iOS” or “My application is Jelly Bean specific for Android”.

No iOS splash screen spinner

https://gist.github.com/5064255

Only build for Jelly Bean

https://gist.github.com/5064262

There are many options you can explore, all of these are documented at http://build.phonegap.com/docs/config-xml

In conclusion

PhoneGap is a wonderful way to make your web applications available through app stores and marketplaces, and PhoneGap Build is a great addition to the tool. It helps you not to invest time on repetitive tasks when creating builds, but to actually spend your precious time on development and distribution.

In this session, Tommy Maintz will guide you through building an HTML5 mobile web application using the latest release of Sencha Touch 2.

If you want to have access to the full Dutch PHP Conference & Dutch Mobile Conference content before the official releases you can subscribe to our iTunes podcasts.

• DPC podcast
• DMC podcast

The “it works on my machine” mentality has resulted in numerous face palm moments. This is even more painful when a your app is under heavy load due to a marketing campaign.

With some minimal code changes and some smart utilities, you can maximize your scalability and performance. Keywords: Varnish, PHP-FPM, Nginx, APC, CDN, Gearman, Memcached and a proper server setup.

I’ll show you how you can make a slow app with a crappy code base go mighty fast on one and even multiple servers. The focus of this talk is to cure first and eventually learn and prevent.

If you want to have access to the full Dutch PHP Conference & Dutch Mobile Conference content before the official releases you can subscribe to our iTunes podcasts.

• DPC podcast
• DMC podcast

Business owners have woken up to the reality that the web is increasingly consumed on the move. Product owners are demanding new mobile sites that must be released yesterday! You manage an established online business, now you need to move into the mobile market. How do you take your existing business into a mobile domain? Does the entirety of your current business model need to exist in the mobile environment? Or is there a killer mobile app hidden within your existing product? This talk will walk through ten considerations that you must make when moving your online business to a mobile audience. Using a case study from a web startup transitioning to the mobile market, we take a guided tour through the challenges encountered and how you can avoid them in your business.Throughout this session, we will examine the finer points of the mobile development process we wished we had considered in advance. Learn how the user experience evolved beyond the initial business requirements through prototypes and testing. Discover how the legacy architecture was not suitable for mobile operations and the big infrastructure decisions that resulted. Witness our decision making process that led to the final solutions.Laid bare in this talk is the entire mobile development process as we experienced it, distilled down to ten useful pointers for you to take away.

If you want to have access to the full Dutch PHP Conference & Dutch Mobile Conference content before the official releases you can subscribe to our iTunes podcasts.

• DPC podcast
• DMC podcast

Creating a good, useful and functional API for your application can be one of the most difficult parts of a project. With more and more things becoming API-powered, it’s important to plan well and provide what the user expects. I’ll look at some principles you can follow to make sure the API you write is the right one, both from the developer perspective and what you, as a user, should expect of a quality web service API.

If you want to have access to the full Dutch PHP Conference & Dutch Mobile Conference content before the official releases you can subscribe to our iTunes podcasts.

• DPC podcast
• DMC podcast

CocoonJS is a native wrapper for HTML5 canvas based applications/games.Without any code changes and thanks to its OpenGL canvas bindings CocoonJS is able to execute you applications with almost a 1000% performance boost.CocoonJS offers native iOS and Android deployment environment. It is highly focused on monetization since applications deployed in CocoonJS have out-of-the-box Ad networks and tracking systems integration. Other features like asynchronous websockets, localStorage, facebook integration, etc. are available too. All this magic is achieved directly, without cross-compilation processes or being limited to custom APIs.

If you want to have access to the full Dutch PHP Conference & Dutch Mobile Conference content before the official releases you can subscribe to our iTunes podcasts.

• DPC podcast
• DMC podcast

Continuous Integration has typically been a practice only performed by companies who want that piece of mind for their client software, but does it need to be like this?

Travis CI is a continuous integration service for the open source community. We make testing OS projects dead simple and fun. But most importantly, we help improve code quality for large projects like Doctrine2 and symfony, to smaller libraries like FOSRest.

The vision behind Travis CI is to become for builds what PEAR is for distributing libraries.

In this talk Josh, one of the core members of the Travis CI team, will introduce you to the vision behind Travis, the how it is implemented, and why it matters to everyone in the OS community.

If you want to have access to the full Dutch PHP Conference & Dutch Mobile Conference content before the official releases you can subscribe to our iTunes podcasts.

• DPC podcast
• DMC podcast

The web as a mobile platform

The web has been a great place on desktops and laptops for quite some time, but with a booming growth of mobile devices like tablets and smartphones, the internet has become increasingly more interesting on these devices as well. Building mobile apps for the web has some advantages when compared to native development, before we start with Sencha Touch 2 we will take a look at these advantages.

If we look at 3 popular platforms there are a few distinctions which we need to keep in mind if we want to develop native applications for them:

As you can see in the table above there are a lot of dependencies which require a lot of different knowledge which makes it expensive and bug-sensitive to create the same application for all the platforms. Web applications have multiple advantages to overcome these issues:

• Available through the web, so no app store submissions and reviews are required. This also makes your app immediately available when you require it.
• Platform independent, the app can be used on any platform you want to support. In the end it all boils down to supporting browsers.
• You have complete freedom over the user interface. If you want to create an app-like experience you can mimic the UI elements you like best from the native world or you can create your own unique branding.
• Webapps can still be wrapped as native apps to push to the different app stores, options for doing this include Sencha Cmd and Adobe’s Phonegap (or the open source base implementation called Apache Cordova).

To achieve the goals mentioned above here you can make use of many web application frameworks, in this post we will focus on one of these; Sencha Touch 2. It has some advantages that make it a very strong framework for many business cases:

• Very strong at building applications instead of shiny websites
• All business logic is implemented using pure Javascript
• It is a touch-enabled framework, which makes it a premium choice for touch-enabled devices
• It has an (S)MVC pattern to have a good separation of concerns
• It is based on the well known ExtJS 4 framework
• Excellent documentation

Getting started with the Sencha SDK Tools

This article is based on Sencha Touch 2.1.0 RC2 and Sencha Cmd v3 beta

Sencha offers a great command line tool to get you up to speed very quickly, once you have downloaded and installed Sencha Cmd and the Sencha Touch 2 framework you can go to the framework’s folder and run the following command:

sencha generate app MyAwesomeApp ~/MyAwesomeApp

This will generate a new application for you with the namespace MyAwesomeApp in your home-folder. To view the generated app, you can use any Webkit based browser to open the generated index.html in your ~/MyAwesomeApp folder.

If we open up a file browser to investigate what has been generated we see a whole lot of files and folders, let’s dissect these and see what they do:

• [directory] app: This is where the code of your application lives, it contains the views, data packages, profiles and controllers. In the rest of the article we will have a more thorough drill down of these folders.
• [directory] resources: Here we will see static resources like the styling, images, splashscreens and icons for our app.
• [file] app.js: The app.js file is the main bootstrap for your application, it determines the app name, icons, required classes and initiates the launch.
• [file] *.json: In the main folder there are 2 JSON files, these are used for building the app. Once your app is ready to go live you can review these files or extend them to get everything you require in the distributable package.
• [file] index.html: The main index file, it shows the preloader and initiates the app.js
• [directory] touch: This directory contains the Sencha Touch SDK, do not touch this directory, whenever you want to upgrade the SDK of your project this directory will be overwritten and changes will get lost. If you want to customize SDK components it’s better to add in your own library directory and extend the objects from the SDK.

Creating a user interface

To make your app functional you will need to interact with your user, Sencha Touch 2 comes packed with many user interface components. These include:

• Containers
• Panels
• Tab Panels
• Carousels
• Lists
• Forms
• Toolbars

These components are all highly configurable which makes them very powerful to quickly create a functional UI.

To get started with an example we will create a file in the app/view/ directory of our application, and we will call it Pictures.js
This view will be a picture gallery shown as a gallery which people can interact with by swiping the images. We have placed several images in the resources/images/ directory which we are going to use as the content for our gallery.

The content of this file will be as following:

Ext.define('MyAwesomeApp.view.Pictures', {
   extend: 'Ext.carousel.Carousel',
   xtype: 'employeescarousel',
 
   config: {
       items: [
           { html: '<img src="resources/images/1.png">' },
           { html: '<img src="resources/images/2.png">' },
           { html: '<img src="resources/images/3.png">' },
           { html: '<img src="resources/images/4.png">' },
           { html: '<img src="resources/images/5.png">' }
       ]
   }
});

If we break down this code we see just 1 method call; Ext.define. This method creates a new class in the Sencha class system. The first argument is the name we want to give to our class, this name starts with MyAwesomeApp.view so the autoloader will detect it as an application class which is stored in the view directory. The last part of the class name is the actual name of the class which maps to your .js file. The second argument is an object which defines our class.

Since we want to use the carousel component to swipe through our content we extend the Ext.carousel.Carousel class and give it an xtype. The xtype defines the unique name for the component, keep in mind though that one components can have multiple instances so it is not comparable to the id-attribute of an HTML element.

Finally we add the configuration for our own carousel by defining the items in this carousel as an array of objects. By default a new item will be defined as a Panel-component. For our panel components we define it’s content by feeding it plain HTML code.

Now that we have defined our view we need to make our app aware that this view will be needed for the application. To achieve this we open the app.js in our root folder there we will find a key named views which is an array of strings, at the moment it only contains the generated ‘Main’ we modify the specification by adding our ‘Pictures’ view in it like this:

   views: [
       'Main',
       'Pictures'
   ],

The final step to make the defined and initiated view available to our user is attaching it to one of the available components. If you have already taken a look at the generated application you will see that it contains a tab panel, to make our picture gallery available to our users we are going to add a new tab on this bar which will show the picture gallery view. For this we open the app/view/Main.js file and edit the configuration of the tab panel with a new item:

Ext.define('MyAwesomeApp.view.Main', {
   extend: 'Ext.tab.Panel',
   xtype: 'main',
   requires: [
       'Ext.TitleBar',
       'Ext.Video'
   ],
   config: {
       tabBarPosition: 'bottom',
 
       items: [
           { title: 'Welcome'...},
           { title: 'Get Started'...},
           {
               title: 'Employees',
               xtype: 'employeescarousel',
               iconCls: 'photos1'
           }
       ]
   }
});

Do not just copy and paste this example, for clarity’s sake we have shortened the first 2 items of the configuration. Here we configure the title for the new tab, we tell it that the tab contains our newly created xtype employeescarousel and we attach a class for our icon to the tab (creating these icon classes will be explained later on).

Once we open up our app now we will have a new tab with the view we just created.

Congratulations, you have just created your first mobile web app! But of course we can do a lot more, let’s dive into the deep.

Taking control

As developers we like to have control over what is happening. Sencha Touch 2 offers various places to do this, but to keep your code clean, the best options are the bootstrap and the controllers.

Bootstrapping is a way to run code while the application is still booting and not yet used by our user. The bootstrap in Sencha Touch 2 is defined as a method called launch in your controllers. The generated app already contains a bootstrap in the app.js in the root folder. It is good to keep in mind that classes defined as controllers and profiles can also contain a launch method which are being run as bootstrap, the bootstrap in these files get executed before the one defined in your main app file.

Let’s see what will happen if we ad a simple alert box to our application once it gets booted by modifying the launch method of the app.js in our root folder:

    launch: function() {
       // Destroy the #appLoadingIndicator element
       Ext.fly('appLoadingIndicator').destroy();
 
       // Initialize the main view
       Ext.Viewport.add(Ext.create('MyAwesomeApp.view.Main'));
 
       // Taking control in our bootstrap
       Ext.Msg.alert('Welcome', 'Welcome to my first awesome app!');
   },

In our example we have added the Ext.Msg.Alert which takes a title and a message as it’s arguments. When we reload our app in the browser we get an alert message component which shows this text. So as we can see, we can already take control before the user has done any interaction with our application.

Most of the times we will also want to take control of the events like user interactions with the app (e.g. tapping a component). In our example we are going to change the code for our html panels in /app/view/Pictures.js into a more specific type of component so we can interact with it in an easy way in the next steps:

    {
        xtype: 'img',
        src: 'resources/images/1.png'
    },

The next step is to open a terminal and go to the directory where we generated our app, in our example this is ~/MyAwesomeApp and we run the following command:

sencha generate controller PictureTab

This creates a new controller skeleton which can, as the name implies, control various events. It also adds a reference for this controller to the app.js. As we open up the controller file in app/controller/PictureTab.js we can see the predefined config key. The config consists of 2 properties:

• refs: attaches a key to all components that match the ComponentQuery defined for it. A ComponentQuery is a simple query-type within Sencha Touch to select components rather than HTML elements.
• control: specifies the events and attached actions for these events.

Let’s have a look how we can make the application trigger an event once we tap one of the pictures.

   config: {
       refs: {
           picture: 'img'
       },
       control: {
           'picture': {
               'tap': 'onPictureTap'
           }
   }

In the refs we have placed the line picture: ‘img’ this defined that every img xtype in our views is referred to as picture in our controller.

In the control section we make use of this reference and attach an object with the property ‘tap’: ‘onPictureTap’ this tells the application that we want to take control once an image is tapped. The definition of this control will be placed in the onPictureTap method inside the controller. This brings us to the final step which is implementing the definition. In our controller object definition we add the onPictureTap method. As an example we will show an alert box to the user, which tells the user what the location of this image is. If you’re not bootstrapping anything this is also a good opportunity to remove the launch method.

   onPictureTap: function(imageComponent) {
       var src = imageComponent.getSrc();
       Ext.Msg.alert('Event handled', 'You tapped ' + src);
   }

Note that the first argument of this function is the component instance which triggered the event. This way we can use the component’s methods to access it.

Once we reload the app in our browser and tap a picture in the carousel we should see a message with the name of the image in it.

Data binding

Now we know how to control the applications our next concern is working with data. Sencha Touch 2 provides a very complete data handling package which we will utilize in this chapter.

In the image above we can see the main components included in the data package. The Model is a single entity of a ‘thing’ in your application (like a product, user or calendar item), it defines the blueprint of this entity. A Store is a collection of entities commonly used to propagate a list. The Proxy defines the read and write gateways to the data source which holds the data.

Model

If we want to start adding data to our application we will need to define the blueprint of our model first. The model will have certain properties with a data type attached to it (if no datatype is defined Sencha Touch 2 will automatically assign one, this is not advised as this can lead to unexpected results). Let’s define a blueprint for an employee by running the following command from our application root:

sencha generate model Employee id:int,name:string,imgsrc:string

This will create a new file in app/model/ called Employee.js which has the properties we’ve just defined as a key named fields in the object’s config.

Store

Creating a store is not part of Sencha Cmd, just like views, therefor we need to create a new store manually. This gives us a good opportunity to review how we manually add components to our project.

We start off by creating a file called Employees.js in the app/store/ directory. In this file we define the following class:

Ext.define('MyAwesomeApp.store.Employees',{
   extend: 'Ext.data.Store',
 
   config: {
       model: 'MyAwesomeApp.model.Employee',
       autoLoad: true
   }
});

In this class we extend a basic store (Ext.data.Store), which is an abstract implementation. Then we configure the store by telling it that it needs to use the MyAwesomeApp.model.Employee model as the blueprint for it’s data. The second configuration option autoLoad tells the application that the data needs to be loaded upon opening the application.

The final step for defining our store is adding it to our app.js in the root directory of our application. There you add a new property called stores which will define an array of strings with the stores which we are going to use, of course we start off with our Employees store.

   stores: [
       'Employees'
   ],

Proxies

The final addition before we can start pulling data and use it in our application is a proxy. Proxies can be attached to both stores and models as a config item. The most common case is that the store will know it’s model class and that the model will have the proxy attached. This gives us the power to use a single model with the proxy rather than having to initiate a collection of models.

The proxy will consist of 2 main items which are a reader and a writer. The scope of this article will just show the reader since they are very similar.
Our proxy will read a static file on the server (resources/employees.json) in our resource folder using AJAX, the following config in our model (app/model/Employee.js) defines this proxy in it’s config:

    proxy: {
        type: 'ajax',
        url: 'resources/employees.json',
        reader: {
            type: 'json',
            rootProperty: 'employees'
        }
    }

Sencha Touch 2 comes packed with several proxy-, reader- and writer-types, for this example we are using the proxy type ‘ajax’ and assign the url of the ajax resource which is a JSON file. The next item is a reader which is capable of reading ‘json’ and it inspects the file for a root property named ‘employees’ which will contain an array of (suprise, surprise) employees.

Publishing data through the UI

Once we have the proxy and json file in place we still need a UI element to show the data.
For this we are going to create a new view which will utilize the list component. We create a new file in /app/view/ and call it EmployeeList.js and define our new class in it:

Ext.define('MyAwesomeApp.view.EmployeeList',{
   extend: 'Ext.dataview.List',
   xtype: 'employeeslist',
 
   config: {
       store: 'Employees',
       layout: 'fit',
       styleHtmlContent: true,
       itemTpl: '<h3><img src="{imgsrc}" style="max-height: 40px;">{name}</h3>'
   }
});

The difference we see here between the view we created before and this one is that we extend an other type of component, the list component, and that this component takes different config parameters. What we configure here is the store which points to our Employees store we just created, and the itemTpl. This itemTpl represents how 1 item in the list is supposed to look, the data from the model is added in by placing the property we want to show within curly braces.

Once we have our new view in place we add it to the app.js’s view-array as we did before and we create another tab in our app/view/Main.js

    {
        title: 'List',
        xtype: 'employeeslist',
        iconCls: 'photos1'
    }

As we can see this tab will refer to the xtype of our newly created EmployeesList class.
When you reload the app now you can see a new tab in the tab bar which will open up a list instance with all the data in it.

If you want to practice with all we’ve learned up to now it would make sense to attach a non-static data source (like a web-service) and create a simple CRUD app.

Device profiles

Sometimes you can’t get around implementing different features for different type of devices, the most common example is that tablets usually have a whole lot more screen real estate than smartphones. Luckily Sencha Touch 2 has the ability to implement profiles so we can easily extend on existing classes. A good tip is to work from the smallest form factor to the larger ones you’d like to implement.

To start working with profiles we can use the Sencha SDK Tools again with the following command:
sencha generate profile Tablet

And we do the same for a phone profile:
sencha generate profile Phone

This creates the new classes in the app/profile/ directory. The next thing we need to do is specify when a device is a tablet and when a device is a phone. Sencha Touch will look for a method in the profile which is called isActive, this method needs to return a boolean value so the framework knows if the defined profile needs to be used at runtime.

In this example Sencha Cmd detected what we wanted to do and the isActive method is already implemented. If the name of the class isn’t that obvious the isActive method needs to be modified.

Now that our app is aware of the different profiles we can start creating implementations for it. By default the autoloader will append the namespace with the profile name before the actual class name. To clarify this let’s create different views for our list.

We create a new controller in the directory app/controller/tablet called EmployeesList.js and enter the following code:

Ext.define('MyAwesomeApp.controller.tablet.EmployeesList', {
   extend: 'Ext.app.Controller',
 
   config: {
       refs: {
           list: 'list'
       },
       control: {
           'list': {
               'itemtap': 'onItemTap'
           }
       }
   },
 
   onItemTap: function(listItemComponent) {
       Ext.Msg.alert(
           'Tablet info',
           'On a tablet you will get a large info view'
       );
   }
});

Please take note of the class name which now contains tablet in it’s namespace.

The final step is making the app aware of this new class, this time we do not add it to the main app.js but the Tablet.js in the app/profiles/ directory:

controllers: ['EmployeesList'],

If you open up the application on a tablet device now (or a tablet device emulator/simulator) the
defined event will run.

When using a phone emulator you can see that nothing happens when you tap a list item. Now would be the time to practice by implementing a controller which handles these events just for phones.

Theming and styling your application

The default css-theme that comes with Sencha Touch 2 has been heavily influenced by iOS. The good part is that it is also highly customizeable as it is built using Compass (an extension to SASS). You can get the compass compiler running by using the gem installer:

gem install compass

How Compass works is outside of the scope of this article, but for brevity we will highlight a few important things;

• The extension of a compileable file is .scss
• With the command compass compile the changes will be compiled to a normal css file which browsers can interpret.
• With the command compass watch the files in the current directory will be compiled as soon as changes are saved to them.

You may have noticed that in an earlier stage we added an iconCls property but the icon never showed up in your tabbar. This is where we are going to fix that, open the app.scss file under the resources/sass/ directory and add the following line:

@include pictos-iconmask('photos1');

This is a built in function of the Sencha Touch 2 framework to add classes with masked icons. Compile the scss file and the icon should be visible now.

In addition you can also add normal css to this file and it will be compiled into the resulting css file as well.

Some final tips

As you can see Sencha Touch 2 is simple to use, yet very powerful to get your requirements done. Once you start creating your own implementations make good use of the very clear documentation at http://docs.sencha.com.

Always make use of Sencha Cmd whenever it supports what you are doing, it takes away the human error for various things which are easily forgotten.

If you feel uncomfortable with Javascript you can also get Sencha Architect 2 which is an easy IDE for setting up your apps. Eventually you will be expected to do some Javascript so get a book on the subject in the meantime.

Always stay away from putting methods in your views. Even though it is tempting and sometimes the documentation points out the possibility to do so, it is not going to help you. Once you start bug fixing or revisiting your project it will get hard to understand why certain events are happening as they do. Always use the controllers and bootstrapping to define functionality.

Mobile browser performance is challenged by bandwidth, battery, and memory constraints. Slow loading and reacting sites create bad user experiences. Sites that drain batteries or crash the browser are infuriating. Porting a web application designed and developed for desktop devices—devices with virtually unlimited memory, and literally unlimited power (they’re plugged in, not running on battery) in many cases just doesn’t work. By understanding mobile limitations and keeping mobile in mind throughout the development process you can create more responsive, faster downloading, less battery consuming applications.In this session we assume you understand general web performance optimization, and instead focus on best practices required to improve performance on mobile devices. Instead of just covering how best to get a site onto a device, you will learn how to make sure it works optimally once it is there. Topics include HTML5, CSS3, images, JavaScript and the DOM.We’ll cover mobile device limitations that often lead to poor user experiences as well as tips and techniques to prevent these trouble spots from arising.

If you want to have access to the full Dutch PHP Conference & Dutch Mobile Conference content before the official releases you can subscribe to our iTunes podcasts.

• DPC podcast
• DMC podcast