A 'Series of Online Research Software Events' (SORSE) aims to enable Research Software Engineers (RSEs) all over the world to engage with their wider community during lockdown and beyond. Chaired by Peter Schmidt, who leads mobile development efforts at UCL, and accompanied by fellow panellist Mark Turner, who leads the RSE group at the University of Newcastle, Patricia and Adrian participated in a roundtable discussion about providing a mobile service in Universities and took questions from an audience of around 25 attendees. After a brief introduction by each of the panellists, the discussion covered a wide range of topics over the one-hour recording. There were a wide range of questions which provoked a great deal of discussion and these have been summarised below.
What is the real demand for mobile apps in research and where does it come from?
In year one of the MDS we built twelve apps, in year two we have already built ten and have six more in the pipeline. As a minimum this is a demand of roughly one new app request every month – and those are just the ones that are funded. The team has tripled in size over the same period to meet the demand. Not only does MDS build apps, but it also supports researchers to build their own as well as deploys apps developed by external companies (see our post on the three-tier service stack). These requests come from all three faculties but with Science and Engineering bringing up the rear.
What influences your choice to develop an app using a cross-platform framework versus doing it natively?
This is not really a binary choice. Writing “native” apps typically refers to writing an Android app in Java/Kotlin using the Android APIs or writing an iOS app in Objective-C/Swift using the iOS APIs. Cross-platform previously meant writing an app as a web site which was displayed in an embedded web browser. However, cross-platform options have come a long way, with a great variety of available frameworks. The MDS chose Xamarin which is an open-source framework from Microsoft (see one of our previous blog posts). Xamarin is designed as a wrapper around, while binding directly to, the native APIs. This gives you a certain amount of flexibility between writing platform-specific code to access device-specific features while also writing cross-platform code in the same project. But to turn the question on its head, why would you need to write an app natively?
The only reason we can think of is to ensure maximum performance by “cutting out the middleman” that is the higher-level bindings and intermediate language compilation. However, in the apps MDS has produced in the last two years, such performance requirements have never materialised.
The main reasons we chose to use a Xamarin though remain largely strategic:
- To speed up development time; developers only need to write code and tests in a single language using a single IDE.
- To maximise code-sharing between platforms: typically, around 80% of the code base is shared between the Android and iOS apps so an app is largely written once with the same experience on both platforms.
- Access to device-specific APIs is straightforward due to the one-to-one bindings and can be abstracted into reusable cross-platform components if necessary.
- Many of the RSEs in the Manchester group have .NET expertise. Hence, the technology builds on the language skill we already had available to allow us to get up and running quickly without needing to retrain.
- The Xamarin community offers a wide range of reusable packages and plugins that allow for rich features with little additional work required. Xamarin can also make use of a plethora of .NET libraries directly through the NuGet package manager.
- It links in easily with Visual Studio App Center for crash monitoring, analytics and Continuous Integration and automated testing as well as Azure for push notification services and file storage.
Who is doing the user interface design for your apps?
In our experience, researchers pay little attention to UI and UX and would rather budget be spent on features. We are happy to oblige, although our RSEs do maintain an awareness of example UI best practice. We also have the option of farming the work out to University Marketing and Communications for a slice of the available budget and have even done projects where UI designs have been provided to us in advance produced by an external graphic design company.
There were also some more perhaps poignant questions from the audience which included:
How do you go about maintaining apps once they are on the stores as they can be there for years?
The decision to appoint as many RSEs as possible on permanent professional services contracts at Manchester means that MDS can allocate a portion of developer time to the long-running task of maintenance as required. Not all RSE groups across the UK are able to offer this and something we are particularly proud of in Manchester.
How does things like research ethics factor into app deployment?
The MDS encompasses the full set of app lifecycle responsibilities including having the privilege required to manage their own app testing, release and deployment through the University Apple Developer and Android Developer accounts. Consequently, the MDS also administers a full governance process for mobile apps that are deployed either through the stores or otherwise. A key element of this process for research apps is ensuring the relevant ethics submissions and data management plans are in place, approved and up to date prior to an app being deployed into production. In addition, apps that collect or process data are also reviewed by the Information Governance Office at the University via an Information Governance Risk Review screening assessment.
Find Out More
The webinar is set to go live on the SORSE YouTube Channel next month with the audio expected to feature as an upcoming episode of the RSE Stories podcast.
If you have are further questions for us, feel free to email us using the MDS email address and we’ll be happy to answer them for you.