Skip to main content

Observations on web service design for mobile devices

This post was prompted by my use of back end third party services for the FINDaPAD app and my recent set of posts about push pins and Bing Maps control. I want to explore the affect the design of the back end services can have on a mobile app UX & UI design.

For FINDaPAD we make use of two sets of third party services, Nestoria & UK Crime API. Nestoria is a property search service for the UK and other countries whilst UK Crime API provides crime information for England & Wales, we use the second to generate crime stats for a local area when viewing a property in FINDaPAD.

Even though Nestoria claim on their website 'The API is very much a work in progress.' I believe this be a well thought out API from a consumers perspective, it has a compact data schema (JSON or XML) and it enforces a pagination convention on the consumer which has a bigger benefit for mobile app development than for full blown desktop for the simple reason of CPU performance and power consumption. We use two APIs from Nestoria, one for property details and the other for average property prices - one HTTP GET request for one set of results. It has well defined pagination API which limits the maximum page size to 50.

Shown below is the performance cost of making a HTTP GET request against Nestoria on a tethered WP7 device - it takes approximately 3.7 seconds to request the first 50 properties, decode the JSON and map into a domain model. The relationship between the number of properties downloaded and the time taken to download is relatively linear and predictable and this fact is import when designing how your UI reacts when downloading data - whether it sits there with a progress bar or allows the user to perform other actions.



The UK Police API is a less mature API having been around for about a year, it allows you to query for data by several different criteria.

In FINDaPAD we have to use two separate API calls to get the information we want - two HTTP GET requests for one set of results. First we have to make a HTTP GET request with our geo-location to get the police force & neighbourhood values and then a second HTTP GET request with the result from the first to get the crime stats for the current geo-location. Now this isn't a problem per-se for FINDaPAD because we request the crime stats asynchronously whilst we are trickling the property data from Nestoria to the UI so the user experience is a seem less transition from the details of property to the crime stats for the local area. Ideally this would have been done as a single web request not only from a performance point of view but from a cost - if you're paying for your data plan on your mobile device then you would have incurred a greater cost.

In my 'How many pins...' I was using a UK Police API to return all the crimes in a particular area, this was based on the idea of supplying a geo-location and it would return all the crimes occurring within a 1 mile radius for the last calendar month. This API call works great when tested from a desktop app or the WP7 emulator because both have plenty of processor power, memory and network connectivity. But when running on a device it can be an issue because the returned data set has an unlimited size and the cost in time to transmit this down the wire, decode etc is unknown - fundamentally the API does not support pagination. This is best demonstrated by the following set of screen shots, searches for crimes in totally different locations, one a remote rural area and the other an urban inner city area:




The first screen shot shows the cost to get all the crimes in a rural area (where there are no crimes) and the second in the urban inner city you can see how the elapsed time has increased, if the total crimes in the urban area increases I don't have anyway of calculating how long it would take to request and process going results and ultimately this could lead the user to abandon the app (and give it a bad rating!).

So you might ask - Okay how would you do it then?


If I was going to keep the API endpoint the same - all crimes in a 1 mile radius. I would add pagination support so that I could trickle the data to UI as each request is fulfilled. If I was going to change the API I would like the ability to specify a bounding rectangle so I could request only the visible crimes, this would also require pagination as the number of crimes could be even greater than the 1630 show above. Though there could be a downside to the second approach as this would make client caching more problematic.

Don't be under the impression I think the UK Police API is bad or wrongly implemented, I believe this APIs will mature over time as greater understand of how the data is being used.

Remember not all publicly consumable web services are well suited for use with mobile devices.

Comments

  1. Nice article. I think it's well worth looking to the "cloud" to act as the proxy between you mobile app and the services you are consuming (I believe AppFlow uses Azure for this). You can then a) tailor the service to trim down the data b) provide more appropriate caching for your app c) more easily automate regular testing against your proxy API to ensure your App hasn't broken due to 3rd party api changes.

    ReplyDelete
  2. Interesting, I thought about this as well and I'm starting to think this would be an approach to 'smoothing out' and aggregating the data into a structure I want. The only concern is the increase in size of the code base (which could be argued against) and also the cost of using the cloud.

    ReplyDelete
  3. This is a very good tip especially to those fresh to the blogosphere. Brief but very precise info… Thanks for sharing this one. A must read article! Feel free to visit my site ::
    PHP developer London

    ReplyDelete

Post a Comment

Popular posts from this blog

WPF tips & tricks: Dispatcher thread performance

Not blogged for an age, and I received an email last week which provoked me back to life. It was a job spec for a WPF contract where they want help sorting out the performance of their app especially around grids and tabular data. I thought I'd shared some tips & tricks I've picked up along the way, these aren't probably going to solve any issues you might be having directly, but they might point you in the right direction when trying to find and resolve performance issues with a WPF app. First off, performance is something you shouldn't try and improve without evidence, and this means having evidence proving you've improved the performance - before & after metrics for example. Without this you're basically pissing into the wind, which can be fun from a developer point of view but bad for a project :) So, what do I mean by ' Dispatcher thread performance '? The 'dispatcher thread' or the 'UI thread' is probably the most

Showing a message box from a ViewModel in MVVM

I was doing a code review with a client last week for a WPF app using MVVM and they asked ' How can I show a message from the ViewModel? '. What follows is how I would (and have) solved the problem in the past. When I hear the words ' show a message... ' I instantly think you mean show a transient modal message box that requires the user input before continuing ' with something else ' - once the user has interacted with the message box it will disappear. The following solution only applies to this scenario. The first solution is the easiest but is very wrong from a separation perspective. It violates the ideas behind the Model-View-Controller pattern because it places View concerns inside the ViewModel - the ViewModel now knows about the type of the View and specifically it knows how to show a message box window: The second approach addresses this concern by introducing the idea of messaging\events between the ViewModel and the View. In the example below

Implementing a busy indicator using a visual overlay in MVVM

This is a technique we use at work to lock the UI whilst some long running process is happening - preventing the user clicking on stuff whilst it's retrieving or rendering data. Now we could have done this by launching a child dialog window but that feels rather out of date and clumsy, we wanted a more modern pattern similar to the way <div> overlays are done on the web. Imagine we have the following simple WPF app and when 'Click' is pressed a busy waiting overlay is shown for the duration entered into the text box. What I'm interested in here is not the actual UI element of the busy indicator but how I go about getting this to show & hide from when using MVVM. The actual UI elements are the standard Busy Indicator coming from the WPF Toolkit : The XAML behind this window is very simple, the important part is the ViewHost. As you can see the ViewHost uses a ContentPresenter element which is bound to the view model, IMainViewModel, it contains 3 child v