Mobile clients for AODB (Airport Operational Database) products running on tablets and mobile phones are a standard offering today. These clients allow convenient access to operational data while being on the floor, at the tarmac etc. I remember my first mobile AODB project more than 10 years back operating on a proprietary Nokia platform. Today it is not a major technology challenge any longer with current mobile hardware, platforms and libraries available at hand.
The remaining questions are often: How to design the app for a small screen landscape available, but facing a big amount of operational data ? What features does a mobile user really need, what info is key to be displayed, what updates need to be entered while being mobile ? How to simplify user interaction ? How to handle the data synchronization when being offline, aka in areas without wireless or mobile coverage ? Build a hybrid app or go native ?
I believe we at an interim stage of mobile computing at this moment, while current mobile apps replicate desktop applications (screen, mouse, keyboard) with the means of mobile interaction (touch, swipe, pinch,..), we still sorting out the next evolutionary step. Mobile computing on mobile phones, handhelds, wearable computing, smart watches, AR glasses etc. etc. Ruggedized devices became standard while smart watches are still not taking off.
The next (or this !) generation of mobile apps should make use of the mobile characteristics and sensors built-into most mobile hardware. A few ideas: Location awareness, the app should know where the user is at the apron and already open the relevant flight and information or support manual milestone recording. Depending on the users role, tasks should be highlighted to him/her, eg. a service manager that is closest to a problem location should be notified. NFC reader, barcode scanner and AR glasses should assist the user to identify cargo, baggage, vehicles, etc.
Putting aside this considerations, I like to engage in a little thought-experiment:
Can we run an AODB, aka the server, on a mobile phone (Android) ? (without using any external core service, eg. data storage or rule engine etc. Standalone only, allowing other clients to connect, simple interfaces only)
Lets play with pro and con argument and check on the feasibility.
Hardware
This topic triggered the discussion when comparing current hardware in mobile phones with server hardware 20+ years ago when the first generation of AODB products appeared. A standard server of that time was something like a Sun Ultra II with dual 200 MHz processors, 256 to 512 MB of RAM and maybe a SCSI rack with 3x 10GB diskspace, running Solaris, 32bit. Easily priced at 20.000 to 50.000U$ depending on configuration plus various commercial licenses.
Lets look at a current mobile phone like the Huawei P20, Octa-core (4×2.4 GHz Cortex-A73 & 4×1.8 GHz Cortex-A53) with 4GB of memory and 128GB of SD card space, coming at 600U$.
Operating System
Android is obviously not a server OS, it does not give us control over settings that we can rely on under Linux. We cant assign memory and priority, it is actually the OS that controls apps and services, going to the extend of terminating unused apps and similar. The only way of having a persistent app running is as service. Apps are living in sealed sandboxes, only a rooted device would give us more control.
Solution architecture
We cant build a multi-tier solution with the classical database, business logic and frontend layers. Android enforces monolithic applications, the only way to escape this is by building services and relying on ICP (AIDL, Intents, Binder). Anonymous shared memory is only available in Android 8+.
Database and Application/Web-Server
App-server ? Easy to answer, it does not exist. Maybe simple http server is possible.
Database ? Only a few solutions at hand, either the built-in SQLite, not really a DB known for performance, or some alternatives, mostly key-pair and relational DB’s and some NoSQL DB (Comparison chart here).
Scalability
We cant scale vertical, no adding of CPU’s or memory possible. Horizontal scaling would not be easy, unless we deploy more mobile phones to outsource certain services, but implementing a load-balancer would not be possible.
Availability
In terms of network connection we are limited to 1 wireless or (!) 1 mobile connection at a time, no redundancy. Power-failure is less of a problem, we have built-in battery that could last at least 1 hour under heavy usage. Android as OS is quite stable, it can run for prolonged periods, though it is uncertain if services running permanently with load create a problem.
Integration
Integration of interfaces with other systems is a bit more challenging. Though it is no problem to consume webservices, download from ftp server or receive emails as part of interface client, we will have a hard time to provide an interface, eg. to offer a webservice. There is no ESB running on Android.
Conclusion
It is definitely possible to run a very lightweight AODB solution without lots of fancy bells and whistles on a mobile phone, ideally to act both as server and client integrated into one solution (app). All under the premise to limit our requirements to a basic set of features like managing schedule, daily operations, milestone handling, simple resource management.
The longer I review this idea the more arguments I collect against this use-case, the platform is too limited to allow scaling, does not provide real server features and will not be able to run heavy services like rule engines, ESB, etc.
Maybe feasible for small scale operations at an airport with few commercial flights a day, some GA, few users and utilizing third party services in the cloud for billing, ESB, etc.
I suggest we rather invest our thinktank energy in building a serverless AODB by using orchestrated microservices and use the mobile platform solely as client.
Image: Creative Commons, National Library of Ireland on The Commons, “St. Albert at Dublin Airport, circa 1950”
The JavaDude Weblog 