CRUD-Capable Mobile Apps with R and shinyMobile: a Case Study in Rapid Prototyping

Mobile app development is becoming increasingly complex. A statistical programmer faced with the task of creating a mobile app with data science components must compare a growing number of technology stacks to determine the best development method (Kasprzak et al., 2020). If a developer wishes to take full advantage of native capabilities, they will need to learn Java or Kotlin for Android development, and Swift for iOS. If instead, one wishes to create an app that will work on both iOS and Android, they will need to consider a cross-platform Javascript framework such as Ionic or React Native, or perhaps an alternative language such as Flutter. From these two options, a single code base has several advantages, including reduced development and maintenance costs (Corral et al., 2012). However, each of the aforementioned languages has a steep learning curve, presenting a significant barrier for many in statistical fields, who are often limited in their general programming abilities (Chambers, 2000).

Statistical programmers are often self-taught, or have learned the basics of programming from one or two papers at university. Many lack a fundamental understanding of programming principles (such as the conventions of object-oriented programming) that are generally required for development of complex apps. These factors make the transition from languages such as R to app development languages such as Java or Swift, an intimidating task with a steep learning curve and time barrier. In particular, the prospect of maintaining multiple code bases for different platforms is intimidating, especially for a lone programmer (Heitkötter et al., 2013). Additionally, while other app development languages may provide access to plotting libraries, none of them are able to match R for its conciseness of statistical code, graphical flexibility, and range of statistical packages. However, it is not possible to install the R runtime on either Android or iOS, making it impossible to incorporate R code into a native mobile application.

The Progressive Web App (PWA), a set of web standards recently developed by the Google Web Fundamentals group, provides an alternative to native mobile app development frameworks (Biørn-Hansen et al., 2017). A PWA, despite being a web application, can be installed on iOS and Android such that it appears to have native functionality. App icons appear in native format, and the app runs in a fullscreen WebView wrapper. While there are limitations to this format (such as lower performance and lack of native hardware functionality, discussed later in this paper), these are often deemed trivial when considering an app’s requirements.

Previously, to build a PWA for mobile, expertise in HTML, CSS and Javascript was required, along with general web development skills. However, the shinyMobile package (Granjon et al., 2021) provides programmers versed in R with the ability to produce fully functional web apps for mobile, with no experience required in any of these languages. This removes a number of barriers for entry into the mobile app market for statistical programmers (Elliott and Elliott, 2020). As an additional benefit, apps created with shinyMobile also run well on desktop and tablet devices, with the tabbed interface adjusting naturally to different screen sizes. This is largely due to the flexibility of the underlying shiny dashboard framework, which combines with shinyMobile to create a fully reactive app (Chang et al., 2021).

To install a PWA on a mobile phone, one simply needs to open the website in which the app is housed in a supported web browser (such as Google Chrome, Safari, or Mozilla Firefox), then use the browser-specific options menu to add the app icon to their home screen. The app then has the appearance of a native app, with no download required. While the installation process is slightly unconventional when compared to apps installed from Google’s Play Store or Apple’s App Store, it is straightforward and can be completed within a minute, if instructions are followed correctly. As PWAs become more common, users worldwide are more likely to be familiar with the installation process.

We used the shinyMobile package as our primary framework for developing the ‘Harden’ mobile app, which is designed to help addicts to perform a self-monitored Ecological Momentary Assessment (EMA) to reduce their rate of relapse. This app had several unique requirements:

1. 1.

   Available to mobile users, preferably with near-native appearance, functionality and speed

2. 2.

   Advanced graphing with interactive components for self-analysis of variables

3. 3.

   Moderately advanced statistical capabilities, such as data wrangling in the backend, and automated calculation of correlations and uncertainties

4. 4.

   Intuitive data entry - the user needed to record multiple variables on a daily basis with ease

5. 5.

   Straightforward user settings

6. 6.

   Daily notification capabilities

7. 7.

   Compliance with relevant security protocols (i.e. HIPAA, GDPR, et cetera.)

8. 8.

   Persistent data across user sessions - users needed the ability to view data they entered into the app on previous days

9. 9.

   Authentication, so users could only access their own data.

By using the shinyMobile package to turn this project into a production-ready PWA, all but one of the requirements above were met directly, with notifications not being generated directly by shinyMobile. Workarounds for this are discussed in the Limitations section, below.

The shiny concept was extended to enable CRUD (Create, Read, Update, Delete) functionality, which was essential to allow participants to both input and read their variable data. All persistent user data was housed in a PostgreSQL database. The DBI and RPostgres packages were used to interface between the shinyMobile UI and the database (R Special Interest Group on Databases et al.(2021)R Special Interest Group on Databases (R-SIG-DB), Wickham, and Müller, R-SIG-DB; Wickham et al., 2021a).

To create and test the database locally, the command line tool psql was used (psq, 2021). A production database was initially set up on ElephantSQL, which at the time of writing provided free shared cloud hosting for a small PostgreSQL database up to 20 megabytes in size, with a limit of 5 concurrent connections for the free tier (Hörberg, 2021). Data was stored in separate tables based on its purpose, with the user ID set as the primary key for each table. For instance, one table housed all user settings, with each column containing an individual setting, while another table housed all variable data for each user. Using PostgreSQL for the backend provided the dual benefits of highly flexible database configurations coupled with rapid and scalable performance.

For user authentication, the polished package was used, providing a customized sign-in page to the app, along with the ability to configure a database for maintaining user identities and logins (Merlino et al., 2021). The polished authentication layer was used to generate all user ID strings, which were stored as the primary key for each table in the PostgreSQL database.

shinyMobile provides access to a multitude of framework7 widgets, several of which were utilised for Harden. For instance, shinyMobile::f7Slider() produces a slider bar for user input, and shinyMobile::f7Accordion() produces an ’accordion’ widget, which allows different visual elements to be segmented into collapsible elements. The shinyMobile::f7TabLayout() template was used to divide the app into three tabs - one for user input, one for graphs, and one for user settings. All of these elements are demonstrated in Figure 2.

The ggplot2 (Wickham et al., 2021b) and plotly (Sievert et al., 2021) packages were combined to generate interactive plots, firstly by creating the ggplot2 object, then passing it as an argument to plotly::ggplotly(). These plots were placed inside the accordion elements, and were made reactive, such that they loaded only when their accordion element was opened, thus reducing initial app load times. However, plotly does require loading of JavaScript libraries during creation of the first plot, which produces a slight delay for initial plot load times. Subsequent plots do not require the libraries to be re-loaded.

A dark theme is also available in shinyMobile. To match the dark theme, the ggdark package was used (Grantham, 2019), which provides dark colour schemes for ggplot2 graphs.

The shiny.pwa package was used to convert the shiny app to a PWA, allowing it to run as a standalone fullscreen app with its own icon, on both mobile and desktop (Silva, 2021). Additionally, various packages (and their dependencies) were used to articulate the logic layer of the app, including:

• •

  The dplyr, magrittr and tidyr packages, for manipulating data in a tidy fashion (Wickham et al., 2021c; Bache and Wickham, 2020; Wickham, 2021)

• •

  The lubridate and zoo packages, for manipulating date-time and time series data (Spinu et al., 2021; Zeileis et al., 2021)

• •

  The here package, for generating relative filepaths and organising the code base (Müller, 2020)

• •

  The sever package, for creating a customized error message in cases where the connection to the server was lost (Coene, 2020)

Programming was mostly performed in the RStudio integrated development environment (IDE) (RStudio Team, 2020). All project files, including code files, images and related data, were regularly uploaded to a private GitHub repository for version control and backup purposes (Github, 2021), using RStudio’s inbuilt git API (Chacon and Straub, 2014). Prototypes of the app were hosted on the shinyapps.io hosting platform (RStudio, 2021a), also provided by RStudio and automated from within the RStudio IDE.

In order to create a shiny app with full CRUD functionality, along with unique logins for each user, the server host must be able to provide an asynchronous platform for multiple users, to prevent cross-contamination of data updates between users. For this purpose, Google Cloud Run, which provides serverless hosting for containerized apps, was chosen as the host for Harden (Bisong, 2019). Cloud Run provides a number of customizable options for its servers, including RAM and CPU limits. While Cloud Run can autoscale to zero server usage at times where there are no users, it also allows developers to specify a number of ’warm’ instances running at all times. This prevents ’cold’ starts if a user requests a container at a time when there are no spare containers running. For efficient autoscaling, it is recommended to have at least one container running warm on top of any other containers that are currently being used. This reduces start-up times for users who would otherwise deal with a cold start, but increases the runtime costs for Cloud Run (Google, 2021a).

To deploy the application to Cloud Run, a Docker script was written to containerize the app and its requisite packages (Merkel, 2014). The Docker script was then uploaded to the GitHub repository containing the code base for the app, with the Cloud Run instance being configured to trigger a new version build whenever a commit was pushed to the master GitHub repository branch. This allowed for easy version handling, and the option to fall back to an older version if critical bugs were found in the current version. It also ensured that users were kept up to date with the latest version, which was automatically propagated to all users at build time. Where packages were not strictly necessary to the functioning of Harden, they were excluded from the Dockerfile, in order to maintain a lightweight code base. Package versions were also specified in each Dockerfile, meaning that different app versions were not affected by unexpected package updates. Note that it is generally recommended for the developer to use a package such as packrat or renv to manage their project dependencies on their local environment (Ushey et al., 2021; Ushey, 2021).

The database was initially hosted in a Google Compute Engine server located in Iowa in the United States, which helped to reduce latency between the Cloud Run server and the database. In a future version, the database will most likely be migrated to Google Cloud SQL (in partnership with Cloud Run), which will in theory provide further performance benefits due to lowered latency and network egress costs.

The primary disadvantage of the shinyMobile technology is the requirement for users to be connected to a shiny server. While some PWAs have limited offline capabilities, a shinyMobile app relies heavily on the server to produce live data for the reactive UI, resulting in an immediate crash if the server is disconnected. As internet coverage improves worldwide, this problem is reduced over time, but app designers will need to assess whether there will be strong demand for the app in places of limited internet connectivity.

A PWA, being a rendered web page, is unable to access most hardware functions on mobile, for security reasons. This means that certain native functions, such as scheduled notifications, are impossible to access through web applications. For the purposes of an EMA app, this is a significant disadvantage, as users need to be reminded to input their data on a daily basis at least (Shiffman et al., 2008). Two potential solutions include scheduled emails - potentially via the blastula package (Iannone and Cheng, 2020) - or housing the web app inside a WebView component in either a native Android or iOS app, and then scheduling notifications from the native app. However, these are convoluted workarounds, and a more straightforward solution would be welcomed. Depending on the importance of notifications to the app being created, it may be that developers will prefer development on native platforms to bypass this issue.

The shiny and shinyMobile packages provide a streamlined way to reduce the complexity of web development into one language. This is an enormous advantage for statistical programmers with a limited understanding of internet technologies. However, it comes at the cost of introducing data security issues, as novice app developers explore untested methods of transferring data online (Kasprzak et al., 2020).

In web security, it is vital to be aware of the concept of ’unknown unknowns’. Novice programmers are likely to make critical security errors, being ignorant of the dangers of poorly written code. In particular, statistical programmers who only have experience developing software on their local development environment are likely to be unfamiliar with modern web security needs. In other words, they are unable to fix vulnerabilities that they are not aware of (Kasprzak et al., 2020). As such, it is vitally important that all shiny developers who plan to transfer data across networks are trained in good practices, or that they recruit a data security expert to review their project.

Since RStudio’s own shiny hosting service, shinyapps.io, was not used for distributing Harden, additional security measures needed to be implemented to secure the Harden app from intruders over the network. These measures included the use of Secure Sockets Layer (SSL) certificates for encryption of packets over networks using the Hypertext Transfer Protocol Secure (HTTPS) communication protocol (El-Hajj, 2012), along with the sanitization of SQL queries for prevention of SQL injection attacks. The RStudio website provides guidance on how to create parameterized queries with the DBI::dbSendQuery() and DBI::dbBind() functions (RStudio, 2021b). While a full discussion of security issues is beyond the scope of this article, it is vital that one is aware of the risks when designing their app.

For an app to have global reach, one should expect to pay a regular subscription fee to host their app on a web service such as Google Cloud Run or Amazon Web Services. This fee scales up per user. Pricing details for Google Cloud Run are provided on their website (Google, 2021b), and include details of a free trial, which will be beneficial for initial development and testing. Pricing will be a vital consideration for app developers, who may need to consider funding for research projects, or charging a subscription fee to users. For the latter option, the polishedpayments package (Merlino, 2021) can be used to create a paywall, in combination with the polished package. However, there is also a charge for using this service. It may be necessary for the developer to consider alternative cost-saving options, including creating their own authentication database or hosting their shiny server locally, if they cannot make their business model profitable while using polished in combination with Cloud Run. It is hoped that alternative solutions with lower margin costs will be made available in the near future, as more developers explore this space.