With NavyBMR study guides, sailors accomplish the following:
NavyBMR delivers a wide range of operational training in multiple learning formats including online and in printed format. Study guides are constantly updated based on updated doctrine for almost 80 rates (Navy jobs).
Lacking a mobile app, and recognizing the rapid paradigm shift of people using mobile phones instead of desktops and laptops, NavyBMR partnered with Array Digital to design, build, launch, and provide continual support for a mobile app.
Mobile apps consist of much more than the code that is deployed to the phone or tablet. Data, in the form of study material (questions and answers) is needed. We could not deploy the study material with the app because once downloaded, updates would be problematic or unavailable. We could not depend on a user to install an updated version of the app in order to get recent study material. Instead the mobile application must receive current study material as it changed. Thus a separation between the app code and the data was required, as was a way to feed data to the app.
Although NavyBMR has created and provides significant amounts of study material, it was not readily available or in a digital format readily usable by a mobile application. Thus one of the first parts we designed was an administrative application for the importing, adding, editing, and removal of study material. The database and user interface were designed to minimize data entry and no piece of data was ever entered into more than one location.
Since the NavyBMR admin application was web based, admin staff could utilize a full sized keyboard and desktops to quickly import and manage tens of thousands of questions and answers.
Like all web applications we create, the application is mobile responsive allowing staff to manage their data using their phone or tables even when they are on the go. And since it’s a web application it’s accessible from any location globally. Security restrictions controlled by the administrator allow staff to be added or removed on an as-needed basis with the correct permissions.
In order for the most up to date data to be provided to the mobile app, the data that is managed by the Administrative Web Application must be provided to the mobile app via an application programming interface (API). An API is a way for one program to communicate to another program in a format that is highly efficient. Data is not duplicated between systems - rather it’s shared by one application and provided to the other. However there remains one source of “ground truth” - the web application - and the API is simply the delivery mechanism.
A structured layer between the data and mobile app - the API provides a secure means for the mobile app to quickly get up to data data. The API was created as a separate application from the Administrative Web Application so that each could be updated and deployed separate from one another. That provides flexibility so that if a change is required in one we don’t have to deploy one large monolithic application containing both. This concept is known in the industry as microservices and provides our clients with a competitive advantage as compared to their competitors with legacy systems that are harder and slower to maintain.
With the Administrative Web Application and the APIs in place, all of the data was available for use by the mobile applications. From the beginning we wanted to cater to the platforms most used by mobile users - iOS and Android.
There are many ways to create a mobile application. Older techniques require one set of code (aka a code base) to be used for iOS, and another completely separate set of code to be used for Android. iOS and Android use two different languages and different programs are used to create apps for each platform, so it’s literally twice the work. We avoid that inefficiency by using a hybrid technique which allows us to create it one time, with one code base, and then deploy it to both iOS and Android devices. The apps - one targeted for iOS the other for Android - look and feel exactly as the two systems specify in their user guidelines. So they look different from each other, but exactly as expected for the platform.
Once the initial app was created we tested it internally by deploying the apps directly to our dedicated test devices. Later the apps were deployed to private instances of the Apple and Google Play App Stores so that we could confirm the full user experience, in a private setting, and allow for the client and selected beta testers to confirm the application was working as required and desired.