Posts Tagged ‘Mobile’


2015: Native App Development is Dead in the Enterprise

by Cain Ullah

With Gartner results showing that in 2014 mobile and tablet sales equated to approximately 2.4 billion unit sales compared to 318 million PCs and with an ever increasing proliferation of mobile devices, for many enterprise level organisations developing an effective mobile strategy continues to be one of their biggest challenges.

So what questions are organisations currently asking themselves when devising a strategy for a successful mobile presence?

Native vs Responsive

There has been a long standing argument between the value of building native applications specific for a device such as an iPhone or Android vs. the mobile web i.e. responsive web sites that work across all devices.

The nirvana is that developers wouldn’t have to worry about devices at all and that there would be a solution to write an application once, for it to cover all use cases and work on all devices be it in the guise of a native app or a website. Unfortunately this doesn’t yet exist and Facebook’s attempt at doing this via HTML5 was followed by a rapid backtrack that was well publicised.

There are obvious pros and cons to both (you can read David’s article here for some great insight into why responsive web design is a great strategy). Native applications give you more flexibility when accessing a smartphone’s features (such as the accelerometer) and there is the obvious advantage of offline browsing. However, native applications are only built for a specific device resulting in you having to build multiple applications; development costs and ongoing maintenance escalate as a result. Responsive websites on the other hand can be built once and work on most devices (if tested properly) providing a far greater reach for less development cost. But offline browsing is not easy and user experience can often be hindered by the limitations of HTML.

At the moment there are use cases for both that solve separate concerns. If you have a complex set of requirements you may not be able to avoid the need to have to build both a website and a native application. It is common place for enterprise companies to have many desktop applications each with 3-4 mobile applications to support them.

Enterprise strategies differ from company to company. A fine example is The Times newspaper. They have focussed more on the optimum interactive experience of their native applications for both Apple and Android tablets, with separate editorial teams dedicated to each device. The website on the other hand is not responsive. They’ve not even bothered to redirect to an, instead just displaying the desktop site on a mobile with a link to download the app from the app store.

In contrast to The Times, the Guardian has opted for a great adaptive/responsive website detailed in David’s aforementioned article from October 2013.

So is there a happy medium?

Cross Platform Tools

To tackle this problem, there are tools in the market that facilitate cross-platform mobile development such as Phonegap and Titanium. These allow you to build apps using Javascript and Web Technologies, and deploy them to  multiple marketplaces in the guise of native apps, across multiple platforms. The advantages on the surface are obvious – you get access to native features that are not available to web browsers but you also only have to write and maintain one code base. If only it was that simple.

There is a great blog highlighting the comparison and the weakness of both Phonegap and Titanium by Kevin Whinnery here.

Other cross-platforms also exist. Another blog by Kevin Whinnery’s former colleague, Matt Schmulen provides details on the options and how they fit into the current mobile ecosystem where there is an ever increasing demand in the Enterprise.

These frameworks include:

  • PhoneGap/Cordova (HTML/JavaScript)

  • Titanium/Appcelerator (JavaScript)

  • Mono/Xamarin (C#)

  • Rhodes (Ruby)

  • Kony (JavaScript formerly Lua)

Our experience of these cross-platform mobile development tools is that you simply cannot replicate the native app experience. We have experimented with these tools before, an example being the build of the mobile applications for our BMW project using Phonegap. We found that the iPhone version of the app was great. However, getting an optimum experience on Android took a huge amount of effort in optimisation and testing to get it close (but still not close enough) to a native experience.

So what does the future hold?

Native App Development Is Dead in the Enterprise


This is a bold statement that will take some time to become completely true. However, 2015 is going to be the dawn of a new era of technology that will replace existing cross-platform tools such as Phonegap and Titanium with a much better offering that will finally succeed where Phonegap and Titanium have largely failed. This will be the beginning of the end of enterprises building responsive sites with multiple native applications to compliment them.

Responsive websites, with the help of new technology will form the basis of the code for native applications without hindering user experience. The applications will be fast and responsive, and there will be a single code base with very little device specific code.

What does this mean? Software companies like Red Badger that currently focus on the enterprise web (i.e. responsive web sites and not native applications) will also be able to deliver great native applications without a great deal of additional effort or the need to hire native app developers. Native application agencies are going to have to adapt and re-skill their employees in order to keep up, or face the consequences of withering into eventual obscurity. The winners will be the enterprise companies. They will have options available to them to  build great experiences across web and native applications on multiple devices with close to a single code base. This means fewer applications, less maintenance, lower development costs and happier customers.

This will ultimately kill the question: “should I build native or responsive?”. Why choose when you can have it all?!

P.S. Where’s my proof you may ask? Watch this space.

UPDATE 2015/02/08: On 28th January, Facebook announced React Native at React Conf. React Native is a game changer and already answers the predictions made in this blog. You can view all of the videos from the conference here.


Will cars become the new mobile?

by Mike Altendorf


It seems slightly crazy to be talking about ‘the new mobile’. It seems like mobile only recently became the new mobile and I can’t even remember what it was before that. Such is the speed of change in this digital world of ours that simply by proclaiming something ‘new’ makes it old. What I find particularly interesting at the moment though is that it seems it is more reinvention than invention. The ‘internet of things’ is in the process of breathing new life into a host of everyday objects. I heard today about a company that is developing a lock that will text you if it is being broken into; I have heard about belt buckles that will alert family members if elderly relatives go on an unexpected walkabout; shoes that analyse the way you run, even toilet paper holders than text you when they are about to run out (ok, maybe I made the last one up).

All of sudden every physical thing around us has an opportunity to become something else. The thought is actually overwhelming. Can we deal with that much information? Do we need it? At what point does it become too much? In a way there is no doubt that there will be many missteps along the way but there is no doubt that the ‘internet of things’ is set to revolutionise our lives and there is one piece of everyday equipment which I think has the potential to become ‘the new wearable mobile’ and that is the car.

The idea of the car that is more than the car has been with us as long as the car has. In 1938 at the New York World Fair General Motors predicted that motorists would be able to simply type in a destination, sit back and relax ( autonomous-vehicles-reality-coming-street-near-you). Those of a certain generation will have dreamt of having their own Kit that could not only talk to them but could save the day against any baddy out there (and there is always the Batmobile of course). Cars have always had huge potential and right now we are on the cusp of that potential being realised. As far as platforms go cars have far more to offer than the mobile phone. They don’t just tell you where to go, they can take you there. The computing power in the average sedan is already overtaking that of a smartphone. Sensors help us park, keep us from getting too close to other cars on the road, alert us to obstacles, sense and adapt to different weather conditions, open garage doors. We can call, email, surf the web, watch movies. Almost without us noticing cars have become a whole lot more than four wheels and an engine. 

The reality is however that we have barely scratched the surface of what is possible. With the exception of mobiles and computers, cars are the machines that the majority of us spend the most time engaging with and now we have the possibility of them communicating with their surroundings? This not only opens up the idea of the self-driving car but of a whole transport network that is communicating internally. Cars talking to each other, to traffic lights, to buildings: Cars that are monitoring you as you drive, evaluating your behaviour and adapting accordingly, communicating with people and places. Imagine a car that can not just call for help from an accident but automatically request an ambulance? Cars that can prepare your house for your arrival or come and pick you up when you have had more than half a pint? 

The thing is once we no longer need to concentrate on the road that frees up the time we spend travelling to do other things. Retailers need to consider whether a car will become the next device from which people will shop and how they can exploit tech to connect with it. Unlike the mobile it doesn’t need to be small enough for us to carry round – in fact it will be carrying us around. What would you do with a screen the size of a windscreen if you didn’t need to be able to see out of it all the time? 

All of this might seem a bit fantastical but when you consider how mobile has exploded in the last five years perhaps there is a chance that I will be taking delivery of my very own Kit sometime before my 60th birthday.


Something about the Quirky World of Mobile Web Apps

by Haro Lee

On a recent mobile-focused project we ran into a few challenges over getting what turned out to be a fairly complex layout working smoothly and responsively over a range of target devices. It also highlighted a number of real edge-case quirks in how different phones and browsers deal with modern web technologies such as the audio element, and even how ‘shake to undo’ can affect a form that the UI hid several transitions ago.



(There was a time mobile phones were simpler… or not…)



To help with the total payload of the project we chose to use the Zepto library rather than jQuery. This has an API very similar to jQuery’s and the advantage of size but is focussed on modern, mobile browsers so drops support for IE and – significantly – doesn’t cover Windows Phone. That wasn’t a problem on this particular project but worth bearing in mind for the future.

We found a couple of niggles in the Zepto API, mainly related to our own coding styles and the requirements of the project. We missed jQuery’s ability to set a hash of functions against AJAX http response codes, for example.

In the end, given the eventual size of the rest of the application’s payload, the filesize saving of Zepto over jQuery probably didn’t make a whole lot of difference.


How to be responsive

The biggest problem encountered while implementing a responsive layout with the given design was how the DOM flow needed to change depending on whether the screen is portrait or landscape. It would have been ideal if we’d had the option to change the design and eliminate the worst of the problems, but once we realised how complicated it would be it was already too late. So a lesson learned…

One of the big problems in trying to fit a fairly fixed size application design to a phone screen is orientation. Fine in a native app; you can just specify if the app fits to portrait or landscape, or both, but in a browser that level of control is not available.

Fitting the level of interaction we needed, responsively, into a landscape phone viewport meant quite a lot of juggling of DOM elements and events when switching from and to portrait layout. This was particularly tricky on iPhones as Safari in landscape orientation has three different possible sizes (address bar visible, address bar hidden, fullscreen) and generally smaller screen sizes than our target Android devices. The eventual experience in landscape wasn’t as satisfying as in portrait but we did manage to make it work.

Because of all the complexities that are not possible to handle only with CSS and media queries, we heavily depended on a Javascript layout manager to handle resize events and orientation changes, calculating available screen estate and rearranging elements.

A simpler way to get around this, although perhaps a cheeky one, would be to use the ‘orientationchange’ or window’s ‘resize’ event to effectively hide the main app with a “please turn your phone round” message. Unfortunately the ‘orientationchange’ event is not available on older Android devices.



The procedure we used to preload assets for our single page web app was to have separate CSS files for the preloading/splash screen and for the main app.

The splash page was part of the app, so we didn’t want users to proceed from here and start using the main app until all the assets were loaded. To achieve this, we made one stylesheet for the splash screen with all the generic styles that didn’t require any images and another for the main app which referenced all images and assets (i.e. icons and background images) and only linked the splash stylesheet to the HTML page. We then used a Javascript preloader which requested all the image assets and the main stylesheet, attached this CSS file to the HTML page once everything was loaded and ready.

This method could also be used to load different stylesheets and assets depending on the screen size or device, if required.



A new technology for us on this project was the Web Audio API which is a programmatic way of cuing and playing sound files rather than relying on a DOM element such as <audio>. Support is limited for now with only modern desktop browsers, and Safari in iOS 6, able to use it, but it looks to be a great way of adding spot effects to browser games and other interactions.

We used the Howler library to add sound to the application, with the expectation that we would use its fallback methods to increase support across devices and browsers. In the end due to other technical constraints (see ‘Device Quirks’ at the end of this post) we chose to only play sound through the Web Audio API, so if we were to refactor here we could have removed Howler (not that there’s anything wrong with it) and go direct to the API.


Jam off the boil

We’ve used the Jam package manager on a few projects now, and while it does have some advantages in dependency management and compilation it also uses its own module install system. So it relies on package owners keeping the versions that are published in Jam (rather than their main Github, etc, repo) up to date. We’ve had a few cases where the version of a library we needed isn’t available yet in Jam.

Jam interface with the browser is a modified version of Require, which we like for its clean module loading mechanism. So for future projects we’d look to dropping back to regular Require and find something else, perhaps a Grunt task, to handle the file concatenation and minification which Jam also offers.


App logic

The application logic required a fairly complex state to be maintained, and for these we used our old friend Knockout. We did consider lighter MV* libraries but ultimately felt that with Knockout’s very comprehensive view binding built-in we would save ourselves a lot of trouble. The other main aspect of the Javascript architecture was the use of a PubSub (publish-subscribe) library to communicate between the various parts of the app. So for example the AJAX API methods were fairly isolated – to enable their easy reuse – with their success states publishing the returned data for the viewmodels to pick up.

This decoupling did present a few edge case bugs around timing issues later on in development, but overall the ability to have communication, view state, preloading, sound and so on implemented independently and talking to each other via PubSub suited the Require modular loading we used as well as resulting in cleaner code.

This complexity of the application was borne out in the eventual size of the DOM, as we had several ‘pages’ within one document which were hidden and shown as required. For smoothness of experience this was useful, but retrospectively we’ve wondered if it might have been better to have a minimal HTML document with more extensive use of Javascript templating through Backbone or similar. Ultimately its hard to tell without implementing, but at least we have a steer for future iterations in this programme of projects.


Phonegap and other gotchas

It is well known that the performance of a web app wrapped in the Phonegap library is not as good as a native application.

Our previous Phonegap projects had a lot more DOM elements involved than this one so we hoped for better performance, but there were still a few performance issues on older iOS devices. Aside from that the Phonegap wrapping was pretty straightforward with minimal changes needed.

In the end perhaps the weirdest problem we discovered was that mobile service providers such as T-Mobile and Virgin appear to strip comments in HTML when sending data to mobile devices. This caused failures in our Knockout implementation, which used the library’s containerless control flow (i.e. specially formatted comments) to reduce the number of DOM elements – a very unexpected surprise. We ended up replacing all comment bindings with regular DOM bindings.


Device quirks – iOS[I] vs Android[A] vs Blackberry Z10[B]

– on-screen keyboard

[I] no viewport size change when hiding/showing the keyboard

[A, B] viewport size changes when keyboard is showing

[older A] even when the form page is hidden, the on-screen keyboard will not be dismissed unless the focus on the textfeld is forcibly removed.

– in-page scrolling

[A] even with overflow settings its still very buggy on the stock browser but Chrome doesn’t have problems.

– overflow: hidden

[older A] cannot interact with elements inside of “overflow: hidden” even if they are visible

– shake to undo (only on iOS)

[I] we found a filled-in form which was subsequently hidden triggered the iOS ‘shake to undo’ event. Unfortunately there was no known way for users to disable this feature easily but having an iframe somewhere in the DOM and changing its src (to anything) disables the “feature”. This hack doesn’t work if the app is wrapped in Phonegap but you can explicitly turn off shake to undo here.

– <audio> elements

[A] when a sound clip plays in an audio element it stops other background music from other apps

[B] the sound clip files are added to system playlist and so become accessible through its music player

– ‘devicemotion’ event

[A] on Android Chrome browser the ‘devicemotion’ event is not supported, although it is available on the stock browser. Future Chrome updates should add support.

– ‘orientationchange’ event

[older A] not supported


co-written by Stephen Fulljames



Device Independent Web – All For One, One For All

by Haro Lee

“All For One, One For All!”


What Happened…

A few days ago, I got an email with a url to an article on a website.
I clicked it without giving it much thought and the page opened on my web browser and for a moment I was puzzled as it looked quite not what I expected.

The font size was unnecessarily big, the paragraphs filled the entire width of the window, images were stretched, and I scrolled down and on the bottom of the pages there were several huge buttons filling all the available width.

At first I thought ‘what a badly designed website’ and then realised something was not right (other than it looked bad…).

I checked the url and it started with “mobile”.

Yes, it was the mobile version of the webpage.

I removed the “mobile” bit and it reopened the normal desktop version of the webpage now with a lot more comfortable look.

I figured out what happened there. The colleague was looking the webpage on his mobile phone and shared it by sending the url.

I’m sure many of you have the same experience.



I don’t want to start yet another debate what should a mobile internet be like or even the point of the existence of mobile internet (such as “There is no mobile internet” debates). There are plenty of other people talking about it with probably more knowledge than I have.

This post is not to argue or teach others what to do but just to talk about a little detail seems to be forgotten sometimes.

I appreciate the extra effort the people pour in to make their website look better on mobile devices or smaller screens.
Most of the times, it really helps my browsing experience.

But sometimes they seem to forget how advanced the mobile and web technology is becoming.

One example is Chrome browser on all the different devices.
As far as you are logged in, your browsing history and bookmarks are shared between devices. It knows what were the webpages you were looking on your phone so you can open them again on your desktop and vice versa.

It’s not just the browsers.

There are many many chances that you send an email with a link to somebody or even to yourself while browsing on your mobile phone and the recipients may open it on their desktop exactly like my experience above.  

That brings forward the importance of being versatile between devices.

In many cases if you open a webpage saved or sent from desktop on your mobile web browser, it correctly shows the mobile version of the page.

What it seems to be often forgotten is the opposite case.

Even a big company like BBC ( has forgotten it.

Maybe it’s like that so the developers can check the mobile version of website easily on their developing process, or just a simple memory loss, or hasn’t been considered at all, I am not sure.


A Little Thought…

One way to fix this quickly is just not to forget to check what device the webpage is opened on even on the mobile version of the website.

However, if you can afford to re-make the website, probably one of the most manageable ways of ensuring cross device experience will be using responsive web design. This may bring another good old everyone’s favourite debate of what and how responsive design should work but that is another story.

May your tool be Twitter Bootstrap (, Skeleton (, or HTML KickStart ( or whatever you choose to work with for an easier start, or even your own creation.

Responsive web design lifts at least the burden of managing two or more different versions of the same page or template for different devices and it comes with an extra peace of mind that you don’t have to worry about the different devices and screens available on the wild all the time.

Another side effect of responsive design I like is that it makes the user experience less cluttered by forcing the designers and developers to think more about what and how to show and not, of course that’s if they are bothered to be bothered…


New Birdsong Push Notification Service and v1.8

by Jon Sharratt

Just a quick post before the weekend to formally let you all know that myself and Joe today have released the new Birdsong push notification service.

Push Notification Service

We have released our shiny new service to Windows Azure today (a release on Friday…. naughty).  It has been a low risk release as the notification and live tile functionality as you all know hasn’t been working for a while.

With this in mind we wanted to get it right and have spent the past few weeks concentrating on implementing site streams from the twitter API to ensure we can provide you with almost instant notifications and live tile updates (phone connectivity depending).  I hope you all enjoy the new and improved service.  Development and testing has been an enjoyable challenge for myself, Joe and our test lead Samera.

NOTE: You will need to resave your notification settings for each account in your current Birdsong version (latest is v1.7) to take advantage of the new service.

NOTE: If you enable notifications in your current application favorited tweets and retweets will come through.  When version 1.8 is released these options will be configurable.

Birdsong v1.8 (Coming soon)

In regards to the next version of the Birdsong client we will be enhancing features for notifications to allow you to enable or disable toast notifications for favorites and retweets when they occur.

The final feature we have also added gives you the opportunity to turn on live in-app updates.  This feature will automatically refresh your timelines when you are mentioned or a direct message is sent to you.

As for the technologies we used and how the push notification was redesigned.  I shall leave that for another post…..

Have a great weekend, oh and don’t forget to set your do not disturb settings ;o)


Functions to consider for Mobile testing

by Samera Butt

Having a mobile version of an application has now become a must. With mobile devices ranging from different OS platforms and tabletdevices – as testers, we have a lot on our plate!!

However, there are key points that we must consider whilst drafting out test plans and scripts for any mobile device. In this blog I attempt to cover some of the key points along with functional testing we should consider for mobile testing…

User Interface

Unlike our desktops, mobile devices come with various interfaces, from small screens that can be re-orientated when the device is physically rotated, touchscreen only devices to those which allow a combination of touchscreen and hard keypads, soft keypad only and not forgetting the various navigation methods such as hard keys and trackballs.

Being familiar with the device you are/will be testing on is important, if you are not, ensure you have a play around with it before testing. Check for the following:

  • Check for overall colour scheme/themes of the device. For example, Windows phone allow you to change the accent colour and background colours.
  • Style and colour of icons
  • Progress indicators when pages are loaded
  • Menu’s – how they are invoked and typical items they contain
  • Overall responsiveness of the application on the device

Screen Orientation/resolution: Applications should be tested in portrait and landscape view. Rotating the device fast, and checking to see the application’s response and errors

Touchscreens: Things to consider when testing touch screens are:

  • Multi-touch such as : pinch to zoom and single touch.
  • Long touch and short touch. For example, on some phones, pressing and holding an item will bring up a context menu, or a secondary function of a button.

Button Size & Position: Buttons and icons should be large enough to be seen clearly and be clickable by a fingertip.

Workflow: Use of radio buttons and checkboxes to minimize the amount of typing required, as this can be time consuming.

External Factors

Factors such as interaction with other devices and interruptions from the devices own functions such as incoming phone calls should be considered.

Factors to consider are:

  • Loss of Network Connections
  • Memory Card usage
  • 3G Network, 4G network, 2G network
  • No SIM card in the device
  • In airplane mode
  • Test intermittent network scenarios that a user might encounter in the real world such as:
    • Walk out of Wi-Fi range so the connection automatically switches to 3G/2G (for example, in a large building like a hospital or airport, or outdoors)
    • Ride in a lift or on a train where the network connection may go up and down
    • No network connection available at all

Device Options such as Screen Timeout/Auto on/off: Is your application subject to screen dimming or automatically turning off even when it is actually busy? For example, you wouldn’t want your screen to dim or turn off while watching a slideshow of your photos.

Screen orientation: You may be able to enable/disable automatic orientation switches when the device is rotated. Does your application apply the setting set on the device?

Font: Does choosing a different font family, size, or style affect the appearance and usability of your application?

Connections: Using one of the connections on a device, such as Bluetooth or Microsoft Direct Push (only on Windows Phone devices), could have adverse effects on your application. How does enabling/disabling Bluetooth or other connection types affect your applications behaviour?

Emulator Use

Can be a great way to achieve testing coverage across multiple devices, but it is not safe to assume that just because your application works on an emulator, it will work on the actual device itself. When using Emulators, it is important to consider the following points:

  • Not all activities can be realistically emulated, like switching network connections, or taking a picture or video.
  • Some activities don’t work at all on emulators, like streaming video on a Blackberry emulator.
  • Due to lower device power and memory, the application could exhibit slower performance overall when run on an actual device (versus in an emulator on your powerful desktop computer).
  • If the emulator and actual device have different resolutions, your screens may not display as you expect.

Stress Testing

Mobile device applications have much less memory and power available than PC’s

Security Testing

This applies to applications which require sensitive data storage such as banking applications, and how the application behaves under various device permission schemes.

Mobile devices will no doubt continue to grow, and as testers we will need to keep up to date with the latest gadgets out there to keep on top of the latest changes in OS and functions belonging to a gadget. No doubt the device functions discussed in this blog will continue to grow.