JavaScript Under Pressure

Just thought I'd share this little exercise that I got sent.

It's a fun little exercise that gives you five JavaScript exercises to do on a time limit.

http://toys.usvsth3m.com/javascript-under-pressure/

If you don't want to see the answers, then leave now, otherwise I'll give a summary of how I completed them!

One

return i*2;

Two

if(i%2)
{
    return false;
}
else
{
    return true;
}

Three

var fileExt = i.split('.');
return fileExt[1] != null ? fileExt[1] : false;

Four

var lengthOfString = 0;
var arrayVal = "";
   
for (var x = 0; x < i.length; x++){
  if(i[x].length > lengthOfString && typeof(i[x]) == "string")
        {
            lengthOfString = i[x].length;
            arrayVal = i[x];
        }
    }
   
return arrayVal;

Five

var sumOfArray = 0;
   
for(var x = 0; x < i.length; x++ {
    if(Array.isArray(i[x])) {
        sumOfArray += arraySum(i[x]);
    } else if (typeof(i[x]) == "number") {
        sumOfArray += i[x];
    }

}


return sumOfArray;

Back From the Dead

Well, suffice to say its been a while since I last put anything on this blog but I think its time to change that!

A lot has changed since I last posted, a lot more experience and far more exposure to many new things since getting myself a new job! It's given me a lot of insight into how little I knew at my old place and how set in their ways they were.

I had never used CMS' before, I knew of them but had never used them, I never had a need to. This has changed now however, where I work now uses them a lot. They are certainly best suited to the type of business they offer, they're a fantastic way of getting non-techies to keep a website running. Certainly something I'll be looking to do more reading on for the future, you can never learn too much!

Anyway, on to the tech! I've so far had experience with two CMS' now in my seven weeks here and I must say I've had a far greater experience with one than the other.

EPiServer

EPiServer is a .NET Content Management and E-commerce product company providing robust, flexible and highly customizable software solutions for the next generation of websites. For what it does however, I found it to be overly complex. It requires a stand alone installation for the CMS, it's not something you can just drop into a solution. This installation then lets you point it at solutions to include EPiServer components. Oh, and its not free!

Umbraco

Umbraco is an open-source .NET Content Management system, it does not require any additional component installations, you can just use nuget to add it to your solution. It handles the deployment and configuration automatically. All you have to do is point it at a database. It has a much more simple learning curve than EPiServer to boot.

I'll talk about them a lot further in future posts, that's a really quick, untechie summary but I just had to get down something to get the blog alive and kicking again. I've also got another piece I want to contribute with regards to the whole Mobile Web vs Native app discussion after a recent push at my workplace to start considering a mobile/tablet market.

Fun times ahead!

A look into JavaScript

Just a quick one today for those of you interested. I had to do a presentation at work yesterday that covered a number of topics relating to JavaScript so I thought I would upload them and share them here to see if they are of any use to anybody else.

Topics to be covered

• JavaScript Overview
• Document Object Model
• Objects & Prototypes
• jQuery Library
• AJAX & JSON
• MV* Frameworks

The slides can be downloaded at my Google Docs Upload


It uses local file reading so the following text should be added to your Chrome shortcut --allow-file-access-from-files (as we know everybody uses Chrome right? :) ) 


Any feedback would of course be welcomed for improving them for future use.

Project Log – TimeTrack: Part One

For a while now I have been seeking a project that I can begin development of that will allow me to put to use HTML5 alongside some of the rather interesting JavaScript libraries/frameworks out there. My inspiration came from one of my daily grinds at work, time logging.

I’m not sure how many of you out there have to log your hours at work, but for those who do you’ll know the importance of having something that is easy to use and is responsive. Unfortunately the software I use for time logging at my place of work is anything but…

So, with my inspiration in hand I went searching for some nifty little gubbinz with which to begin development.. Earlier in the year I read an article (alongside some videos) in a dot NET magazine that uses Backbone and jQuery mobile to build a rather flashy Notes application, remembering how easy and fun jQuery mobile was to use, I thought I would return to it. With jQuery mobile in hand I began my work.

For those unfamiliar with jQuery mobile, it is a JavaScript Framework based on jQuery optimised for mobile/tablets, oh, and it replicates iOS in its design! It has a large number of features that allow the design of “multi-page” websites using nothing but a single HTML file and some tags in the HTML code for jQuery Mobile to pick up on. So here is part one, as always with any project it will cover its initial design, how it will flow and alongside this, obviously, a very brief introduction to jQuery Mobile. First up, we will need a front page, that will include a way to view tasks entered by Day, Week and Month and we will also need a way for a user to add a new task. So using HTML5 and jQueryMobile here is my initial first screen. As you can see below we have an accordion style list to display all the tasks by Day, Week and Month and if expanded will show a table of tasks. The ‘New Task’ button displays the form in the third image. 

Initial Screen

Expanded Menu

New Task Form

So, with those initial two pages let’s break it down.

To achieve this ‘two-page’ design in our HTML we will be making use of the data-role attribute. In a most basic way of explaining this, it tells jQuery Mobile what’s going on at that point with the HTML code associated with this role.  To declare a new page you can then create a new div tag and use the data-role attribute giving it a value of page. The beauty of jQuery Mobile is this ‘new’ page is hidden until we enter some form of transition or call to that page.  So, as shown below we can declare our home page and a new page that will then be our New Task form as seen in the third image above.

<!-- Home Page -->

<div id="home" data-role="page">

      …

</div>

<!-- New Task Form -->

<div id="new-task" data-role="page">

    …

</div>

Now we have our two pages, we can then flesh out the content within each. Let’s concentrate on the home page for the time being. As you can see in the images above there are a number of different things on the home page, these are the header bar, the New Task button and our accordion list containing our table of data. The header is achieved in much the same way, jQuery Mobile internal pages are structured with a header, content and a footer and use the same data-role attribute to determine these.

So, expanding on our Home Page div, inside we have the following code to produce the header:

<div id="name" data-role="header">

    <h1>

        Time Track

    </h1>

<a href="#new-task" data-rel="dialog" data-icon="plus" class="ui-btn-right" data-role="button" data-transition="pop">New Task </a>

</div>

You can see further use of the data-roles for the header itself and the content within. The header uses the header attribute followed by a button that uses the same data role; for the most part these data roles are self-explanatory.

Coming out of the header now, we come into the content section of the home page, again we create a new div with the content data-role, this is primarily a semantic thing and structures the page well (header, content, footer). Inside our content is where we then put the code for our accordion content / tables.

<div data-role="content">

    <div data-role="collapsible-set">

<div data-role="collapsible" data-collapsed="false" data-theme="b"   data-content-theme="c">

            <h3>

                Day</h3>

            <div class="ui-grid-d" style="text-align: center">

                <div class="ui-block-a">

                    <div class="ui-bar ui-bar-d">

                        Task Title

                    </div>

                </div>

                <div class="ui-block-b">

                    <div class="ui-bar ui-bar-d">

                        Task Description

                    </div>

                </div>

                <div class="ui-block-c">

                    <div class="ui-bar ui-bar-d">

                        Date Started

                    </div>

                </div>

                <div class="ui-block-d">

                    <div class="ui-bar ui-bar-d">

                        Date Completed

                    </div>

                </div>

                <div class="ui-block-e">

                    <div class="ui-bar ui-bar-d">

                        Total Time Spent

                    </div>

                </div>

            </div>

        </div>

    </div>

</div>

So, let’s now break this down.

Within our content div, we have our ‘collapsible-set’ this is the data-role we use to tell jQuery Mobile we want this to be a collapsible menu. I have chosen to use this as I want to be able to toggle whether I view my tasks by day, week or month. You can then add each of your collapsible items to the set. In the example above I have only displayed the collapsible for Day, but the code is the same for all items in the set.  We then use the data-grid class to define the table (the letters correspond to the number of grids in the table, d in our case is five going up from a).

Then amongst all this code are all the little extras you can see with the classes, the ui-x. These are purely for styling the elements you put onto your page. You can consult the jQuery documentation to see a list of all them, including previews.

Before we skip onto the navigation of internal pages I will briefly talk about our ‘New Task’ form that we will soon reveal how to navigate to. jQuery Mobile being the clever little thing it is, will format our form to look just like a pop-up by creating a simple html form. That’s all there is to it, create our form and jQuery Mobile does the rest!

<div data-role="content">

    <form action="#" method="post">

        <div data-role="fieldcontain">

            <label for="title">

                Title

            </label>

            <input type="text" id="title" name="title" value="">

        </div>

        <div data-role="fieldcontain">

            <label for="body">

                Description</label>

            <textarea id="body" name="body"></textarea>

        </div>

        <button data-icon="check" data-theme="b">

            Save

        </button>

    </form>

</div>

So, we’ve seen the code for the Home Page, seen how we create our multiple pages, seen the ui theming, data-roles etc. All we need to see now is how we link to internal pages! Again, thanks to the functionality of the library, all we need to do to link to internal pages is link to the page id in our html, as I’ll show below. As with the themes of the content, you can also select from a number of page transitions offered by the library, I have chosen pop simply because I like it. But there are a number of other sliding, switching etc. transitions to experiment with!

<a href="#new-task" data-rel="dialog" data-icon="plus" class="ui-btn-right" data-role="button"

    data-transition="pop">New Task

</a>

The #new-task will then navigate to our New Task form:

<!-- New Task Form -->

<div id="new-task" data-role="page">

    …

</div>

So that’s all there is for Part One. Just a simple introduction to the basics of my project, a look into jQuery Mobile and the amazing features it offers to the user, with great simplicity. Next we will be looking into Backbone.js to add some functionality to our form to persist and read our tasks.

Mobile Applications - Native vs. Web App (Part Three)

Continuing the series on from (Part One) and (Part Two) today I will talk about development of the apps, the tools available and some of the practices that allow a developer to create the advanced and interactive apps we see today.

Javascript - I'm a real boy programming ^ language.

JavaScript has become a powerful tool for developing web applications. There are an increasing number of well-polished applications that deploy JavaScript to a very high standard, Google Mail being a great example. There are several frameworks out there now that make JavaScript development a much more pleasant experience taking it away from a more procedural and messy coding style to a well formatted, OO, patterned approach and it is these frameworks that allow for the power providing in applications on the web today. A JavaScript library helps to make code that bit more manageable offering functionality to be integrated as and when needed, more akin to development in a native app language. JQuery as I’m sure many of you reading this article will know is one of the more popular frameworks and offers a lot of useful functions for a developer that would otherwise take a lot of time to develop and test. Libraries offer the developer a tool to speed up development of their application while maintaining good quality code.

Frameworks on the other hand offer a way to structure a system or component architecturally. There are particular frameworks that allow JavaScript developers to maintain their code and develop using tried and tested design patterns. One in particular I have used is Backbone.js; a lightweight library that helps building applications using MVC. Now I won’t go into too much depth with Backbone or MVC at this point as this is not a tutorial article and is out of scope of the subject, but the structure of Backbone (Model, Collection, View, Controller) allows for a well-formed, easy to maintain application and, as found on Backbones’ website have been utilised in a number of large applications such as LinkedIn Mobile, DocumentCloud and BitTorrent.

The point of this is to highlight that JavaScript is no longer just an option to add a little bit of functionality here and there. It is at the core of web application development and with the addition of libraries/frameworks it is rapidly becoming a technology to compete with native device languages. Another great bonus to tip the balance of development in the direction of JavaScript is that of IDE’s, your browser can be your IDE. When you look at the development tools available to you with browsers such as:

Google Chrome (Developer Tools)

Firefox (Firebug)

The ability to develop and test JavaScript on the fly makes it much easier to get started in developing JavaScript applications. Download and install your browser, you have your JS IDE. There is no fuss with ensuring you have the latest version of Eclipse, or JVM/JDK, no extra space or time to run/debug applications it is all there collectively at your fingertips inside your browser.

CSS3 – Hey there good looking!

CSS3 has made a huge impact into the aesthetics achievable in web development; this coupled with the semantically oriented mark-up of HTML5 has allowed the creation of some wonderful websites such as EllaDesign and HTML5Readiness. CSS3 offers a number of effects that, up until now, designers were forced to use images for (which as you all know increases bandwidth which we are trying to save!). HTML5 also offers us the Canvas API which allows for dynamic drawing on a page. Using JavaScript and CSS with canvas can achieve some stunning effects as demonstrated particularly by Liquid Particles. CSS3 offers tools that allow for modern, crisp and professional looking UI designs without the need for learning the multiple methodologies utilised for native UI design, for example UI design on the Android platform uses the View and ViewGroup nodes using XML which have requirements for how they must be laid out and structured. CSS3 brings together this diversity of knowledge to implement a single technology to allow cross-compatibility across devices. Boston Globe is another great example of all the main principles of web development (particularly responsive web design).

Mobile Apps - Native vs Web (Part Two)

While doing some more reading and research trying to determine the subject for this article (continuing from Part One of the series), I decided to elaborate on some factors I found leaning towards pro-native. This is not to say that I think they are wrong, or I am right but merely to offer an outlook that was possibly overlooked. Firstly, an argument of “if it needs no internet connection it should always be developed as a native app”.

The issue of internet connection or not is an issue of distribution, and the method by which apps are installed and updated.  Coming back to the subject of local storage (covered in Part 1) there is no reason to rule out a HTML5/CSS/JavaScript application for a pure offline application. There are a number of HTML5 browser games now that allows offline play. The use of local storage to store user data such as save states or appcache for assets and offers the same kind of functionality that would be available through a native app. Again the limitation is that most mobile markets do not allow for apps that are not natively developed. This is where the issue of cross compatibility comes in; the potential of web/browser applications is limited only by the self-serving restrictions imposed of the respective markets. Not only can the user data be stored you can cache most of, if not all the application data through the browser thus rendering the “offline == native” argument redundant.

Any application whether it is a native or web app will initially need downloading from the relevant website or the specific device market. In the case of said web app you can cache all downloaded components in the browser offering true offline capabilities and likely a much smaller first download than a native application will need due to the small amount of data in HTML/CSS/JavaScript files (especially when you consider minified files). Whether native or web technologies they are merely presentational, it is about the approach that suits the application. This issue of ‘installations’, ‘clean end to end experience’, ‘browser support’ are all concerns that have existing or rapidly developing solutions when you look at applications developed using  web technologies.

Installations as it is, I think people overlook installation via caching using the Application Cache interface or AppCache as it is otherwise known. This provides many benefits, albeit providing some functionality that is an unfamiliar experience for the user however with the push to cloud technologies and the impact the web is having on people’s everyday lives it is something a user will adjust to. AppCache also provides a seamless, transparent update to the application which is a benefit to the user in a number of ways. First, the speed is increased as cached resources are local thus removing the need to make server requests for assets, this has a noticeable issue in performance speed for the user. The only exception to this is a download of resources from the server that have changed but again, this only benefits the user as it seamlessly updates the application without the user being prompted or distracted by notifications. Eric Bidleman has a great article explaining AppCache in more depth. ^[1]

Installations are a short sighted concept and installation via caching and transparent upgrades are often overlooked even though the single feature has been credited as the main success behind the Google Chrome browser. Using the AppCache interface, which provides a transparent updates and seamless updates to the application, can benefit to the user in a number of ways. First, the speed is increased as cached resources are local thus removing the need to make server requests for assets, providing a noticeable issue in performance speed for the user. The occasion where performance may be an issue is when downloading newer versions of changed resources from the server, but again, this only benefits the user as it seamlessly updates the application without the user being prompted or distracted by notifications. The only major downside would be user confusion over the new, improved, and transparent installation/upgrade procedure as the rapid change in analogy may affect the experience of users whose expectations lie with the existing monotony of the “next, next, finish” interface and are off put by its absence.

It is not ‘installed’ but still perfectly functional offline, with the ability to get updates over an internet connection (as any native app would). The advantage of web technologies is the ability to use the flexibility offered by mark-up/presentation along with a number of robust, efficient libraries and API’s available. I think it is a case of people not trusting the nature of the connection, the user likes the trust offered on app markets – and the way that you install applications is irrelevant, it just needs a clear analogy. There are a number of other concerns when you consider the approach to take with mobile applications such as browser support with things such as CSS compliance and JavaScript engines, but the same argument applies when you consider developing apps across multiple devices. The overall cost of developing an application across multiple browsers is far less than employing more developers to deploy apps for iOS and Android etc. especially when you consider the financial cost of targeting both. Both use different native languages, both need separate IDE’s and one even requires a particular set of hardware and operating system. All major factors to consider when weighing up the business side of things with the technical.

References:

[1] http://www.html5rocks.com/en/tutorials/appcache/beginner/

Mobile Apps - Native vs Web (Part One)

Mobile development is booming at the moment, everybody wants a mobile application. However before development begins, a question comes up that is a rather hot subject at the moment, native or web app?

Source: Global Intelligence Alliance

The results of my recent reading seem to show a very large split over which of the two is best to use and if any particular one is better than the other. Will HTML5/JavaScript/CSS3 technologies ever be robust enough, even when their respective /specifications are finalised/, to lure the mainstream developer away from the native mobile platforms? It was an issue that up until recently I was rather stubborn over and attempted to always bias my findings toward web apps. I remained convinced there was a definitive yes, HTML5 is the way forward. On reflection however I don’t believe it is as simple a question to answer.

Source: w3

HTML5 brings some fantastic tools (and let’s face it, an awesome logo) to the table that can really help with the look and feel of mobile applications:

Geolocation ^[1] is one of them and it has a huge hype at the moment as it allows a user to ‘check’ themselves into places, let users know where they are/have been (with the users permission) and has become a novelty for a number of websites and allowed for some very interesting interactive experiences (see geocaching).

Local Storage ^[2] has been a massive bonus for HTML5, especially popular among game developers, allowing for both on and offline play. The ability to synchronise the local and server storage allows for true data persistence. The browser, for both mobiles and desktops, is slowly becoming the primary tool for a user.

Websockets ^[3] are another technology that simply cannot be ignored; they offer a solution to a problem that many people have implemented “hacks” for to do for a very long time. When you consider their potential for mobile applications, their bi-directional communications give much more efficient bandwidth consumption and will also be much more efficient with battery power consumption. Websockets also have the potential to push notifications to your device with much more efficiency than native API’s. It is not at the moment a guaranteed, concrete solution but again with things such as canvas, geolocation, WebGL it is the impact these technologies can have when developed and researched further.

The question I kept asking myself was can web apps ever replace a native application. Being new to mobile applications, new to JavaScript, new to HTML5 it was a question I asked over and over and spent many, many hours trawling blogs, books and articles to give a concrete answer for this question. Despite being new to the technologies in general I have realised I am asking the wrong question however. I am approaching the subject wrong trying to force the answer I want, I biased any opinions to making the answer yes, HTML5 is in fact better. I got over my zealous attitude to web technologies and realised it is not about one technology replacing the other; it is a case of what tool is best for a job. HTML5 will never be able to integrate with a device’ hardware to the level a native application can. However depending on the purpose of the application it brings a great alternative to having to learn a native language, learn a new IDE etc. It has allowed a whole new area of experimentation and potential, it has allowed a developer the flexibility to decide what tools are best for the job at hand. 

Source: Backbone.js (DocumentCloud)

Take Jérôme Gravel-Niquet’s Todo’s tutorial ^[4] using HTML5 and Backbone, a simple but effective application made possible without having to know Java or Objective C, without having to learn how to use Eclipse or buy a Mac. Knowing the ins and outs of each technology, each possibility is the key to developing an effective and efficient mobile application. Bear in mind however that these technologies are still growing and as more and more documentation is complete, more experts educate people like me on the benefits of the API’s it offers…the future is still very bright for the possibilities HTML5 can bring to not only mobile applications, but to the internet in general.

I suppose in summary I came to realise the simple truth. When you consider developing an application either natively or as a web-based application, it is a matter of finding the right tool for the job not about making the tool fit the job.

References:

[1] http://diveintohtml5.org/geolocation.html

[2] http://diveintohtml5.org/storage.html

[3] http://websocket.org/quantum.html

[4] http://localtodos.com/

Cotinued in Part Two - Discussing the arguments behind the 'installation' issues with Native vs Web