All Posts By

Greg Crouse

React Native Client-Side Data Storage Solutions

By MobileNo Comments

In order to develop a mobile application with maximum DIL [Disconnected, Intermittent, Low-bandwidth] functionality, local data storage is essential. Within the React Native ecosystem, there are a number of options to consider.

Simple Storage Solutions

AsyncStorage is an asynchronous, unencrypted, persistent, key-value storage system. AsyncStorage is a perfect solution if the data to be stored is simple, lightweight, and not sensitive in nature. This solution is supported in bare and managed workflows in Expo.

SecureStore is another asynchronous, persistent, key-value storage option available in React Native. SecureStore enables the storage of key-value pairs in an encrypted data store. The size limit is 2048 bytes for the value. This solution is also supported in bare and managed workflows in Expo.

Persisting simple data in key-value pairs is highly useful but it is typical that mobile applications will require the storage of more complex data structures. Because of this need, there are many options to choose from.

SQlite vs. NoSQL

SQLite is a relational database management system (RDMS). It uses tables where data is defined by columns and stored in rows. Each table has a unique name and may relate to one or more other tables in the database through common values. NoSQL databases are document-based, key-value pairs, graph databases or wide-column stores. They also do not have standard schema definitions that need to be adhered to. Additionally, NoSQL data stores are typically not relational.

SQL databases have a predefined schema. NoSQL databases have a dynamic schema for unstructured data. Therefore, migrations are necessary when schema changes are made when leveraging a SQL/SQLite database. For apps with the need to store unstructured or constantly changing data structures, a NoSQL solution is best. 

SQL/SQLite databases are a better fit for complex query intensive applications. SQLite implementations often will have an abstraction layer to allow developers to interact with the database in the native language of the project. SQLite also implements most of the Structured Query Language (SQL) standard. This allows developers to implement custom SQL queries if needed. In general, NoSQL databases don’t have standard interfaces to perform complex queries. Typically the queries themselves in NoSQL are not as powerful as SQL query language.

React Native Datastore Options

This is a list with a brief description of some of the options for client-side mobile application data storage solutions capable of handling more complex data than AsyncStorage or SecureStore.

NPM (Node.js Package Manager) is the most useful package manager for JavaScript. NPM is very commonly used by React Native developers to install critical libraries to be implemented into their mobile applications. Below is a graph generated using the NPM Trends tool. This gives a sense of how often the packages we are going to look at are downloaded by developers through NPM. It will also illustrate the current trends for data storage solutions in React Native.

React Native NPM Downloads Graph



The React Native SQLite module creates a client-side SQLite database that can be queried through a WebSQL-like API. SQLite is a small, fast, reliable, and self-contained SQL database engine. It is one of the most commonly used database engines and is leveraged by all kinds of applications on any platform and is supported in Expo managed and bare workflows. SQLite data stores can be encrypted using SQLite Encryption Extension (SEE) or plugins like SQLiteCrypt and SQLCipher. Unfortunately, it does not look like these libraries are supported in Expo managed workflows at the time of this writing (December 2019).



Realm is an object-oriented NoSQL database. As such it provides memory-efficient access to data by using Realm objects, which usually consume less RAM than native objects. Realm also has faster performance than SQLite and some other data storage solutions. The client-side datastore includes a built-in framework for seamless data syncing with Realm backend storage solutions. Custom security protocols for each of the different device platforms is also one of the strengths of Realm. As of this writing (December 2019), Realm is not supported in Expo managed workflow.



Pouchbase is a client-side datastore with a JSON-based NoSQL interface. It can be used as an abstraction layer over SQLite or by default it ships with IndexedDB adapter for the browser, and a LevelDB adapter in Node.js. The primary reason to adopt PouchDB is to leverage the built-in framework to enable data synchronization with CouchDB server-side data storage solutions. Client-side PouchDB instances can be encrypted using the Simple-Cryptor-Pouch plugin. As of this writing (December 2019), PouchDB is not supported in Expo managed workflow.



MongoDB is a document-based NoSQL database that reads and writes JavaScript objects. It includes the ability to sync to MongoDB backend datastore. The ability to encrypt the client-side data store instance is built-in. As of writing (Dec 2019) MongoDB is not supported in Expo managed workflow.



Note from developers on the react-native-couchbase-lite repo: This plugin works for Couchbase Lite 1.x only. For new projects, we recommend to use the Couchbase Lite 2.0 Native API and to write your own wrapper to access Couchbase Lite APIs from a JavaScript codebase (see

Disclaimer on the react-native-couchbase-lite repo: “This package is not an official couchbase plugin and is not supported in any way by couchbase. If you have issues with it please do not use the couchbase forums but raise an issue here instead. Although this package does work as described it may not be fully featured and may not be suitable for your requirements. This package is just a thin layer over the CBL REST API, PRs and suggestions are welcome!”

It does not appear like the developers of Couchbase are currently supporting a React Native implementation of their client-side data storage solution. The best React Native compatible client-side data storage solution with built-in server-side Couchbase syncing at the time of writing (December 2019) is PouchDB.

If you are looking for application support as it relates to building applications in disconnected, intermittent, and low bandwidth environments (DIL), contact us here. Bytelion has developed a portfolio of apps meant to sustain connectivity and support local data storage.

Increase Enterprise .NET Development Efficiency By Sharing Code With NuGet

By Development, Mobile, XamarinNo Comments

Reusing code can be a great way to increase efficiency within an organization. If there is an overlap in functionality across multiple development projects it makes sense to collaborate and reuse code across those projects.

Increase Efficiency

An essential tool for any collaborative development environment is a mechanism through which developers can create, share, and consume code. Often such code is bundled into “packages” that contain compiled code (as DLLs) along with other content needed in the projects that consume these packages. Using packages to transmit code facilitates the natural process of integrating updates that improve and add to functionality available to collaborators.

NuGet Packaging

NuGet is a free and open-source package manager designed for the Microsoft development platform. Since its introduction in 2010, NuGet has evolved into a larger ecosystem of tools and services. NuGet is distributed as a Visual Studio extension. Beginning with Visual Studio 2012 and subsequent versions, NuGet is pre-installed with Visual Studio by default. NuGet can also be used from the command line and automated with scripts. NuGet is the standard tool by which package dependencies are managed in Visual Studio projects/solutions.

A NuGet package is a single ZIP file with the .nupkg extension that contains:

  • Compiled code (DLLs)
  • Other support files related to that code
  • Descriptive manifest that can include:
    • Package ID
    • Package Version Number
    • Package Author Info
    • Package Description
    • Other Fields Included: Owner Info, Copyright, Title, Summary, Project URL, Icon URL, License URL, Tags, Release Notes

Creating A Single Cross-Platform NuGet Package For Xamarin Mobile Application Development

Visual Studio library projects can be configured to create a variety of packages with differing levels of compatibility from a single platform to multiple platforms. Most of the time creating NuGet packages with Visual Studio is simple and works well, but I encountered a few build errors while attempting to build a single multi-platform NuGet package for Xamarin mobile application projects using Visual Studio for Mac (VS for Mac). Here are a couple examples:

  • The Target “GetPackageContents GetPackageTargetPath” does not exist in the project. (MSB4057)
  • The “AssignPackagePath” has failed unexpectedly. (MSB4018)

Below is a step-by-step process for VS for Mac to create a cross-platform NuGet package that will run on iOS and Android that leverages Xamarin.Forms. Following this outlined process helps to mitigate and avoid some errors, but even this process is not error proof. It may take a few tries to produce an error-free cross-platform NuGet package with VS for Mac.

  1. Open Visual Studio and click File, and then choose New Solution.
  2. For your project template Select Multiplatform Library (as shown below).
  3. Next configure the solution. Give it a name and a brief description. Select Android and iOS under Target Platforms, then under Implementation select Single for all platforms.
  4. Make sure the project name, solution name, and path are the way you want it, then click Create
  5. To add platform-specific references the next step is to right-click on the project and under Add click Add Platform Implementation.
  6. Select Android, iOS, and Create Shared Project as shown below.
  7. When this process completes you should Build All in order to confirm that your solution is error free. Sometimes the build will fail at this point. This seems to be an expression of an error inherent in the processes executed by the VS for Mac IDE. If Build All fails it may be best to simply start over.
  8. Now is the time to make sure that the References in all the projects are correct. The main project should reference the .Shared project. The .iOS and .Android projects should have references to the main project and Xamarin.iOS or Xamarin.Android respectively. The .NuGet project should reference the main and .Shared projects.
  9. The next step is to add the Xamarin.Forms package to the .Android, .iOS, .NuGet and main projects.
  10. For proof of concept add a Xamarin Forms Page in the .Shared project with a label that says “Hello World.”
  11. Right-click on the main project and then select Options. In the Build section under General confirm that Target Framework is set to .Net Portable with a PCL profile that is compatible with the platforms to which you want to deploy your package. In our case, Profile 111 is correct.
  12. While in Project Options, under the NuGet Package click on MetaData to add or edit the data that will be associated with the package you create.
  13. Under the NuGet Package section Build tab, select “Create a NuGet Package when building the project.”
  14. Now when you Build All the single, multiplatform package will be generated and  saved in the main project’s /bin/ folder (either Debug or Release, depending on configuration). The NuGet package file will be saved with the extension .nupkg

With a little luck at the end of this process you should now have a single NuGet package that will deploy to both Android and iOS with the ability to leverage Xamarin.Forms.

NuGet Package Distribution

NuGet packages can be distributed and consumed in multiple ways. If your package is meant to be shareware it can be published and distributed for public consumption directly on If the packages are meant to be proprietary then a private repository can be created. Something as simple as a folder on a secured network will work. The NuGet Package Manager in VS can then be configured to load or update packages from whatever location your packages are stored. The location can be configured by opening the VS project you want to add the package to and then complete the following steps:

  • If Loading New Package:
    • Right click on “Packages” folder in the target Project and select Add Package
    • Select Configure Source and add local directory in which NuGet Package resides.
    • Set the Package Manager source to the folder that was added
    • Select the Package to be installed
    • Click Add Package (if it is a Shared Project Solution the package will need to be added to each each Project)
  • If Updating Package:
    • Right click on the package to be updated and click Update (updated package should be located in local directory the package was originally loaded from) (if it is a Shared Project Solution the package will need to be updated in each each Project)

The Value of NuGet

Leveraging the power of NuGet is an excellent way to package, transmit, consume, and update shared code across .NET projects. As the default package manager for Visual Studio it is familiar to developers and already integrated into the IDE’s workflow. The example package described here is one of the more complex scenarios, but generally speaking it is relatively simple to create platform specific packages. The distribution and update process are also easy to implement and manage. All of this adds up to saving time and money for your enterprise.



If you would like to do some additional reading I have listed below a partial list of resources I used to create this article.

Manually Creating NuGet Packages for Xamarin

Cross-Platform Development with the Portable Class Library

Creating a New Multiplatform Library for NuGet

Create .NET Apps Faster With Nuget

An Introduction to NuGet

NuGet Documentation

Portable Class Libraries (PCL)


iOS USB Data Transfer in a DIL Environment With Xamarin

By Development, Mobile, XamarinNo Comments

Transferring data across mobile devices can be a daunting problem when those devices are in a DIL (Disconnected, Intermittent, Low bandwidth) environment where you do not want your device to transmit signals that could be detected. For small data packages it may make sense to use QR codes to transfer data across devices that are not connected. However; this type of solution is not scalable if you have large packets of data that need to be transferred. For larger amounts of data a laptop could be used as an intermediary between two devices. With an Android device the simplest way to do this would be to program the app on the device to dump the data to be transferred in an external file located in “My Files.” The Android device could then be plugged into a laptop where the device would be seen as an external mass storage device and the data could easily be retrieved and then transferred to another Android device. Unfortunately it is not this simple with iOS.

Communicating With an iOS Application through USB

The iOS mobile operating system limits the way in which Apple mobile devices (and therefore the applications on those devices) can communicate via the physical USB/Lightning connection. The typical portal through which data is transferred via a USB connection from a computer to an iOS mobile device (and vice-versa) is through the iTunes desktop application. The iTunes application accomplishes this by connecting to the iOS device through usbmuxd. When the iTunes application is installed on a computer, a utility called usbmuxd (USB Multiplexing Daemon) is installed along with it. usbmuxd is a socket daemon that is started on Mac OSX by launchd (see /System/Library/LaunchDaemons/ It creates a listening UNIX Domain Socket at /var/run/usbmuxd. On Windows the service that hosts this program is named “Apple Mobile Device Service,” and can be seen in services.msc.

Can usbmuxd Be Leveraged By Third Party Apps?

usbmuxd is a socket daemon that listens for iOS device connections to a computer through its USB ports. When the usbmuxd detects an iOS device running in normal mode (as opposed to recovery mode) it will connect to it and then start relaying requests that it receives via /var/run/usbmuxd. This is the only way to connect directly to an iOS mobile device through a USB connection. This means if you want to create a direct line of  communication through USB between a desktop application and a mobile application, that connection must be made through usbmuxd. In order to establish this socket connection through usbmuxd some code needs to be implemented in both the desktop app and the mobile app. The sample code below was written by Carlos Rodriguez in his blog article “Communicating with your iOS app over USB (C# and/or Xamarin).”

How To Create a Connection Using usbmuxd

First the NuGet package iMobileDevice.Net needs to be added to the desktop application project. Here is some sample code using that package to listen for a usbmux “AddDevice” event:

Below, the Connect method gets a “DeviceHandle” reference using the UDID of the connected device. Once it gets that handle, it calls the “ReceiveDataFromDevice” method:

And finally, the below line sends data to the iOS device.

The iOS application would have to implement some code like the following in order to ‘listen’ for an incoming connection on port 5050 (an arbitrarily chosen number that matches the port number in the desktop app code).

Once the above code has been executed a connection that resembles something like a TCP network connection will be established between the MCC Utilities desktop app and the Communication Component inside the app on the iOS mobile device.


It is possible to create a direct connection between an iOS mobile application and a desktop application through USB by leveraging the usbmuxd socket daemon. Data can then be communicated back and forth through this connection in order to accomplish the prescribed data sync between the two applications. This connection will have been established through the usbmuxd socket daemon. This solution can be used to transfer data between iOS devices in a DIL environment with the desktop app as the intermediary.

Cross-Platform Optical Peer to Peer Data Sharing in a DIL Environment

By Development, Mobile, XamarinOne Comment

A DIL (Disconnected Intermittent Low bandwidth) environment presents many problems. Sharing data between users is a significant issue. Most applications rely on a robust and constant connection to a network in order to collect and distribute data between users. But what happens when there is no network connection and it is critical for close proximity users to exchange data? What if they need to transfer data across mobile devices with different operating systems? There are a few possible solutions that can be developed to solve this problem using libraries available in the Xamarin stack.

Standard Options for Peer to Peer Data Sharing

Many mobile devices are able to send and receive data via bluetooth. It is possible to create a connection between devices on this bandwidth and transfer data. Bluetooth can work in many situations, but if the user is in an area with high interference in this frequency range, or if security is an issue and she/he does not want their signal discovered, bluetooth is not an option. Near-Field Communication (NFC) is another technology that can be leveraged to create a connection between devices. NFC data transfer is secure due to its extremely close signal range (approximately 10cm). Unfortunately at the time of this writing it is not available as a solution on iOS devices. Apple’s Core NFC API has provided developers access only to the read functionality of the NFC chip in their devices. Another issue with NFC is that due to its low signal strength it is susceptible to interference. If bluetooth and NFC do not work for your use-case, what other options are available?


Optical Peer-to-Peer Data Transfer

Another option to consider for peer to peer data transfer is optical. Data can be encoded into QR images and those images can be displayed on a device’s screen. A second device can simply use it’s camera to read the image and then it can decode the QR image back into data. There are limitations to the amount of data that can be transmitted in a single image. When encoding numeric data (0-9), up to 7089 characters can be stored in a single image. When using a limited alphanumeric (0-9A-Z $%*+-./:) 45 character set, up to 4296 characters can be encoded in a single image. You can also use an ISO 8859-1 character set to encode up to 2953 characters in a single image. If the amount of data you are attempting to transmit is greater than the capacity of a single image, one can implement custom solutions to break up the data into multiple images. The images can be read and the data recombined on the receiving device. This would also require custom implementation. Custom solutions that are developed to handle these data issues can be leveraged in both major mobile platforms if it is developed using Xamarin.

Optical Peer-to-Peer Data Transfer has some advantages when compared to other peer-to-peer data transfer methods. It is secure because intercepting the transmission requires a clear line of site to the image. The data can also be encrypted prior to generating the encoded image, ensuring that the underlying data cannot be read without the encryption key. When using this method of data transfer, there is no chance for interference to disrupt the communication. The images can be read in daylight or dark because of the back-lit screen on mobile devices. Additionally, there are no concerns about electromagnetic interference. Another benefit to this method of data transfer is that the transmission can be communicated across different mobile platforms. The QR Code is platform agnostic, so an Android device can transfer data to an iOS device and vice versa by using the Optical Peer-to-Peer Transfer method.


Optical Peer-to-Peer Data Transfer is a novel solution for data transmission across mobile devices in a DIL environment. NFC may not be 100% reliable in all conditions, and currently peer-to-peer sharing using NFC is not an option on iOS. Bluetooth transmission may not always be an option if the use-case requires that the user not be discoverable or there are other security concerns. Directly transmitting data that is encoded into QR codes from one device’s screen  to another mobile device through the device’s onboard camera is a simple and elegant solution to peer-to-peer data sharing when other methods fall short. The Xamarin development platform is the most efficient way to create and deploy a cross-platform mobile app with this data transfer functionality.

Secure DIL Environment Login with Xamarin.Auth SDK

By Development, Mobile, XamarinNo Comments

Previously in this blog series I have defined what a DIL environment is and I have described some of the key technical problems a DIL environment imposes on a mobile application that relies on web services for data and other functionality. Now it is time to begin looking at implementing specific solutions to some of these problems. In this article I will focus on solving the problem of how to implement a secure login for an application while in a DIL environment.

DIL User Login Authentication Sequence

In a normal connected environment a user (User A) enters their name and password into the mobile application. The mobile app then sends those credentials to the backend web service for verification. If valid, the user is logged into the application and gains access to its resources. But what happens when the device is disconnected from the network? How can User A’s credentials be validated? The mobile application must be designed to support DIL login. This can be accomplished by securely storing user credentials locally whenever a new user on a device successfully logs in to the application while the device and application is connected to its web service. Now that User A has already successfully logged in to the application on a specific device in a connected environment, User A can now login to the application on that same device when it enters a DIL environment.

What if another user (User B) also wants to login to the application on the same device in a DIL environment, except User B has not previously logged in on that device when it was connected. Unfortunately User B will be unable to login, even if she/he has valid credentials. It is impractical to store all valid user credentials for the application locally on a mobile device. The only way a user can login to the application on any given device is if they have previously logged in to the application while the device is connected. This sequence is illustrated in the chart below:

Xamarin.Auth SDK

What do we need in order to implement a DIL login? The first step is to find a way to securely store verified user credentials. The Xamarin stack includes an SDK that provides a simple and secure cross-platform solution for local user credential storage and user authentication. Xamarin.Auth also includes OAuth authenticators with built in support for identity providers including Google, Microsoft, Facebook, and Twitter. Additionally, Xamarin.Auth provides support for presenting the sign-in user interface. For more information on these features check out the official Xamarin developer documentation here. The aspect of Xamarin.Auth that we are going to focus on here is the secure local storage of user credentials.

Securely Store User Credentials

To make a DIL login possible a user must first have a successful login on the device while the device is connected. After the credentials provided by the user have been authenticated by the web service the verified credential data can then be passed to an Account object derived from the Xamarin.Auth SDK. The Account object can then be saved securely using the Xamarin.Auth AccountStore class. Below is an example of how this can be implemented.

The AccountStore class maps to Keychain services in iOS and KeyStore in Android. This makes it an excellent cross-platform solution for secure storage for verified user credentials that can be used to authenticate user logins when the device enters a DIL environment. The verified credentials stored locally through the AccountStore class can be retrieved and used to verify a DIL login as shown in a simple example below:

Once the user’s credentials are verified against previously authenticated credentials, the user can be allowed access to the application’s functionality and data. If the credentials cannot be verified against the locally stored credentials the user should be denied access.


In a DIL environment secure login is an issue that needs to be addressed. When developing applications using Xamarin, the Xamarin.Auth SDK contains an effective, efficient, and secure way to store verified user credentials across mobile platforms. That locally stored credential data can then be used to authenticate users that have previously logged in on a specific device when that device is offline. This gives users the ability to login and access application features at any time, regardless of network status.

Exploring DIL Environment Limitations and Solutions with Xamarin

By Development, Mobile, XamarinNo Comments

In my last installment I described what a DIL Environment is and how it can negatively impact a mobile application that relies on web services. When developing a mobile app there are a number of scenarios you may face regarding the amount of control and DIL support you have with the backend web services you are consuming:

  • Custom Purpose-Built Backend: A custom backend that your team designs, controls, and configures to support DIL scenarios specific to your application.
  • Platform As A Service (PAAS): A backend utilizing a platform like Azure, ApiOmat, or Amazon Web Services that may offer some built-in DIL support which can be implemented and configured.
  • Virtual Blackbox Backend: A back-end that you have absolutely no control over and provides no DIL support.

In this article I will be examining the third scenario, a virtual blackbox backend. In order to maintain functionality for the mobile application in a DIL environment in blackbox backend scenario all DIL support must be implemented client-side within the mobile application itself. This is a common situation when it comes to enterprise and and third party application development.


Offline Caching Support- Preserving core application functionality when disconnected

How can a mobile application like this remain functional when it is cut-off from its web service data stream?  The only way is to cache incoming data locally on the mobile device for offline use. The complexity and amount of data consumed by the application would be factors the developer should consider when determining the type of data store and its implementation. One the most common methods would be to leverage an SQLite database within the mobile application to store the incoming data. Xamarin offers excellent support for SQLite database implementation, but there is no framework for resolving an optimal caching strategy.

When creating a local store there is also the need for custom logic to be implemented to manage the data. The storage space on the mobile device is limited. It is unlikely all of the data supplied by the webservice can be cached on the mobile device indefinitely due to the device’s local storage space limitations. Some applications may work best with a FIFO (first-in, first-out) logic applied to the data caching process. This logic could be triggered either when the local data store reaches a predetermined total size on the mobile device’s local hard drive, or the remaining space on the device’s local drive drops below a critical level. At that point old data would be purged to create space for new incoming data. In some cases it might make sense to give users the option to override that logic on specific data objects that may be critical to the user’s purpose.

There must also be custom logic implemented to save and track changes the user makes to the data as they work offline. When the device finally reconnects to the network there needs to be logic to manage the update process. Depending on the amount of data kept in the local store there is a good chance that pushing the entire contents of the local store back to the web service for update would be impractical. Custom logic within the mobile application itself must be implemented to track changes so that only new data is pushed to the web service for update. This strategy would save time and bandwidth, both of which may be critical to the user.

There is no out of the box existing Xamarin framework to support this caching. Each developer must roll their own version and think through all of the use cases.


Security Issues- What is the nature of the data being stored?

Depending on the purpose of the application, especially medical data, it is a possibility that the data being cached on the local store is sensitive or private in nature. The presence of malware on the mobile device where your application is in use is a possibility that should be considered. It may be necessary to encrypt the data being cached by your application in order to prevent malware from mining data out of your application’s local data store. Xamarin does support data encryption, but developers typically have to download 3rd party tools to build effectively.

Another issue to consider is if your application requires secure user login. Typically user authentication is handled by backend web services, so how can a user login to the application when disconnected? A custom offline login process must be created and implemented within the application. Validated login information must also be stored locally on the user’s mobile device for offline authentication process’ utilization. Storing login information locally would require an encrypted local store in order to keep users’ credentials secure.

Additionally, when working in a blackbox backend scenario there is typically no way to obtain validated login information by request from the web service. Seemingly the best (and possibly only way) for the mobile application to capture validated login information is to store usernames and passwords when a successfully validated login to the webservice occurs. This solution is limited and would only store the login information of users that successfully log in on a specific device. Authorized users who have not previously logged in on that specific device would not be able to login on that device while it is disconnected.


Battery Life- Is this a critical issue for your user?

When a device becomes disconnected from the network it begins scanning for a new connection. This scanning can consume a lot of power and drain the device’s battery very quickly. Accelerated battery consumption is potentially a big problem for end-users if they are in a situation where there is no access to electricity. Within your mobile application it may be wise to implement logic that alerts the user when the device becomes disconnected from the network and then offers options to the user for the device’s network scanning behavior. It may be possible to override the device’s default network scanning behavior in order to give the user the ability to change the time interval between scan attempts or stop the device from scanning for a new connection altogether. All of these options would help to extend the battery life of the device. The user should also be given the option to re-enable the network scan when the user is back within range of the network. While the OS of mobile phones do implement battery saving techniques, Xamarin developers don’t have existing tools built into the framework.



In this installment I have taken a look at the challenges presented in attempting to compensate for the limitations of a DIL environment when there is no support for this scenario from the web-services your mobile application consumes. There are many aspects to the problem that must be considered, and the implementations of these solutions will largely depend upon the priorities and purpose of your application. When dealing with a virtual blackbox backend there is a lot of work put upon the application development team to find and create custom solutions and implement them within the mobile application itself.

Xamarin would be a great tool for this scenario when the application being developed is required to be deployed on both Android and iOS platforms. The majority of the custom logic required to implement the DIL solutions I described would be shared in both platform iterations. Sharing that amount of code would reduce development time and allow for faster and less costly deployment across multiple platforms. A DIL environment creates many challenges, but we here at Bytelion relish the opportunity to solve problems and create custom solutions for our clients.

Stay tuned for our next installment as we explore newly created tools and techniques to support DIL using Xamarin!

What does it mean to be in a Disconnected, Intermittent, Limited bandwidth (DIL) Environment?

By Development, Mobile, Xamarin

What is a DIL Environment?

Disconnected, Intermittent, Limited bandwidth (DIL) environments can occur more often than you think. In a tunnel, elevator, or driving down a scenic country road are all places where you are likely to experience this condition. Your mobile device is either out of range or simply blocked from connecting to the nearest cellular tower or wifi network. You have now entered a DIL environment. So what does that mean for your mobile device? A loss of network and internet connectivity makes your web browser useless, but does it have to render your mobile applications useless as well? This is an important question to consider when designing and building your mobile app.

Why is it Important for Mobile Developers to Consider?

Most mobile applications are designed to utilize various web based services – and for good reason. The native resources of a mobile device are limited in both processing power and data storage capacity. It is only natural to want to connect to a web service to access superior resources remotely in order to enhance the capabilities of an application beyond what the mobile device can provide on its own. We often take for granted that there will be a fast and robust connection to the internet available to the user at any given time, but what about when it is not?

Thinking About Strategies

There are strategies that can be implemented in order to mitigate the effects of this loss in resources when entering a DIL environment. The U.S. Department of Defense has attempted to tackle this problem with a variety of techniques. Sophisticated software and hardware solutions have been devised to enable mission critical applications and resources to remain available for military personnel to utilize on their mobile devices in hostile territory where secure and reliable connections to their tactical cloud resources are non-existent. One solution calls for the implementation of forward-deployed, discoverable, virtual-machine-based tactical cloudlets that can be hosted on vehicles or other platforms which provide a limited substitute for normal network connectivity.

Military hardware solutions are impractical to implement in support of consumer applications in a normal civilian environment. But are there ways to mitigate the limitations of a DIL environment without utilizing costly and impractical hardware solutions? As a Xamarin mobile developer at Bytelion, I will explore this issue further in my next post. Stay tuned, and thanks for reading!