Softwire Blog

2016 internship – the Do-It For Good mobile app

1 December 2016, by

The Do-it Trust promotes the use of social technologies to enable social action and volunteering. They are a digital social action charity behind Do It which is the UK’s digital home for volunteering.  The Do-it Trust have been doing a great job promoting charity events – in just over 18 months they have registered 200,000 new volunteers.

We approached the CEO of the company, Jamie Ward-Smith, to ask whether they would like us to build a mobile app for them free of charge as a part of our summer intern’s training. We grouped the summer interns together, assigned them a senior developer as a full time trainer and they got to work on a real project and experienced the full lifecycle of a software project.

Mobile App

The aim of the mobile app is to make it easy for volunteers to apply for charity events based on their interests and skills they would like to gain.

Do It App

One of the main features of the app is a built-in chat system which enables the event organiser to contact the participants to have a group chat about the event. We also made it simple for users to share the events they are interested in on various social media platforms to create more awareness about such events.

Do It app sharing

As a result of having a mobile app, Do-It will be able to reach more people and make participating in charity events more interactive via the built-in chat system and an option to share opportunities on various social media platforms.

Do It menu

Do It oppotunity

To be able to use the app on various devices, we used the open-source mobile development framework Cordova.

About the project

The Do-It project provided the perfect balance of a meaningful real world project which would have real benefits for the users, contribute to our corporate goal of doing more pro-bono work and had relaxed deadlines to enable us to provide quality training.

The Do-it team gave us a lot of flexibility and they were open for suggestions and our ideas. This meant that interns could actively be involved in the decision making process which made everyone feel like a valuable part of the app development. We believe that the interns working on the mobile app got a fun and rewarding internship during which they learnt skills and gained valuable experience that they can take with them.

Available on the App Store and on Google Play.

Do It For Good


Cross platform phone apps

28 October 2016, by

If you want to write a phone app, and want it to run on multiple platforms, but don’t want to spend large amounts of time maintaining two code bases, then there are several solutions that allow writing one app, and deploying it to several platforms.

These multi-platform apps work by running a mini website on a phone, which is accessed via a web view, which is how the app appears native.

In this post, we’ll discuss several different approaches to writing a multi-platform app, and have a look which situations you should choose each option.


A War on State

3 February 2016, by

Here at Softwire, we’ve been busy building a mobile app for a chain of health clubs, and this is the final post in a four-part series about our experience and what we’ve learned.

We’ve chosen to build the app using Apache Cordova, so our code can easily run on both iOS and Android platforms. Take a look at the first post to read about what Cordova is, the second to see some of the practices we use to make Cordova feel as app-like as possible, and the third to see how we keep our transitions smooth in KnockoutJS.

In the nearly 16 years we’ve been around, we’ve supported many customers’ projects – including maintaining and supporting this customer’s pre-existing web application, which allows users to book exercise classes and tennis courts. All this has given us great insights into what makes software easy or difficult to maintain.

One of the major causes of difficulties in the old website, and elsewhere, is unnecessary state.

As you browse the website, the site builds up a large collection of state about your visit, which it then uses to work out what should be displayed on each page. This means if we find a bug it can be quite time-consuming to work out where each piece of state was originally set, and how the various pieces of state interact.

For the mobile app, we definitely didn’t want to repeat this mistake. We decided to declare war on state and to focus within this project on making the app as stateless as possible, so it was easy to reason about, understand, and maintain in future.

What did this mean for us?

There’s an API for that

To start with, we decided that the app should communicate with the back-end booking system using a stateless RESTful API.

Each API request that the app makes contains all information that the API needs to complete the request, meaning that the API doesn’t need to remember details of any previous requests.

This makes testing significantly easier, as the back-end API can now be tested separately from the app. Debugging is also much easier, as the isolated requests make it clear whether a bug is caused by the app, or the API.

Let’s go on a journey

The design of the UI in our app is reasonably complex; it’s built from hundreds of moving parts, each of which can change depending on the state of the user’s booking.

To reduce the amount of common state that we have to deal with we’ve divided the UI of our app into 3 ‘journeys’, each of 4 separate pages. Each journey is responsible for the flow between various pages, and the interactions between the pages required to make this work. Each page is then responsible for the details of a specific part of that journey.

These are represented by ‘journey’ and ‘page’ view-model objects within our code; any state relating to how the journey and pages are displayed is stored on these objects. Each time the user starts a journey, we create a new instance of the journey and page objects, and when the user leaves a journey, we destroy the journey and page objects. This ensures the journey and pages never contain state left over from a previous visit.

On a strictly need-to-know basis

In the old website a great deal of information was passed between pages, including large, complex object models, dramatically increasing the complexity of the codebase, and making it hard to tell where any information came from.

For the mobile app we have taken the opposite approach and pass around as little information between pages as possible, usually just a single ID, e.g. the ID of the exercise class being booked, or the ID of the booking.

We’re using the repository pattern throughout to enable this. We have a set of repositories in our javascript code which load data and manage internal caches using HTML5 local storage, and we’re then able to get away with just passing IDs between pages, because we know the next page will be able to load any information it needs from the repositories at very little cost.

If it breaks, turn it off and on again

Within our app we’re using quite a few fancy UI widgets. One of them – a swipeable carousel of dates – doesn’t play very nicely with Knockout: every time we change the list of available dates, the widget re-draws the carousel vertically, rather than horizontally! Clearly this widget isn’t stateless, sadly, as it’s appearance isn’t just a function of its inputs, but is also affected by its previous state.

We spent a while trying to fix this in the widget itself, but to no avail. Fortunately, we then thought of another approach: instead of changing the list of dates, simple destroy the old widget and create a new instance with the new set of dates, which worked a treat.

This change essentially makes the widget stateless, from our point of view, by destroying and rebuilding it at any time when the state might change, so that the widget’s appearance is instead based only on its current inputs. When statelessness gets difficult frequently and pre-emptively “turning it off and on again” can actually get you remarkably close!

Smooth transitions in Cordova / Knockout

15 January 2016, by

Here at Softwire, we’ve been busy building a mobile app for a chain of health clubs, and this is the third post in a four-part series about our experience and what we’ve learned. Watch this space for the next instalment, or follow us on twitter for updates!

We’ve chosen to build the app using Apache Cordova, so our code can easily run on both iOS and Android platforms. Take a look at the first post to read about what Cordova is or the second to see some of the other practices we use to make Cordova feel as app-like as possible.

One of the important requirements was for scrolling and transitions to be smooth and to avoid the screen juddering. Lack of polish and smoothness is one of the most common objections raised against Cordova; it’s an easy trap to fall into, but simpler than you might expect to solve once you’re aware of it.

Work with the phone

Modern phones have powerful graphics processors, so we want to offload as much of rendering onto the GPU as we can, to keep the CPU free and ensure our rendering goes at top speed.

Let’s say we’re using CSS to move an element ‘my-page’ off the right of the screen by applying the ‘off-right’ class.

We could write:

#my-page {
    left: 0;
    transition: left 1s;
} {
    left: 100%;

This will work, but it’s not typically run on the GPU by most browsers, which means performance may take a hit if you have many or large elements moving like this across the page.

Fortunately we can replace this equivalent to get GPU acceleration, with:

#my-page {
    transition: transform 1s;
} {
    transform: translateX(100%);

The ‘transform’ property here is designed to be easy to handle on the graphics processor, and so runs much more smoothly.

Don’t stop me now

We’re building our app as a single-page website, within Cordova. As part of this, we’re using Knockout.js to do data bindings. Knockout is a simple way of keeping your javascript object models in sync with the HTML (or ‘binding’ them together, in Knockout lexicon).

It’s important to understand how this works to improve performance though, with Knockout or other similar frameworks. When you change the value of a Knockout-observed variable, Knockout will immediately make the corresponding change to the HTML, and each of these changes in the HTML will cause the browser to re-render the relevant part of the page. If a large part of the page is moving when this re-render is trigger then it will appear to stop, re-render and then continue moving, causing a noticeable judder.

This is particularly noticeable if you update properties across an array of objects. Knockout interprets each of these as a separate change and causes the page to re-render multiple times, resulting in a very juddery transition! Doing this is generally bad for rendering performance, but it’s a very easy pattern to fall into with many modern single-page app frameworks.

To solve this, in our app we’ve been careful to make sure we never change knockout-bound values whilst we’re transitioning. When we move between pages, we’ve adopted a workflow like this:

  • 0 ms
    Create new page, start loading data and binding each part to the page.
  • 100 ms
    Pause data bindings. Put any data change requests in a queue.
    Start transition (transition lasts 500ms).
  • 600 ms
    Resume data binding. Process any queued requests.

In our testing we’ve found that the first 100ms is typically long enough for data to be fetched from the cache and rendered, when it’s already cached, without being long enough for the user experience to suffer.

Nothing to see here

Generally, we’ve been very happy with the performance of Knockout, but it’s performance can degrade with increased load. Every data-bound value causes extra work for it, and slightly reduces performance. For best performance, we should minimise the amount of data that Knockout is binding.

For us, this means segmenting the app into different ‘journeys’ and ‘pages’ and ensuring Knockout is only data-binding the journey and page currently in use, and disposing of the data and DOM elements not relevant to the current page. Within some of our larger pages, we take this further, and change what data is bound as the user moves around the page. This requires some discipline for us to remember to destroy pages and journeys as soon as we’ve finished viewing them, but has been well worth it in performance benefits. If there’s “nothing to see here” then it’s best if Knockout doesn’t have to keep track of it.

All this has come together for us fantastically; despite being built with Cordova the app feels snappy and quick across a wide range of devices, and our customer is very happy with the result.

In the fourth and final post we’ll look at how we architected the app to ensure maintainability for the future. Keep an eye on our blog for the next edition, or follow us on twitter for updates.

What does it mean for an app to feel like an app?

21 December 2015, by

Here at Softwire, we’ve been busy building a mobile app for a chain of health clubs, and this is the second post in a four-part series about our experience and what we’ve learned. Watch this space for the next instalment, or follow us on twitter for updates!

We’ve chosen to build the app using Apache Cordova, so our code can easily run on both iOS and Android platforms.

As a quick recap: Cordova is cross-platform way of building mobile apps using web technologies. As a developer, you write a regular website using HTML, CSS and javascript, and Cordova takes this website and creates an app that is a wrapper around the website.

For the iOS app to be available on the App Store it needs to be approved by Apple. One of Apple’s requirements that is particularly relevant for Cordova apps is that the app “feels like an app, not like a website”.

What does this mean for us? There are a lot of components to this, but in this post I want to look at how it’s affected our approach to client-server interaction.

No 404s

We’re lucky to have some really nice designs for the app, and we wanted the entire UI to live up to these.


To keep this user experience really smooth one thing we really have to ensure is that we don’t ever show the user an ugly 404 page.

On a regular website, a user moves from one page to another. Each page is loaded individually from the server and contains the data they have asked for, as well as the code needed to take them to other pages.

This wasn’t an option for us. Our app users might be on the move, underground or have a slow data connection. If we built the application extremely minimally as a wrapper around a traditional server-hosted application then we’d be making these page requests in an environment where they might fail. We can’t risk showing them an half-loaded page or, even worse, a 404.

Load data, not code

To solve this, we’ve built the application as a single-page website. All the code is bundled into the initial download – that way, all our pages load instantly, without having to wait for any code to be downloaded. This approach is an important part of good Cordova development, and helps solve the error handling issue above and reduce latency for users to keep the app feeling snappy.

The only communication we have with our servers is to send and receive data (rather than code). We have a RESTful API that manages all our operations, like loading class timetables, making bookings and getting club opening hours.

If any of these API requests fail we can show the user a pretty error message, and allow them to retry, without the app looking broken.

Smooth transitions

The app looks beautiful so we want it all to perform well on the phone. That includes loading pages, but we also want scrolling, swiping and transitions to all be smooth, and to avoid the screen juddering.

In the next post we’ll look at how we achieved this. Keep an eye on our blog for the next edition, or follow us on twitter for updates.

Write an app without writing an app

16 December 2015, by

Here at Softwire, we’ve been busy building a mobile app for a chain of health clubs, and this is the first post in a four-part series about our experience and what we’ve learned. Watch this space for the next instalment, or follow us on twitter for updates!

We were recently asked by a large chain of health clubs to build an app for both iOS and Android platforms. We chose to build the app using Apache Cordova, rather than writing separate native applications. Why did we choose Cordova, and how do you get started with it on a new project?

The problem with native apps

At Softwire, we’re used to building native mobile phone apps, but building native apps comes with a number of difficulties:

  • Each platform requires you to learn and use a specific programming language, development environment and set of libraries.
  • You have to maintain a separate codebase for each platform and keep the code in sync between platforms.
  • Each platform has its own quirks and bugs will typically be different in each platform.

All of this makes native development potentially more expensive and risky, and we’ve been interested in investigating other approaches for a while.

What’s the alternative?


Our work for Yudu – A Retrospective

14 March 2015, by

Softwire built a next-generation digital publishing platform for YUDU media, which powers more than 1,000 new publications and 1,000,000 page views every day.

The Challenge

Build a bespoke, highly scalable digital self-publishing platform allowing publishers of all sizes to create feature rich, interactive publications at the click of a button.

YUDU Media asked us to build an online digital publishing platform. The system had to provide a cost effective way for publishers to take their content online, without making a major technology investment. They required a sophisticated web-based publishing interface, which could turn raw PDF, Word, Excel or PowerPoint files into an interactive experience for the reader. Publishers could enhance their publications by adding rich media elements, from videos to order forms, graphs and HTML5 interactivity, without any need for technical knowledge.

The end product had to be simple to use for all end users, both the publishers themselves and the readers. The system also needed to be able to cope with high usage volumes, with 1000’s of readers using the application at any one time.

The Solution

Softwire paid close attention to detail in the scoping phase and took an agile approach to the development phase allowing us to create a highly adaptable, highly useable end product.

Softwire’s customer-centric and agile approach to development helped us to create a product which met the rapidly evolving needs of our client. Our autonomous team kept in regular contact with YUDU’s project manager regarding requirements and carried out speculative development phases to determine fiscally viable product features where requirements were not fixed. This helped Yudu to grow their product offering to the needs of their business and their market.

The core platform was developed using Java Enterprise technologies, including JBoss application server, Spring MVCX and Java EE, and uses Oracle databases. Dedicated PDF processing servers carried out the heavy-lifting of converting PDF files to a flash compatible format. The product also included an Epublishing marketplace implemented in Ruby to allow users to organise, promote and sell their publications. It also included a statistics server with a reporting web interface to monitor reader behaviour. Publications were rendered via a browser-based flash based page turning application.


The Outcome

Successful delivery of the system has allowed publishers across the world to digitalise their titles and YUDU have grown into a multinational award winning company.

Softwire have continued to work with YUDU to steadily build upon the original project. YUDU’s product is now used by just under 1000 publishers globally including TimeOut, Readers Digest and the Beano. More than 1000 YUDU publications are published and over 1,000,000 YUDU pages are viewed daily across the world.

Softwire’s expertise and attention to detail allowed YUDU to take a high quality product into the rapidly evolving market place of digital publishing. We have worked with YUDU as they have grown from a start-up company, to continually offer high levels of code, design and customer service.

Time Out on Yudu

Paper prototypes on your iPhone

22 July 2013, by


This week a colleague sent me a link to POP App, a new tool for making paper prototypes interactive using your iPhone.

POP allows you to take photos of your paper prototype using the app and then highlight link spots so that users can move between pages.


It’s super easy to use, and once you have completed your prototype you can share it with other POP users or with anyone over the internet.

Here’s my first project – a cave adventure.!/projects/51cf24d8012b36cb0e0006f7/preview

This post originally appeared on Zoe Cunningham’s personal blog

Recommended viewing: Design on mobile platforms

17 April 2013, by

We found these videos on design for mobile platforms useful:

Testing and Debugging Webpages for BlackBerry Mobiles

22 January 2013, by

If you are testing a webpage you have developed for BlackBerry mobiles, then the BlackBerry website is a useful place to visit as it has simulators of all their devices available to download. Once installed, the simulators that are running OS6 or higher can be used to view your webpage in their browser straight away. To get the browser working on OS5 simulators or older, the BlackBerry Mobile Data Service simulator (MDS) needs to be installed and run, instructions for doing this on Windows 7 x64 can be found in this helpful blog post here (this is a link to the Google cache version as the site is down at the time of writing).

The most useful thing I have found is, since BlackBerry OS7, there is now a way to debug webpages, which is very useful as the BlackBerry browser has a lot of quirks, despite being Webkit based since OS6. The following can be done in either the simulator or on an actual device:

First of all you need to go to the Browser Options and ensure ‘Enable Developer Tools’ is selected. In the browser you then need to bring up the menu by pressing the BlackBerry button and select Developer Tools > Enable Web Inspector. A popup will then display an IP address and port number.

You can then connect to that IP address using a Webkit based browser on your PC (or a PC on the same network as the device if you aren’t using the simulator) and select the site that is being displayed by the BlackBerry.

Once you have selected the webpage you have access to the full debug tools that are available to Webkit browsers, which are very useful for figuring out why that <select> is appearing twice as large as it is on every other browser.