21 December 2015, by James Griffiths
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.
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.
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.
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.
4 August 2011, by Matthew Richards
A DataSet is (to quote Microsoft) an in-memory cache of data. Essentially it’s a snapshot of part of your database. DataSets can be very useful, but they have some significant annoyances too. This article sets out a few of the key problems, and some possible solutions to attempt, based on extensive experience from building and (more significantly!) maintaining our Reservwire travel reservation product.