Selecting a Stored Data Approach for Mobile Apps

 

 

Robert C. Nickerson¹ and Francois B. Mourato-Dussault²

¹ San Francisco State University, Department of Information Systems, San Francisco, USA, RNick@sfsu.edu

² San Francisco State University, College of Business, San Francisco, USA, FMD@mail.sfsu.edu

 

---

Abstract

Stored data is a critical component of any application. The stored data component of mobile applications (apps) presents special considerations. This paper examines stored data for mobile apps. It identifies three types of mobile apps and describes the stored data characteristics of each type. It proposes decision factors for selecting a data storage approach for a mobile app and the impact of the factors on the usability of the app. The paper surveys over 70 apps in a specific domain (that of walking the Camino de Santiago in Spain) to examine their data storage characteristics. It also presents a case study of the development of one app in this domain (eCamino) and how the decision factors were applied in selecting the stored data approach for this app. The paper also discusses the implications of the research for apps in other domains. The paper concludes that in general the data storage approach selected for a mobile app depends on the characteristics of the situation in which the app will be used, but in the domain examined one particular approach (synchronized data storage) has clear benefits over other approaches.

Keywords: Mobile, App, Smartphone, Stored data, Data synchronization

---

 

1    Introduction

Stored data is a critical component (resource) of information systems [12]. Without the ability to store data, users would need to enter all required data into a system before any processing could be done or useful output could be produced. Information systems, with their reliance on data files, databases, data warehouses, and big data, could not function if they could not store data as part of the system. In a sense, stored data is the glue that holds the other components of the system together.

The stored data component of mobile applications (apps) presents special problems. Devices on which these apps operate (smartphones, tablets, etc.) typically have limited storage capacity. If the app is designed to be used only offline, then it must store all required data on the device, which limits the amount of data that can be stored. In addition, the data is not updated dynamically from external sources as conditions change, and thus, except for those cases where all data is generated on the device, it is likely to be out of date. On the other hand, if the app is designed to be used online then it can access the required data in real time from a server, in which case the data storage limitation of the device does not impact the app. The app, however, is dependent on a wireless connection with sufficient bandwidth, which is not always available. A third option discussed later, that of data synchronization, presents its own challenges.

The impact on the user of different approaches to data storage in mobile apps can be severe. With some apps (e.g., personal contact list) the user updates the stored data and keeps it on the device. In many situations (e.g., customer ratings) the data is updated by external entities, thus requiring access to a server, which, as explained above, has potential problems. Sometimes even locally stored data may need to be used to update data on a server (cloud storage) so that the user can share the data among several personal devices.

In mobile business, apps are used for a variety of purposes from front-end, customer-facing applications, such as those found in mobile commerce, to back-end systems used only by employees, such as mobile inventory management systems. The trend towards BYOD (Bring Your Own Device) [6] complicates the situation. Employees are bringing their own devices with their favorite apps to their work places (which may be remote) and expecting to use them in their jobs. All these apps, whether company-supplied or employee-provided, need stored data, but the data storage approach may vary from app to app.

As mobile device apps become increasingly ubiquitous, both for personal use and business use, the design of the stored data component becomes more important. Users and businesses will not accept apps that do not meet their data needs. Only well-designed apps that provide the right data at the right time will find favor among users and in businesses.

The purpose of this paper is to explore data storage options for mobile apps. The main question addressed in this paper is in what situations are different approaches to data storage appropriate. The answer to this question can be of value to both app developers and users. Developers need to select a data storage approach for their apps, and knowing which approach is appropriate for which situations helps developers focus on app design that is most likely to meet the users' needs. Users can use the answer to this question to select apps that use a data storage approach that fits their situation.

This paper investigates the question by examining the data storage modality for apps used in a specific domain (described later). It surveys over 70 apps used in this domain to identify the intended use of each app and the data storage approach taken by the app. The paper also presents a case study of the development of an app in this domain and the way the data storage issues are addressed in its design. The impact of the data storage approach on the usability of the app for the user is explored.

This paper is organized as follows. The next section describes types of mobile apps and the data storage characteristics of each type based partially on literature related to mobile apps data storage. Following this we propose several decision factors that are relevant for selecting a data storage approach for a mobile app. Next we describe the domain of this study. Following this we present a survey of mobile apps in this domain with an analysis of the data storage approach used by the apps in the survey. Next we examine the case of one specific app and show how the decision factors were applied in the case. We follow this with a discussion of the survey and the case. We then discuss the implications of the research for apps in other domains. Finally, we present our conclusion.

 

2    Stored Data for Mobile Apps

Mobile apps come in three varieties with respect to their stored data component:

1. Offline apps: These apps store all their data on the mobile device. The data may be initially populated when the app is installed (e.g., maps) and possibly updated by the device user, or initially populated and updated during the app's use (e.g., contact list) by the device user. These apps do not need to be online to function (except for initial installation); their full functionality is provided offline. (We recognize that the data for some of these apps may be backed up to a cloud based system, but we do not consider this a change in the nature of these apps).

2.    Online apps: These apps depend on access to a server for their stored data. Although some data may be stored on the mobile device (see hybrid apps below), the app relies on the data stored on a server for its functionality. This data can be updated on the server by uploading user entered data from the mobile device to the server. It may also be updated by external entities (e.g., system administrators, other users) directly on the server and then downloaded from the server to the mobile device. Apps used for e-commerce fall into this category. These apps must be online to function; their full functionality is only provided when online.

3.    Synchronized apps: These apps store all their data on the mobile device and thus can be used offline, but the stored data may be updated (downloaded) with data from a server when the device is periodically online. In addition the data on the server may be updated (uploaded) with data from an online device. These apps provide their full functionality when offline. An example of an app of this type is described in the case study that appears later in this paper.

(A fourth type of app is a hybrid app. These apps combine online and offline characteristics. They provide full functionality when online but limited functionality when offline. All data for hybrid apps is stored online but for some apps of this type limited data may be stored on the mobile device. An example of this later variation is Google Maps. To provide full functionality, however, this type of app must be online. Because this type of app must be online to access all stored data, we include it in the online category in this paper).

Table 1 summarizes the data storage characteristics of these types of apps.

 

Table 1: Data storage characteristics of mobile apps

 

 

Synchronized apps create a special challenge because a number of synchronization patterns can be used. [7] classifies these patterns as follows:

•    Data synchronization mechanism patterns: These patterns deal with when data is synchronized between the server and the mobile device. Two patterns are:

-    Asynchronous data synchronization: Data is synchronized while the app continues its normal functioning. The user can continue to use the app during data synchronization.

-    Synchronous data synchronization: The normal functioning of the app is blocked while data is synchronized. With this pattern the user is not able to use the app during synchronization.

•    Data storage and availability patterns: These patterns related to how much data is stored on the mobile device. Two patterns are:

-    Partial data storage: Only data from the server that is needed by the app is stored on the device.

-    Complete data storage: All data from the server is stored on the device.

•    Data transfer patterns: These patterns deal with how much data is transferred between the server and the mobile device. Three patterns in this category are:

-    Full data transfer: All the data on the server is transferred to the device and vice versa.

-    Partial data transfer based on timestamp: Only the data changed since the last synchronization is transferred from the server to the device and vice versa using a timestamp to indicate when the last synchronization took place.

-    Partial data transfer based on mathematical algorithm: Only the data changed since the last synchronization is transferred from the server to the device and vice versa using a mathematical algorithm to determine what data has changed (e.g., checksums).

Different combinations of these synchronization patterns impact the usability of an app in different ways. For example, synchronous, complete storage, full transfer can take considerable time for large amounts of data preventing the user from using the app for an extended period. On the other hand, asynchronous, partial storage, timestamp synchronization, although not impacting the user's use of the app, may result in the needed data not being available on the mobile device at the time the user needs it. The app developer must select the synchronization pattern for the app based on the intended use of the app.

Another treatment of data synchronization for mobile apps can be found in [15].

Database capabilities on servers can use common database management systems such as Oracle and DB2. On mobile devices used for offline and synchronized apps, however, the data storage software must meet special requirements. Because the memory capacity of mobile devices is limited, the data storage software must occupy a minimum of storage and must store data efficiently. In addition, the software must be designed so that it provides adequate performance with the limited processing power of mobile devices. Finally, for synchronized apps, the software must be able to synchronize the data with the server's database management system. Two examples of data storage software for mobile devices are SQLite [14] and SQL Anywhere [13]. SQLite is public domain, open source. SQL Anywhere is a product of SAP (formerly a product of Sybase until Sybase was acquired by SAP).

 

3 Decision Factors

The decision about what mobile data storage approach to employ in a mobile app needs to consider factors that directly impact the usability of the app by the user and its appropriateness for mobile business. A search of the research literature did not find reference to such factors, although some articles address other aspects of mobile device data storage (e.g., [4]). We found one industry article that provides anecdotal guidelines for selecting database software for offline and synchronized apps [3]. In addition, several websites suggest design criteria for apps that include reference to the data storage component (e.g., [8]) but do not provide decision factors.

A number of factors could be considered in selecting a stored data approach for mobile apps. In the information gathering phase of the case study presented later in this paper, four decision factors were identified largely from discussion with developers. We propose that these four factors, listed below, are central to the data storage decision as they impact the user directly. We demonstrate the application of these factors later in the case study.

•    Speed of stored data access: Access to stored data for an offline or synchronized app can be as fast as the mobile device's storage and processing technology can provide. Stored data access for online apps depends on the speed of the communications channel and the volume of data being accessed. Users may notice data access speed differences when using offline/synchronized apps compared to online apps. The speed may impact the user's ability to access the data in a timely fashion.

•    Availability of stored data: With offline and synchronized apps, stored data is always available. Stored data availability for online apps depends on the availability of an online connection. Users who have limited online connectivity will find stored data for online apps is less available than for offline/synchronized apps. The availability may impact the user's ability to access the data they need.

•    Volume of stored data: The volume of the data that can be stored in offline and synchronized apps depends on the memory capacity of the mobile device. For online apps, the volume of stored data is not limited by the mobile device and can be as much as the server can store. Users of application with very large amounts of stored data may find that offline/synchronized apps do not provide all the data available for online apps. The volume may impact the user's ability to have all the data they need available.

•    Currency of stored data: Stored data for offline and online apps is always current. Currency of stored data for synchronized apps depends on database activity since the last synchronization. Users of synchronized apps may find that some stored data is out of date until the next synchronization takes place, which is not the case for offline and online apps. The currency may impact the user's ability to have up-to-date data available.

 

Table 2 summarizes these factors.

 

Table 2: Decision factors

 

 

4    Domain of Study

To explore the stored data characteristics of mobile apps, we examined apps in a particular domain, that of walking the Camino de Santiago in Spain. The Camino de Santiago (Camino for short) is an ancient pilgrimage in Northern Spain. Although there are many routes, all end at the cathedral in Santiago de Compostela (Santiago for short) in the northwest corner of Spain where the bones of St. James are said to be buried. It can be traveled by foot, bicycle, or horseback; all who make the journey, whether for religious, spiritual, recreational, touristic, or other reasons, are called pilgrims. The most popular route, called the Camino Francés, starts in Saint-Jean-Pied-de-Port in France and ends in Santiago, 774 kilometers (481 miles) away, and typically takes about 35 days by foot. Pilgrims have made the trek to Santiago for over 1000 years with the numbers varying throughout the centuries. In recent years the journey has become very popular with over 200,000 pilgrims completing it in 2014 and 2015 [1]. The recent feature film The Way has sparked even more interest in the Camino.

The Camino is well marked and can be walked without guidance. Pilgrims, however, have often used one or more paper guidebooks to find their way. Two popular books in English are [2], [5], but there are many others in English and other languages. With the ubiquity of smartphones and tablets, however, some pilgrims are using apps to guide them (personal observation during summer 2013). In an online search, we have found over 70 apps that are designed specifically for use by pilgrims on the Camino.

This domain was selected partly because of the personal experience of one of the authors on the Camino, but also because it provides a number of challenges for app developers. Mobile phone service, although very good in Spain, is not ubiquitous on the Camino. Many pilgrims, especially those from the United States, do not want to use mobile phone service in Spain because of the high cost of roaming. A useful feature for Camino apps is maps, which require high bandwidth to download and significant storage space on mobile devices. Two surveys of pilgrims [9], [10] showed that offline apps are preferred by pilgrims, but then data cannot be updated in real time on the mobile device as conditions change on the Camino. App developers need to consider the decision factors discussed previously in selecting the storage method for their apps in this domain.

 

5    Survey of Data Storage Approaches Used by Apps in Domain

Through searches of the Apple App Store, Google Play, Microsoft Windows Phone App Store, and the Internet in general, we identified 71 apps that are designed specifically for use by pilgrims walking the Camino. We excluded apps that, while perhaps useful when walking the Camino, are not specifically for the Camino, such as Google Maps. Although these apps are part of the ecosystem of apps used by pilgrims on the Camino [9], [10], we chose to focus exclusively on Camino-specific apps in this study. We also excluded browser-based systems because we wanted to compare only device-resident apps of the three types identified previously in this paper.

Of the 71 Camino-specific apps that we found 21 (30%) were iOS based, 45 (63%) were Android based, and 5 (7%) were Windows Phone based. We did not consider apps for Blackberry, Firefox OS, or other lesser-used operating systems. Appendixes A, B, and C list the apps that we examined along with each app's type. We note that some apps had versions for different operating systems.

We found six apps that had similar, but not necessarily identical, versions for different operating systems. We counted these apps for different operating systems separately, arguing that pilgrims would associate an app with their device, which could be either iOS, Android, or Windows Phone based, and thus think of a similar app on another device as a different app. We also note that some apps had versions for different languages. If language selection was included in the app, then we counted it as a single app. If, however, the user had to install a different app for a different language, then we counted the versions separately. We also note that some developers have several apps for different routes. (There are over 20 named routes of the Camino de Santiago). We counted apps for different routes from a single developer separately.

We prepared an extensive spreadsheet of the characteristics and features of the apps, including their stored data characteristics. The preparation of this spreadsheet is part of an ongoing research project dealing with Camino apps. This research includes two surveys of over 600 users of Camino apps from the United States and Europe. These surveys dealt with pilgrims' use of apps and their preferences for certain features. Some of the results of these surveys were reported previously in symposium presentations [9], [10]. In addition, one paper dealing with diffusion of innovations has resulted from analysis of some of this data [11]. Neither the presentations nor the paper, however, deal with the data storage characteristics of the apps.

We identified 5 (7%) of the apps as offline, 56 (79%) of the apps as online, and 10 (14%) of the apps as synchronized. To illustrate the three different types of apps, we briefly describe one app of each type here:

•    Albergues 2.0, offline app: This app provides information about albergues (hostel-type accommodations) on a number of Camino routes. The full database of information about the albergues is stored on the mobile device allowing the app to be used completely offline. No updating of the data is available from a server. The entire app must be reinstalled with new data when a new version is introduced.

•    Camino de Santiago - Camino Francés, online app: This app provides detailed route maps of each stage of the Camino Francés. The maps are stored on a server and downloaded as requested by the user. This app can only be used while connected to the Internet; it is fully online.

•    Esoteric Camino France & Spain, synchronized app: This app provides information about unusual points of interest on the Camino Francés and some other routes. The information is written by a travel writer who has walked part or all of several routes of the Camino. The writer updates the information on a server, which is then downloaded to the user's mobile device the next time the user is online. Users can also provide comments about the writer's information, which are uploaded to a server and made available to other users. The app can be used offline for accessing information on all the points of interest downloaded at the latest synchronization.

We identified nine features for each app: route maps, route topography, town maps, information about albergues, information about other accommodations, information about restaurants/cafes/bars, historical/cultural information, points/places of interest, and location based (GPS or Global Positioning System) capabilities. These features were selected both from personal experience walking the Camino and from the surveys of pilgrims identified previously in which the respondents ranked desirable features of an app [9], [10]. One author coded each app for these features from information provided online about the app and, when a free version of the app was available, from use of the app. The other author checked the coding.

We counted the total number of features for each app, arguing that this number is one measure of the desirability of an app from the pilgrim's perspective. Pilgrims are quite concerned about carrying too much weight in their backpacks, and guide books can be heavy. The more features that can be included in an app, the fewer other references the pilgrim will have to carry. While a pilgrim could have multiple apps with different features, navigating among them while walking a sometimes primitive trail can be problematic. The ability, for example, to click on a location and find all the information related to it in a single app is desirable.

The appendixes lists the number of features for each app. Table 3 shows the range of number of features and average number of features for the three types of apps. Offline apps offered the fewest number of features, both in terms of range and average. Synchronized apps provided more features and the greatest average number of features per app. Online apps ranged from the least to the most number of features, with average number of features near that of synchronize apps.

 

Table 3: Number of features in apps

 

None of the offline apps provided route topography or information about restaurants/cafes/bars. The most common feature provided by these apps was information about albergues. None of the synchronized apps provided route topography. All the other features were available in at least half of these apps. Maps (route and town with GPS positioning) were the most common feature of online apps. Route topography and information about restaurants/cafes/bars were the least common features of these apps.

As noted previously we counted similar apps on devices with different operating systems as different apps. If we only consider the six apps with similar versions for different operating systems once in our analysis, then the results are similar. See Table 4. The range of features was the same. The average number of features decreased slightly for each type of app.

 

Table 4: Number of features in apps counting similar apps only once

 

We can see from this analysis that synchronized apps have the most features on the average but may not have the maximum number of features, a distinction that goes to certain online apps. Offline apps fall behind synchronized apps and online apps in terms of average and maximum number of features. This conclusion coincides with our intuition because online and synchronized apps have access to more current data, and thus can provide more features for the user.

 

6 A Case Study of Stored Data in the Development of a Mobile App: The Case of eCamino

In this section we examine one particular app, eCamino, focusing on the decisions made during its development. We selected this app because one author had direct contact with the app developers and was invited to meet with them at their office in Budapest. We used the case study methodology of [16], [17] as a guide for gathering information about the development of this app. Our approach is a single case study that is descriptive and explanatory. It is bounded by the activity of developing eCamino, and by the time from the initial conception to the first release of the product. Since we are interested in the development of eCamino, our discussion is based on the first version. Newer versions have been released that have additional features.

We conducted interviews at the office of eCamino Kft., the company that developed and owns eCamino, in Budapest, Hungary, in February 2015. Present at all interviews were two principals involved in eCamino, identified here as A and B. At one time several technical staff were brought into the meeting room to answer technical questions. Interviews were conducted in English, although some of the discussion with the technical staff had to be translated to and from Hungarian, which was done by B.

eCamino is a synchronized app. It includes 7 of the 9 features identified previously, excluding only route topography and town maps (added in a later version). It is based on [2]. The full database of user-relevant information with maps and content from [2] is stored on the mobile device allowing the app to be used offline. The database is also stored on a server. Users can update data on the mobile device (e.g., update an accommodation's phone number or a restaurant's opening hours) while walking the Camino. When the mobile device is next online the data in the mobile database is synchronized with the server database. User-entered data is uploaded to the server and is subsequently downloaded to the mobile devices of other users. Users can also upload text and photos to the server, which are then available for others to view on other devices such as laptops through a web portal connected to the server.

In 2012, A published an edition of [2] in Hungarian. A has technical knowledge of maps and GIS from his experience working for the GPS company TomTom. He conceived the idea of a mobile app with maps of the Camino route as shown in [2] and other content from [2]. He presented the idea of an app based on [2] to the author, John Brierley, who agreed to it in 2013. A formed eCamino Kft. in Hungary in 2013. Initial financing for the company was provided by the principals, friends of the principals, and Pear Williams Kft., which is another Hungarian company in the technology sector founded in 2011. The offices of eCamino Kft. are located in the offices of Pear Williams Kft. in Budapest. In 2014 a VC belonging to a Catholic order provided additional funding.

Both A and B had walked the Camino and used their experience to help determine the requirements for eCamino. They also interviewed a number of other individuals who had walked the Camino for their views of the desirable features for the app. With the requirements identified, they began the development of the initial version of the app. Development took about six months. The first version, which was for Windows Phone, was released in February 2014. The iOS version was released in March 2014, and the Android version was released shortly thereafter. The first version was developed for Windows Phone because Microsoft had indicated that it would provide support for the project. In addition, Windows Phone based smartphones are common in Hungary.

The core database was created using Oracle on a Microsoft Azure server in Ireland. It was necessary for the server to be in Europe because of end-user license requirements. Azure was selected over AWS and other options because Microsoft provided technical support.

Most decisions were made jointly by A and B. A fundamental decision was that the app would use synchronized data storage. All user-relevant data would be stored on the mobile device so that the app could be used offline. At the same time, the data stored on the device needed to be current. (The survey of pilgrims identified previously supports the desirability of these characteristics [9], [10]). To provide offline use and maintain currency of the data, a synchronized approach was needed. (This decision is discussed further in the next section).

Another early decision was that the apps should be native, with one version for each platform, rather than a single web app usable on all platforms. Developing native apps for three different platforms created a number of problems. Programming was done in different programming languages by programmers working for Pear Williams Kft. and eCamino Kft. Some initial programming was also outsourced to a local firm. Currently all programming is done in house. The core of the system on the Azure server was written in Java. The web portal was written in PHP. The Windows Phone version of the app was written in C#, the iOS version was written in Objective C, and the Android version was written in Java. No cross development solutions were available at the time, and so each version had to be written from scratch. Currently, such solutions exist. A and B estimate that using them would have saved about 30% of the development time. A further complication was that there were differences among smartphones in Europe and the United States because of different network providers. One activity that took considerable time was the geocoding of the points of interest. This was done manually and took one person about four months to complete.

As noted previously, the core of the system on the Azure server uses Oracle for its database. SQLite was selected as the data storage software on the mobile devices because it is popular and usable on all platforms. The complete SQLite database is approximately 160 megabytes. The web portal uses MySQL.

The architecture of the system is shown in Figure 1.

 

 

Figure 1: eCamino system architecture

 

 

Data synchronization between mobile devices and the server uses the following patterns [7]:

•    Data synchronization mechanism pattern: Synchronous data synchronization. Synchronization, if needed, occurs at startup of the app. The user interface and all app functions are blocked during synchronization. Informal use of the app on an iOS device indicates that this synchronization is typically under one minute. (Initial population of the mobile database occurs when the app is installed).

•    Data storage and availability pattern: Complete data storage. All data that is relevant to the user walking the Camino is stored on the mobile device. Some data, such as photographs uploaded by pilgrims, remains on the server and can be accessed by non-pilgrims from the server.

•    Data transfer pattern: Partial data transfer based on timestamp. Only data changed since the last synchronization, as indicated by timestamps, is transferred between the server and the mobile client.

 

7 Application of Decision Factors in Case

Discussions during the information gathering phase of the case study provided a basis for identifying the four decision factors proposed in Section 3. As noted in the previous section, a fundamental decision in the development of eCamino was to use a synchronized data storage approach. This decision illustrates the application of the decision factors using the criteria shown in Table 2:

•    Speed of stored data access: The developers wanted rapid access to the data because they felt users would not want to wait for the type of information provided by the app. All user-relevant data needed to be stored on the mobile device, thus providing access to the data without a network delay. In order to provide rapid access, the app had to be offline or synchronized.

•    Availability of stored data: The developers wanted the data to be available at all times, even when the user was offline. All user-relevant data needed to be stored on the mobile device so it would be available to the user, whether or not a network connection was present. Either an offline or synchronized app was needed to satisfy this requirement.

•    Volume of stored data: The developers determined that the amount of data used by the app was small enough to fit on a mobile device. Although data capacity is limited on a mobile device, this limitation does not impact eCamino because the database is only about 160 megabytes. Although an online app would easily satisfy this requirement, an offline or synchronized app would suffice.

•    Currency of stored data: The developers determined that changes in the data would be limited and infrequent, and thus real-time currency was not needed, although periodic updating would be desirable. Some data on the mobile device could be temporarily out of date without significantly affecting the usability of the app. Data could be updated regularly because of the widespread availability of WiFi in albergues, restaurants, bars, and similar locations on the Camino. It was expected that users would be able to go online at least once a day via WiFi. Although an online app would provide the most current data, a synchronized app would provide stored data that was sufficiently current for the use of the app in the domain.

Table 5 summarizes the application of the decision factors in the case.

 

Table 5: Application of decision factors in development of eCamino

 

The totality of the application of these decision factors indicated that the synchronized approach was best for eCamino. With this approach, data can be accessed rapidly because it is stored on the mobile device. Data is available without a network connection, again because it is stored on the mobile device. The volume of data is small enough to be easily stored on the mobile device. The occasional lack of currency of some of the data is not a problem because the data can be synchronized regularly.

 

8 Discussion

Two separate surveys of over 600 pilgrims in the United States and Europe [9], [10], found that the most desirable feature of an app was accuracy/currency of information. Not far behind in desirability was the ability to use the app offline (fifth in the U.S. survey and second in the European survey out of 19 features surveyed). Although accuracy/currency of information suggests that an online app would be the most desirable, use of online apps on the Camino can be problematic because of the potential lack of an online connection. The offline capability of synchronized apps, while at the same time maintaining relatively current information, leads us to the conclusion that this type of app is the most desirable for the domain under study. It is important to note that this conclusion is only applicable to the use of apps by pilgrims walking the Camino; different conclusions may be reached in other domains.

The benefits of a synchronized app in the domain of walking the Camino de Santiago are clear from the previous analysis. With synchronized apps, data stored on the mobile devices carried by pilgrims is always available and rapidly accessible. Access to data for an online app may be slow because of communications limitations, or, more significantly, not available because of the lack of an online connection. Although online apps are best for large volumes of stored data, synchronized apps are sufficient assuming the volume of data is within the limits of the mobile device. Apps that download highly detailed maps may not meet this requirement. Finally, data for online apps is always up to date, but the currency of data for synchronized apps is sufficient for the needs of pilgrims on the Camino.

Despite the advantage of synchronized apps in most situations for pilgrims on the Camino, we found few in our survey of apps. Only 10 (14%) were synchronized while 56 (79%) were online. Without further analysis we cannot answer why this is the case but several explanations come to mind. One is that the volume of data is too great to be stored on the mobile device. This might be the situation with apps that display detailed maps, which may require significant storage space, although the maps displayed on eCamino are stored on the device and are sufficiently detailed for navigating the Camino de Santiago (based on the experience of one author). Another possible explanation for this is that online apps are easier to develop. Data synchronization is a complex process with many options, as discussed previously. Developers of apps may not want to tackle the intricacies of synchronized apps and instead stick with the relative ease of developing online apps.

 

9    Implications for Apps in Other Domains

The analysis presented in this paper, although specific to a particular domain, has implications for apps in other domains. The decision factors that we propose can be used to determine the preferred data storage approach for apps in different domains with Table 2 serving as a guide. Although other decision factors may be relevant for apps in other domains, the four decision factors given previously can serve as a starting point for further analysis. Other decision factors may be identified by case study analysis similar to ours.

The apps survey method that we used to analyze the stored data approach across many apps in the Camino de Santiago domain can be used for similar analysis of apps in other domains. Identifying features or other characteristics of different apps in a domain and correlating this data with the data storage approach may yield insights into the desirability of different data storage approaches in other domains.

While we identify the synchronized approach as having certain benefits over online and offline approaches for apps used by pilgrims on the Camino de Santiago, the online or offline approaches may be more beneficial in other domains. The methods that we used in this paper can be used in other domains to help determine the desirability of different data storage approaches. This analysis could reach the conclusion that one data storage approach is best or that no approach is preferred over the others, which would be a useful insight.

 

10    Conclusion

This paper examines data storage options for mobile apps. It identifies the mobile data characteristics of the main types of apps with special attention to synchronized apps. It also presents factors to consider in decisions related to selecting the data storage approach used in mobile apps. With this background the paper surveys the data storage characteristics of over 70 apps for one domain (that of walking the Camino de Santiago) and examines the case of the development of one specific app in this domain (eCamino).

The general conclusion in this paper is that different approaches to data storage for mobile apps are appropriate depending on the characteristics of the situation in which the app will be used. Offline apps, with all data stored on the mobile device, are best when the data does not need to be updated or is only updated by the user. Online apps, where the app has real time access to the data on a server, are best when the data is updated by external entities and the currency of the data is critical. Finally, synchronized apps are useful when the mobile device must be used offline but may be periodically online for data synchronization.

More specifically we conclude from the analysis in this paper that, in the context of the domain of walking the Camino de Santiago, synchronized apps show an overall benefit over offline and online apps. Data for synchronized apps is always available and rapidly accessible. There is adequate storage on mobile devices for synchronized data used by most Camino-specific apps. The stored data for synchronized apps is sufficiently up to date for use by pilgrims on the Camino. Whether this or a different conclusion can be reached for apps in other domains is unknown, but it is an interesting question for further research.

This paper also demonstrates the applicability of four decision factors for selecting a data storage approach for mobile apps in the design of one particular app. These factors, which resulted from discussions in the case study investigation, can be used by app developers and app users in any domain. App developers need to decide which data storage approach is best for the apps they are developing. By applying these factors developers can make this determination. We saw an application of these decision factors in the case study. App users can use these factors to decide which app may be best for their use. For example, if a data intensive app is going to be used predominantly in an urban environment with good cellular service, then the user might wish to look for an online app. If the user requirements are different, then perhaps a different type of app would be indicated. Validation of this approach for selecting apps by users, possibly through a user survey of app selection, might be a fruitful area for future research.

We hypothesize that the conclusions of this research, although supported here in the context of apps used by pilgrims on the Camino de Santiago, are applicable in other contexts. Exploration of this hypothesis is an area for future research. Another area for future research would be to look at other case studies beyond the single case (eCamino) investigated for this paper. Such research may identify other decision factors besides those proposed here. Finally, exploring the impact on the user of the different data storage approaches identified here could be a fruitful area for future research. Although this paper has characterized this impact in several ways, research on actual use by end-users could confirm these characterizations or reach different conclusions.

 

Acknowledgments

The authors would like to thank the principals and staff at eCamino Kft. for their assistance in preparing the case study presented in this paper. The authors would also like to thank the many unnamed pilgrims who provided insights into their use of apps on the Camino de Santiago.

 

References

[1]    American Pilgrims. (2016) Compostelas issued by the oficina de acogida de peregrinos by year. American Pilgrims. [Online]. Available: http://www.americanpilgrims.org/assets/media/statistics/compostelas by year 86-15.pdf.

[2]    J. Brierley, A Pilgrims Guide to the Camino de Santiago, Forres. Scotland: Camino Guide, 2014.

[3]    W. Carter. (2015, February) How to choose a database for your mobile apps. InfoWorld. [Online]. Available: http://www.infoworld.com/article/2887754/mobile-technology/how-to- choose-a-database-for-your-mobile-apps.html.

[4]    D. Chan and J. F. Roddick, Summarisation for mobile databases, Journal of Research and Practice in Information Technology, vol. 37, no. 3, pp. 267-284, 2005

[5]    Confraternity of Saint James, Pilgrim Guides to Spain, 1 Camino Francés. Gosport, U.K.: Confraternity of Saint James, 2013.

[6]    B. J. G. Harris, B. Ives and I. Junglas. (2011, November) The genie is out of the bottle: Managing the infiltration of consumer IT into the workforce. Accenture Institute for High Performance. [Online]. Available: file:///C:/Documents%20and%20Settings/Jtaer/Mis%20documentos/Downloads/accenture managing the infiltration of consumer it into the workforce%20(1).pdf

[7]    Z. McCormick and D. C. Schmidt, Data synchronization patterns in mobile application design, in Proceedings of the Pattern Languages Program (PLoP) 2012 Conference, 2012.

[8]    Microsoft. (2009) Chapter 24:    Designing    mobile    applications.    Microsoft.    [Online]. Available: https://msdn.microsoft.com/en-us/library/ee658108.aspx

[9]    R. Nickerson, Mobile technology and smartphone apps on the camino de Santiago: What would Charlemagne, El Cid, and St. James use?, presented at the 2014 Symposium on Pilgrimage Studies, Williamsburg, Virginia, September 26-27, 2014.

[10]    R. Nickerson, Mobile technology and smartphone apps on the camino de Santiago: The view from beyond the U.S., presented at the 2015 Symposium on Pilgrimage Studies, Williamsburg, Virginia, October 16-18, 2015.

[11]    R. C. Nickerson, M. Austreich and J. Eng, Mobile technology and smartphone apps: A Diffusion of innovations analysis, in Proceedings of the Twentieth Americas Conference on Information Systems, Savannah, Georgia, 2014, pp. 183-194.

[12]    J. A. O'Brien and J. M. Marakas, Management Information Systems, 10th ed. New York, NY: McGraw Hill Irwin, 2011.

[13]    SAP. (2016) Develop custom mobile and IoT applications - with SAP SQL Anywhere.SAP SQL Anywhere. [Online]. Available: http://go.sap.com/product/data-mgmt/sql-anywhere.html.

[14]    SQLite. (2016) About SQLite. SQLite. [Online]. Available http://sqlite.com/about.html.

[15]    A. Stage. (2005) Synchronization and replication in the context of mobile applications. Mayr. [Online]. Available: http://www14.in.tum.de/konferenzen/Jass05/courses/6/Papers/11.pdf.

[16]    R. K. Yin. (January, 2004) Case study methods, 2004. Cosmoscorp. [Online]. Available http://www.cosmoscorp.com/docs/aeradraft.pdf

[17]    R. Yin, Case Study Research. Thousand Oaks, CA: Sage, 2014.

 

Appendix A: iOS Apps Surveyed

 

 

Appendix B: Android Apps Surveyed

 

Appendix C: Windows Phone Apps Surveyed

---

Received 5 January 2016; received in revised form 1 May 2016; accepted 1 June 2016