Build a login form for your mobile app with DHTMLX Touch

In this introduction to open source JavaScript framework DHTMLX Touch it

explains how you can implement a login form for a mobile web app and send form values to the server with Ajax

DHTMLX Touch is an open source JavaScript framework for building mobile web apps. Providing necessary API and ready-to-use UI controls, DHTMLX Touch helps developers to create responsive HTML5 interfaces for touch devices. As an example we're going to create a web login form for mobile.
A login form is an essential component of modern websites and applications. Since the web is now moving to mobile devices, it’s important to have all parts of the web interface touch-ready and looking good on small screens.

This tutorial describes the basic steps for implementing a user login form for a mobile web app built with DHTMLX Touch.

In addition to other goodies, DHTMLX Touch already includes a form control that's perfect for our task. We will go through the complete process of creating and designing the form, sending form values to the server with Ajax, and processing the response.

The above picture shows the final look of the login form we’re going to build. Continue reading and you'll see that the layout and appearance of the form can be easily changed to meet your design requirements.

With the variety of server side technologies, you can choose which one to use on the backend but we’ll omit this part and focus only on the client-side implementation involving HTML, CSS, and JavaScript. If you’re not familiar with the methods of user authorisation yet, you can find related articles on the web.

Getting started

To start, we need to create a new HTML5 document and include the DHTMLX Touch library in it. Download the latest version of DHTMLX Touch. The .zip package includes all the necessary files and demos. Extract the content and copy all the files from the ‘codebase’ folder in the project directory.

On the development stage it’s better to use the debug version of the files as it helps you catch possible errors and get some additional info. When the page is ready, you can replace the debug version with the files that contain compressed code to reduce the weight of the library.

1. <!DOCTYPE HTML>
2. <html>
3.     <head>
4.         <title>DHX Touch: Login Form</title>
5.         <script src="libs/touchui_debug.js" type="text/javascript"></script>
6.         <link rel="STYLESHEET" type="text/css" href="libs/touchui_debug.css">
7.     </head>
8.     <body>
9.     </body>
10. </html>

Don’t forget to specify the doctype. It’s needed so the browser reads this document as HTML5. When the DHTMLX Touch library is attached to the page, we can start creating a login form.

Building a form

First we’ll create a form in default skin, and then define form layout, styling, and other features ilater. As a standard login form, our form will include four elements:

Two text fields:

• Login field
• Password field

Two buttons that are located in the same line:

• Login button
• Register button

Let’s create a form layout.

DHMLX Touch uses the “view” term for the UI components and elements. There are five views in our layout which include “form” and its four fields, text fields and buttons. Each view is described by a JSON object. And all objects of the layout need to be gathered in one, depending on the views hierarchy.

Our “form” view will contain the “elements” property with the array of form fields. However, views in elements collection are laid out vertically, one below another. For this reason, we use "cols" array to locate two buttons in the same row (in columns).

Here is the layout:

1. <script>
2.     var form = {
3.             view:"form", elements:[
4.             { view:"text", label:"Login", name:"login", labelWidth:90 },
5.             { view:"text", type:"password", label:"Password", name:"password", labelWidth:90 },
6.             {
7.                 type:"clean",
8.                 cols:[
9.                     { view:"button", type:"form", label:"Login" },
10.                     { view:"button", type:"round", label:"Register" }
11.                 ]
12.             }
13.         ]
14.     };
15. </script>

To create the form we call the dhx.ui() method with this object.

1. <script>
2.      dhx.ready(function(){
3.         dhx.ui.fullScreen();
4.         dhx.ui(form);
5.      });
6. </script>

Note that we put our code within the dhx.ready() method. This approach allows us to execute the code when page sizes are set (similar to window.onload). We also call fullScreen(), which allows the page and its components to be displayed in the full-screen mode.

Once we’ve got the form with the default styling (see picture below), we can move on and enhance the form with the proper layout and styling.

Defining form layout

The DHTMLX Touch framework provides a flexible way to position UI elements on a page. Each element can be defined as a row in "rows" collection or a column in "cols". To build complex structures, you can put rows into a column or columns into a row. This approach allows developers to lay out elements any way they like. We will use "rows" and "cols" to position the form elements to build a login view.

Looking at the picture of the final form it’s not hard to guess what elements can be described by rows and columns. We can separate four rows and three columns in the third row:

• The first row is a toolbar with title
• The second row is just empty space
• The third row includes three columns:
  o    empty column on the left (15px width)
  o    the form itself
  o    empty column on the right (15px width)
• The forth row is an empty space, which is two times higher than the second row

Now we’re building this form using DHTMLX Touch:

1. <script>
2.     var form = {
3.         /*created in step 2*/
4.     };
5.     /*toolbar*/
6.     var toolbar = {
7.         view:"toolbar", elements:[
8.                 { view:"label", label:"Member Area", align:"center" }
9.         ]
10.     };
11.     var loginView = {
12.         type: "clean",
13.         css: "layout",
14.         rows:[
15.             toolbar,
16.             { gravity:1 },
17.             {
18.                 type:"clean",
19.                 cols:[
20.                     { width:15 },
21.                     form,
22.                     { width:15 }
23.                 ]
24.             },
25.             { gravity:2 }
26.         ]
27.     };
28.     dhx.ready(function(){
29.         dhx.ui.fullScreen();
30.         dhx.ui(loginView);
31.     });
32. </script>

We’ll get a login form with the default styling and the layout we’ve defined:

The next step will be applying a new style and adding custom design to the login form.

Form styling

To make our form look like the final screenshot we need to do the following:

• Change toolbar styles
• Set overall background image for all views (elements)
• Set form styles

We will start with the toolbar styles. To apply a new CSS class for a view, we need to set the class name in the CSS property. Let's set it for the toolbar:

1. <script>
2.     var toolbar = {
3.          view:"toolbar", css:"toolbar", elements:[
4.             { view:"label", label:"Member Area", align:"center" }
5.         ]
6.     };
7. </script>

The code which defines styles for the toolbar with labels is the following:

1.  /*toolbar*/
2.     .toolbar{
3.         background-image:url(../images/toolbar.png);
4.         background-repeat:repeat-x;
5.     }
6.     /*label in toolbar*/
7.     .toolbar .dhx_el_label div{
8.         font-family:Gergia;
9.         font-size:30px;
10.         color:#636363;
11.         text-shadow: 0 1px 1px #d9d9d8;
12.     }

This is how the toolbar on the top should look now:

To set one background image for all elements, we’ll set it for rows collection and make the other views transparent:

1. <style>
2.     ...
3.     /*sets the overall background*/
4.     .overall{
5.         background: url(../images/bg.png);
6.     }
7.     /*makes all views inside overall container transparent*/
8.     .overall .dhx_view{
9.         background-color:transparent;
10.     }
11. </style>
12. <script>
13.     ...
14.     var loginView = {
15.         css: "overall",
16.         rows:[
17.             ...
18.         ]
19.     };
20.     ...
21. </script>

Both backgrounds for toolbar and a web page should now appear like this:

Next, we change the style of the login form: set background, border radius and shadows. We’re adding this code on the page to define the appearance of the form:

1. <style>
2.     .form{
3.         background-image:url(../images/form.png);
4.         -moz-border-radius: 10px;
5.         -webkit-border-radius: 10px;
6.         border-radius: 10px;
7.         -moz-box-shadow: inset 0 -1px 2px 2px #444141;
8.         -webkit-box-shadow: inset 0 0 2px 2px #444141;
9.         box-shadow: inset 0 -1px 2px 2px #444141;
10.     }
11.     ...
12. </style>
13. <script>
14.     var form = {
15.         id:"loginForm", css:'form', view:"form", height:135, elements:[
16.             ...
17.         ]
18.     };
19. </script>

We're almost done. Move on and change the design of input fields:

1. /*input outer container*/
2. .dhx_el_box{
3.     background:#ffffff !important;
4.     -moz-box-shadow: 0px 1px  #d2d2d, inset 0px 2px 2px #a6a6a6;
5.     -webkit-box-shadow: 0px 1px #d2d2d2, inset  0px 2px 2px #747981;
6.     box-shadow: 0px 1px #d2d2d2, inset 0px 2px 2px #747981;
7.     border-top:0px !important;
8. }
9. /*text inputs*/
10. .dhx_inp_text{
11.     border-radius: 0px;
12.      -webkit-appearance: none;
13.     background:transparent;
14. }

Finally, we add the required style to our form buttons. We need to set a border radius for both buttons and set a new background colour for the button "Register".

1. /*Login (type:"form") and Register (type:"round" buttons)*/
2. .dhx_el_formbutton input, .dhx_el_roundbutton input{
3.     -moz-border-radius:5px;
4.     -weblit-border-radius:5px;
5.     border-radius: 5px;
6.     -moz-box-shadow: none;
7.     -webkit-box-shadow:  none;
8.     box-shadow:  none;
9. }
10. /*Register button*/
11. .dhx_el_roundbutton input{
12.     background: -webkit-gradient(linear, left top, left bottom, from( #a0b4ce ),to( #5e6e80 ));
13.     background: -moz-linear-gradient(top,  #a0b4ce,  #5e6e80 );
14.     border-color:#5a697b #5a697b #243242;
15. }
16. /*Register button, touched state*/
17. .dhx_touch .dhx_el_roundbutton input{
18.     background: #8496ad;
19. }

After these modifications, we get the design of the login form exactly the way we defined it in the beginning of the tutorial.

Sending Ajax request and processing the response

Once we've created a form that looks and feels native on iPhone and Android, we can now learn how to send the form data using Ajax and show the app's welcome page after a successful login.
We'll make the Ajax call on "Login" button click. We define the function that will be called in the "click" property of the "Login" button:

1. <script>
2.    var form = {
3.         id:"loginForm", css:'form', view:"form",height:135, elements:[
4.             { view:"text", label:"Login", name:"login", labelWidth:90 },
5.             { view:"text", type:"password", label:"Password", name:"password", labelWidth:90 },
6.             {
7.                 type:"clean",
8.                 cols:[
9.                     { view:"button", type:"form", label:"Login", click:"login();" },
10.                     { view:"button", type:"round", label:"Register" }
11.                 ]
12.             }
13.         ]
14.     };
15. </script>

And here is the login() function that we've just set:

1. <script>
2.     function login(){
3.         dhx.notice({ delay:750, message:"Checking ..."});
4.         var formData = $$('loginForm').getValues();
5.         dhx.ajax().post("login.php", formData, afterCall);
6.     }
7. </script>

Here is the explanation of the above function line by line:

1. The first line shows "Checking ..." pop-up message within 750 ms
2. With the second line, we get form values
3. And the last line sends the form data in "POST" Ajax request to server-side script

The first parameter of the dhx.ajax().post() method is a string containing the URL to which the request is sent (the server-side script which will process the login request).

afterCall parameter is the function that will be called after the response is received. And if the response is JSON data: { result:'success'} or { result:'fail'}, this function can look like:

1. <script>
2.     function afterCall(text, xml){
3.         var data = dhx.DataDriver.json.toObject(text,xml);
4.         if (data.result == "success"){
5.             dhx.alert("You have been succesfully logged in!");
6.         } else{
7.             dhx.alert("The login and password are incorrect!");
8.         }
9.     }
10. </script>

In this function, dhx.DataDriver.json.toObject creates a JSON object from the response data. Then it validates the "result" of the object and shows the corresponding alert.

When a user is logged in, they should be directed to a new “Welcome” page. To add this new page, we need to modify the structure of our app and add a new view. For example, we'll show an image as a welcome screen:

1. <script>
2.     var loggedIn =  {
3.         id:"loggedIn",
4.         template:'<img src="../images/logged_in.png">'
5.     };
6.     var app = {
7.         cells:[
8.            loginView,
9.            loggedIn
10.         ]
11.     }
12.     dhx.ready(function(){
13.         dhx.ui.fullScreen();
14.         dhx.ui(app);
15.      });
16. </script>

To show the view from "cells" collection, we need to call show() method for it. We add it to afterCall function:

1. <script>
2.     function afterCall(text, xml){
3.         var data = dhx.DataDriver.json.toObject(text,xml);
4.         if (data.result == "success"){
5.             /*shows "loggedIn" view*/
6.             $$("loggedIn").show();
7.         } else{
8.             dhx.alert("The login and password are incorrect!");
9.         }
10.     }
11. </script>

That's it! Our login form is ready and I hope you’ve learned how to create a custom login form for your next mobile web app or site! You can do a lot more with DHTMLX Touch, and it’s a framework that's fairly easy to learn. If you want to get some new experience in web development for mobile devices, just give it a try.

The developer's guide to mobile frameworks

No matter how you measure it, mobile computing is growing astronomically. Daily usage, smartphone penetration, cellular subscriptions, search traffic, ad impressions, app sales: everything is up. It seems inevitable that mobile devices will overtake traditional desktop and laptop computers as our primary computing platform, perhaps in the relatively near future.

This massive growth presents software developers with amazing opportunities, but also significant challenges. The explosion of mobile platforms and devices has created an unprecedented level of fragmentation, and it's going to get worse before it gets better. Development, testing and distribution of an app for multiple platform/device combinations can be prohibitively expensive.

In this article, I'm going to share my process for determining the best development approach for an app and discuss some of the more popular tools that have emerged to address the fragmentation problem.

Spoiler alert: I'm not going to crown a winner at the end. The correct approach for your project will depend on your development resources, business model, target market and a half dozen other factors. My goal here is to provide information that will help you make an informed decision. For the sake of discussion, I'm going to assume that you are interested in developing apps for iOS, Android, and at least one more platform (eg Window Phone 7, BlackBerry, mobile web, etc...).

Web vs native

Web vs Native is a hot button topic, so please hear me out before branding me a heretic.

I believe that if you can build your app as a web app, then you probably should. Conversely, if you can't, you shouldn't. In most cases, you'll end up somewhere in the middle with a mix of web assets (eg HTML, CSS, JavaScript, images, audio, video, etc) and native code. Determining the right balance for a given project depends on the specific requirements involved. I'll walk you through the process I use to help make this determination: it might not be a perfect fit for your organisation, but it should at least get you started. Please feel free to customise as needed.

All of the development project work we get at Mobiquity comes from enterprise clients. Large companies, by definition, have to reach enormous groups of people with their products and services, so we never have the luxury of ruling out large chunks of the market based on their choice of mobile platform. In other words, every project is a cross-platform project.

When evaluating a new enterprise-class mobile project, I start with web as my default approach, and then ask three questions in an attempt to rule it out.

1. Does this app need access to device hardware that the mobile web browser can't access?
   For example, a barcode reader app needs access to the camera, and therefore can't run in a browser. Ditto for an app that needs to record audio, run in the background, receive push notifications, etc. When an app does need a feature that isn't available to a web app running in a mobile browser, I try to determine what percentage of the app is based on this feature. In other words, is the camera feature the basis of the whole app, or is it just a nice to have?
    
2. Who is the audience for this app?
   There is a big difference between distributing an app to the general public vs your employees or affiliates. If the app is going out to the general public, the only really viable distribution options are the app store specific to the platform, or as a web app. If the app is internal for employees only, the options are ad hoc, third-party app stores (eg Apperian), sideloading or as a web app.
    
3. How memory intensive will the app be?
   Things like extensive animation with layers and opacity, very large data sets, file encryption or decryption, and complex map-based interactions can all contribute to a clunky user experience in a mobile web browser.

With the answers to these three questions, I can make a pretty strong determination between web or native. For example, if I'm given a request to design a B2E app that allows employees to manage their personal profile and benefits information and doesn't need to use any of advanced hardware features on the device, a web app is the obvious choice. If on the other hand, I'm asked to build an immersive mapping application with augmented reality layers that requires access to the gyroscope and will be sold to the general public, a native app is the obvious choice.

In cases where I determine that native is the appropriate path, I have a second series of questions I ask to decide if the app should be pure native or a native web hybrid.

Splitting the difference: native vs hybrid

These days, it's quite common for a native app to contain at least one or more WebViews. Normally, a WebView is used inside of an app to display HTML without having to bounce the user out to the web browser on the phone. Examples of mobile apps that use WebViews are the official Twitter and Facebook apps, the native App Store and iTunes apps on iPhone, the Bank of America mobile app, and hundreds (thousands?) of others.

A hybrid app takes the WebView from a supporting role and moves it centre stage. The native code portion of the app essentially becomes a dumb wrapper for the guts of the app, which are built with HTML, CSS, and JavaScript. Static file assets are bundled in the executable, and network data and dynamic assets are retrieved using standard Ajax calls.

Technically, hybrid apps are native but they are built so differently from typical native apps that it makes sense to draw a distinction between the two approaches. This often raises a couple questions:
Q: If I'm going to build a native app anyway, why would I use HTML in a WebView instead of the standard approach (ie using the native framework)?
A: The main reason to use a hybrid app is that it addresses the fragmentation problem. Remember, we're talking about building cross-platform apps. Since the WebView components of all the major smartphone vendors have more in common than not, you can build an app with HTML and have it run on lots of different devices. If you use the native framework, you're going to have to rebuild the app from scratch for each platform.
Q: If I'm going to build my app with HTML, CSS, and JavaScript, why wouldn't I just ignore the app stores and host it on my web server?
A: There are two big reasons:

1. Business requirements
   There are lots of business cases that might require you to distribute your app through a platform app store. For example, you might want to charge for downloads. Or you might know that your target audience will only discover your app in the app store. Or, maybe you're building the app for a client who demands app store distribution.
2. Hardware access
   Even though hybrid apps are primarily made up of HTML, CSS, and JavaScript, they are technically native apps and are installed on the device. Installed apps are not restricted the way that web apps running in a mobile browser are. Therefore, hybrid apps can access the advanced hardware features of the device using JavaScript. For example, JavaScript code running in a hybrid app can control the camera on a device. This same JavaScript code would fail if the web app was running in a browser.

I'm pretty confident that most people who travel through this decision tree will end up picking a hybrid approach. In those cases, you'll need to pick from a wide range of tools available for building mobile apps using web technology. Following is a list of popular options broken into categories. I'll briefly summarise each and offer some insight about when I would consider using one over the other.

Tools for cross-platform mobile development

The following group of products are JavaScript libraries that take some of the pain out of tough or tedious JavaScript coding tasks when building mobile web apps or hybrid HTML/native apps.

jQuery

jQuery is a hugely popular (and deservedly so, IMHO) JavaScript library that presents a unified API for common JavaScript web dev tasks like DOM traversal and manipulation, Ajax, and event binding. It uses a selector syntax based directly on CSS, so web designers typically find it very easy to start using jQuery.
jQuery is rigorously tested across all A, B, and C grade browsers (desktop and mobile), has a vibrant developer community and excellent docs, and is completely free open source software. The only potential downside of using jQuery for mobile development is that it's significantly bigger than it needs to be because it contains a fair amount of code targeted at fixing weaker desktop browser.
If I'm working on a website that is designed to be viewed in a desktop browser, you can be sure I'll include jQuery, even if that means potentially sending jQuery over the wire to mobile browsers. There's just too much value in the xplat testing that the jQuery team does to rule out the library based on a largish file size. That said, if I'm working on a site or app that won't be available to desktop browsers, I don't use jQuery.

Zepto

Zepto is meant to be a lightweight drop in replacement for jQuery specifically for mobile devices. Because Zepto makes no claims of support for older desktop browsers (think IE6) it can do pretty much everything you'd want to do with jQuery, but with a much smaller footprint. If you're familiar with jQuery and are working on a site or app that’s only going to be available on mobile devices, you should take a look at Zepto.

XUI

XUI is a very lightweight JavaScript library built specifically for mobile browsers. The emphasis is on simplifying just the most commonly used programming operations using the least amount of code possible. In other words, it's just the basics. The syntax is simple but it is different than jQuery so it can take a little getting used to.

Lawnchair

Lawnchair is a very lightweight JavaScript library that abstracts client side persistent "NoSQL style" data storage. It uses the adaptor pattern and supports multiple fallback approaches. The syntax is straightforward and simple queries are supported. When I want to add client-side persistence in a mobile app, perhaps for performance reasons or to support offline features in a mobile web app or site, I'll reach for Lawnchair.

Miscellaneous

New mobile JavaScript frameworks are cropping up constantly. Honourable mentions in this category include now.js, backbone.js, and underscore.js. For a constantly updates listing of JavaScript tools that are useful in mobile development, check in regularly with microjs.com ("Fantastic Micro-Frameworks and Micro-Libraries for Fun and Profit!").

JavaScript UI frameworks for mobile

jQuery Mobile

jQuery Mobile is like jQuery UI for mobile. It's a widget library that converts semantic markup into a familiar, finger friendly format. It's built on top of jQuery and as such has best-in-class support across A, B, and C grade mobile browsers. It's a fairly young but very ambitious project that aims to create the best possible mobile web experience on the largest number of browser. That being the case, the total file size is a bit on the large size but it's a great choice if you're creating a mobile version of a public website.

jQTouch

jQTouch is very similar to jQuery Mobile in that it's a widget library that converts semantic markup into a mobile-friendly format. The difference between jQTouch and jQuery Mobile is that jQTouch is specifically targeted at class A WebKit browsers on small screen devices. This means that jQTouch can use WebKit specific features to deliver a higher level of polish with a less code than jQuery Mobile. So I tend to use jQTouch when I know my users are going to have a WebKit mobile browser. Furthermore, Zepto support is supposedly coming soon, which means that jQuery will become optional. This will significantly lower the overall file size and runtime processing overhead.

Sencha Touch

Sencha Touch is a full featured widget library based on the Ext JS JavaScript library. Like jQTouch, Sencha Touch specifically targets class A WebKit browsers, but apps built with Sencha Touch can automagically reconfigure themselves to take advantage of the larger real estate of a tablet device. Also unlike jQTouch, Sensa Touch is not markup-based. Rather, developers write JavaScript code in a client-side MVC style. This is extremely powerful, but comes with a fairly steep learning curve, and it's a pretty hefty download. Sencha Touch is a good fit for medium-to-complex web apps that will be deployed to smartphone and tablet devices running WebKit browsers.

SproutCore

SproutCore is an open source JavaScript framework that was originally created to help web developers create advanced web applications for desktop browsers. In fact, it was so powerful and polished that Apple used SproutCore to build the original version of MobileMe. Because of its desktop browser origins, I've always found SproutCore to be too large to be practical for mobile development. That said, I know that their team is doing a lot of work in this area and I'm sure they've made progress since I last played with it.

Native tools for cross-platform development

PhoneGap

PhoneGap is a cross-platform mobile development solution that allows you to write a mobile app with standard HTML, CSS, and JavaScript and then wrap it in a native app shell. Currently 10 mobile platforms are supported. If you need to access any network resources, you'd retrieve them as you normally would in any modern web app (ie Ajax). Furthermore, PhoneGap exposes a bridge that allows your JavaScript code to access native device features that would normally be off limits to a mobile browser (eg camera, contacts, speakers, mic, etc...).
PhoneGap is not a widget library, it doesn't compile your HTML down to native code, and it doesn't submit your apps for you. Because your app is executing JavaScript at runtime, it can be hard to achieve as polished an interface as can be done with compiled code. I use PhoneGap for all my hybrid app projects. See above for more on how I determine whether or not hybrid is a good approach for a given project.

Titanium Mobile

Titanium Mobile is a cross-platform mobile development framework that enables you to write JavaScript which is then compiled down to native code for the iOS and Android platforms. Titanium is marketed to web developers and is often compared to PhoneGap although the two are actually quite different. With Titanium, you write your apps against the Titanium framework, as opposed to writing standard JavaScript that would run in a browser. From a syntax standpoint, writing a Titanium Mobile app looks a lot like writing a Sencha Touch app – ie it will immediately look familiar to advanced JavaScript developers but newer devs might experience a bit of a learning curve. If you only want to create native apps for iOS and Android, you might want to take a look at Titanium Mobile: it's a great way to avoid learning Objective-C and the Android SDK.

Corona

Corona is a proprietary SDK that uses the Lua programming language to deliver visually rich native application experiences on iOS and Android. It has full-featured physics and tweening libraries, as well as powerful rendering engine that takes full advantage of the GPU. These features make it perfect for immersive game development, but Corona is also useful for traditional mobile app development. I haven’t done any game development, so I haven't used Corona on a client project but I expect that to change soon. If you have to create an immersive pure native experience on iOS and Android, I'd recommend taking a look at Corona.

Mobile Enterprise Application Platforms (MEAPs)

A MEAP is a soup-to-nuts platform that can be used to manage the entire lifecycle of a mobile application across multiple platforms with a single backend. It's outside the scope of this article to get into a detailed comparison of MEAPs. I've only included them because RhoMobile is sometimes considered a competitor to PhoneGap, when in reality they are not the same thing at all.

• Antenna Software
• Pyxis Mobile
• RhoMobile
• Sybase Unwired Platform (SUP)

Conclusion

I don't see "pure web app" and "pure native app" as an either/or proposition, but rather as opposite ends of a spectrum. The question isn't as much about which approach you're going to use for your app as it is about how much of your app will be made of HTML, CSS, and JavaScript.

Your goal should be to use as much HTML as you can without negatively impacting the user experience because the more HTML you use, the less you have to worry about fragmentation. And the less you have to worry about fragmentation, the more awesome stuff you can build. The world could use some more awesome stuff, so get out there and start building!

Top 10 Best Free Windows Mobile Apps

Even though Microsoft have failed to capitulate the phone market, they still have a user base that’s decent enough for hundreds of applications being made available for Windows Mobile. VOICEABLE have, then, compiled a list of the top ten best free Windows Mobile applications.

10. Fring

Fring are known for their instant messaging services they provide. They’ve ported it onto Windows Mobile and has thus become a key application for those who either have several IM accounts, or just want a particular one (all of them have a sleek and simplistic interface). AIM, Google Talk, ICQ, MSN, SIP, Skype, Twitter and Yahoo are the services supported.

9. TwitToday

While this isn’t an application at its premise, TwitToday is still a useful tool for anyone who has a Windows Mobile and uses the social networking site. It’s fundamentally a plugin for you device’s ‘Today’ screen which allows users to post tweets to their Twitter accounts.

8. Opera Mobile

Opera was one of the classic browsers which went head to head with Microsoft’s Internet Explorer. Gradually, it lost its importance in the browser market but it’s still a great choice for mobile platforms.

7. YouTube Player

Windows Mobile doesn’t have too many YouTube-based applications available, but the few which are available are all that’s needed – one of which being YouTube Player. Users can view videos in an FLV format.

6. iDialer

This application changes the interface, as its name suggests, of the dialing screen in Windows Mobile. It essentially delivers a style more similar to the Android and some aspect of the iPhone. Also, Internet phone services including JaJah and Grand Central are both compatible with iDialer.

5. Skype

Skype will essentially remove the necessity of topping up credit on one’s phone as Skype calls to other users of the service is free. Due to this, and due to the fact that Microsoft’s Skype has hundreds of millions of users, the application is a great alternative to the normal calling system.

4. iContact

The Windows Mobile contact interface is good enough for the average owner of the phone, but with iContact, it transforms it into the more attractive and generally more better iPhone-inspired contact interface. Users can browse through their contacts with just one flick.

3. Pocket RAR

This Windows Mobile application is a simple, yet accessible port of Win RAR. Pocket RAR is suited to make smaller archives, resulting in users saving transmission time, as well as disk space. A graphic interactive interface, which includes a pen and menus, is present within the application. Users will also be able to browse for archives and files via a management mode. RAR & ZIP archives are the supported formats with the application allowing compressing, decompressing and deleting files in those formats.

2. Slick

Slick is another application for IM messengers. However, this Windows Mobile app provides users with the ability to utilize emoticons, in addition to access to message history. Supported messengers are AIM, Google Talk, ICQ, Jabber, MSN and Yahoo.

1. Call Firewall

Call Firewall delivers exactly what its name suggests – users can create blacklists, have access to a host of filtering options, a simplistic interface, and the arguably the main feature: an automatic SMS registering system for blocked callers, meaning they’ll receive a text informing they’re blocked. Also, Call Firewall runs in the background without slowing your Windows Phone.