Background

Research into segregation has generally focused on residential patterns, and pays no attention to how people actually live their lives. In order to tackle this, Dr Jonny Huck developed a mobile app for Android phones to collect data to look at the impact of segregation on human movement in Belfast.

Jonny wanted an alternative approach where it was possible to see how patterns of segregation impacted upon people’s behaviour and mobility (i.e. where they went and when; where they didn’t go and when) - this is particularly important in somewhere like Belfast, where territorial boundaries can be which side of the street you are on, a particular lamp post, and other similar features that can only be captured with the most detailed tracking. His app attracted a lot of interest as it was quite a novel approach to the problem.

Jonny was recently contacted by researchers from the Pontificia Universidad Católica de Chile who wanted to replicate Jonny’s methods. Chile has a diverse population, with people from its bordering countries as well as parts of Europe and Asia living and working there and the researchers wanted to look at interactions between various migrant groups (predominantly from elsewhere in South America). The Manchester team were invited to join the Chilean project as researchers in order to help them look into this issue, and also to do some work into the ethical challenges surrounding the collection of GPS data in this way.

It was hoped that the original app could be reused but since the deployment for the Belfast study, Android’s libraries have moved on and the app no longer works due to changes in privacy requirements. The Chilean researchers asked if Jonny would be be able to upgrade the app or make a new one as there was funding available but, due to time constraints, he approached the MDS team instead to make a new version.

Jonny brought invaluable experience and expertise to the task by acting as a liaison / intermediary between the MDS and Chilean teams. He brought the initial requirements to the table and reported back and forth with any further questions and answers put forward to try and pin down the app’s specification. Once the development had begun and iterations of the software were available to demonstrate, the whole group met virtually to discuss the next steps to take.

App overview

The application, called Location Logger, has the simple aim of capturing and storing the GPS data of its users over a period of time. This data, when matched with some basic demographic information of the user such as age, sex and country of birth, could then be transposed onto a map and any gathering patterns could more easily be observed.

Although designed to be available on both the Apple and Google Play stores, the app is for use by a limited, known group of users for which the required demographic information has been collected via an ethically-approved consent process. In order to restrict access to this userbase, the application requires an alphanumeric code to be entered to complete the setup following installation (Figure 1). All User Ids were randomly generated and stored within the code, with a duplicate list being administered by the Research Team in Chile so data collected (which was transferred with the entered User Id) could be cross-referenced against the master list.

When the user logs in for the first time, the language is selected from the three available translations (Figure 2), and this can also be changed at any time (with immediate effect) by clicking the globe icon in the upper right of the screens within the app (see Figure 1).

The app is designed to be used with minimal user input. It is in fact coded to run in the background with no interaction being required following the launch and subsequent starting of the GPS service (Figures 3 & 4).

Once running, the application should capture a GPS point whenever the user moves laterally more than 25m away from their previous position as detailed in the specification. This “distance trigger” approach was chosen to minimise spurious, duplicate GPS data being collected as would have been the case if a “point-per-X-seconds” (time trigger) method was utilised. It also tries to reduce the possibility of including data captured when GPS accuracy is limited and the location is constantly being locally refined (when indoors, for example, with the signal scattering and registering movement).

The data collected is stored on the device and buffered until approximately 25km of movement has been registered, or a period of 6 hours has passed since the last data transmission. The data is then sent (via Wi-Fi by default, to minimise phone data usage) to the Research IT ‘Storage Connect’ database service, where it is accessible by the research team to download and process.

Technical overview

The app was required to run on both Android and Apple (iOS) devices, and this was implemented by the MDS team using the Xamarin.Forms 5.0 cross-platform mobile framework. Xamarin is an open source tool from Microsoft which can be used to build Android, iOS, Windows 10 and Mac OS apps leveraging .NET, and it is currently the tool of choice for MDS work. It allows a shared codebase to be used in the most part; from which the required packages for each device platform are generated and compiled. It does, however, give the developer the ability to write platform specific code where required to implement features directly from the platform-specific SDKs – as was done in this case for the GPS functionality.

Overall, it seemed a simple premise for an application, however, as time and privacy laws have progressed and changed there has been a move towards the tightening of control over phone devices with regard to what can and cannot be run or done without user acceptance and interaction. So-called “background operations” as of later versions of Android and iOS are now given much less freedom to consume device resources. These changes meant it proved to be a far more complex development process than initially thought, and threw up unexpected problems which needed to be tackled.

Technical challenges

Platform specific GPS:

Although a cross-platform mechanism for getting GPS data is available for Xamarin applications via Xamarin Essentials, because the facility was required to run in the background, MDS developers were forced to looking into a platform-specific solution. iOS and Android both implement GPS functionality in vastly different ways, so the shared code within the Xamarin solution needed to be developed in such a way that it would compile the correct code for each platform at build time. This platform-specific code needed to be added to each platform’s designated project within the overall solution, and built so that it could be ‘injected’ into the relevant build. Although standard practice, detailed knowledge of both Android and iOS Geolocation APIs was necessary, in order that the implementation in both were as similar to each other as possible.

Running app as a background service:

As mentioned previously, the tightened control now put in place on both the iOS and Android platforms meant that running an app as a background service (especially one getting location data!) has become increasingly difficult to achieve without damaging the user experience with multiple and seemingly random requests for user acceptance to allow location data to be captured.

Location based apps are generally preferred and trusted when they are run by the user (in the foreground) such as using location to provide navigation information or a dot on a Google Map. They are also far more accurate if they have the full resources of the phone allocated to them with the OS designed to prioritise polling requests from apps in the foreground. Furthermore, apps running in the background are given lower priority when it comes to memory and CPU cycles, meaning that if the OS believes system resources are running low, it has the authority to kill the process without warning to save memory and possibly battery power. All this makes life that little bit harder for developers to achieve the level of functionality they want. This was a huge problem for an app designed to run without intervention.

Auto app restart upon device reboot:

As part of the requirement to run with minimal user interaction it was specified that the app should run in the background and also restart upon the device being rebooted if the service was running when the device was shutdown. Part of this feature request was also to adopt the same enabled/disabled state of the app which was in effect prior to the restart, but this proved to be untenable: Apps on Android can register to receive a notification internally when a device has rebooted which allowed the team to present a notification to the user to go and start the actual GPS service running again if required. However, iOS doesn’t have any mechanism for this to be done on iOS 15.5 so the feature could simply not be implemented.

Outlook

The app is currently undergoing a beta test in Chile and MDS are working with the researchers directly to further tweak the settings to ensure consistent levels of data resolution. The app will be available via the University of Manchester Google Play and App Store pages later this year.

Contact Us

If you are thinking about developing a mobile app yourself, or would like the MDS to develop one for you, get in contact either via the team email address.