An introduction to the eVitabu project
An introduction to the eVitabu project, an app I co-developed for charity African Pastors Fellowship.
Some of you may know I've been working with African Pastors Fellowship (APF) for over a year on their eVitabu project. eVitabu is a training tool for pastors working in rural Africa that provides easy access to all sorts of resources, be that text, audio or video based. The tool takes the form of an Android app that's simple to use, although I did train all the pilot users at the March 2018 launch conference.
Previously APF distributed all their material in hard-copy form. This was expensive to produce (printing costs, shipping, distribution & storage) and I know they've got lots of unused resources in a container somewhere. The paper distribution method just didn't make sense for the digital era. Given 4G Internet coverage in Africa is very widespread it makes more sense to distribute resources electronically and this was the vision of Dave and Geoff of APF. I've known both these gentleman for a number of years so they approached me and co-developer Mike to get the job done.
This is the first of a number of posts about the project.
Early designs
Initially the plan was to create an app, preinstall it on the tablets and load it up with all the content available. We started looking at building a custom image for the tablets using the CyanogenMod wiki as a source of much needed information. Sadly CyanogenMod then disappeared, along with its wiki.
This was fortunate in one regard as, in hindsight, the original plan wasn't really a good one. Content on the device wouldn't get updated (so the same problem as paper) unless the tablets went back to a central location for updates. Given the size of Africa, and costs of transport, this would have been a huge problem. Following our forced rethink we came up with a significantly better plan, and one better able to help APF fulfill their vision: we moved to having two eVitabus. (No reason that can't be pluralised, just pronounce "boos" not "bus".)
The two halves
Of course there aren't really two products, just two pieces of the same thing. There's a management web application (EVM) written in PHP and the Android app itself using Java and the Android SDK. Fortunately this made for a sensible split, me being a PHP developer and my colleague working with Java. I'd written an Android app for my Masters degree so I was able to help with the app a bit too.
APF staff use EVM to upload content, review user access and run reports. The Android app connects to EVM, downloads details of what's available and presents it to the end user. They dovetail quite well and we've designed the system so new features can be added that shouldn't break old app installs if people don't update.
Hosting
It wouldn't be giving away any secrets to say the project is hosted on DigitalOcean and they were kind enough to sponsor the project. I've used them for a few years now, so after looking at the feature set and doing a cost to feature comparison it made sense to use a platform Mike and I knew already. We did consider other options but in the end, and by the time the project sponsorship was considered, they clearly won the business. The biggest cost was going to be the storage.
A key consideration was the size of the resources, something we just didn't know initially. To be fair, we still don't as there's always more to add. As I write this I'm conscious there's several gigs of content on my desk waiting to be uploaded. Fortunately we can add block storage to the virtual machine at any point, at additional cost, and that's incredibly handy.
Eventually I want to look at changing the way eVitabu works to take advantage of object storage (something like DigitalOcean Spaces) as the costs for using it, compared to block storage stored with the VM, is significantly cheaper. I only found out about object storage very late in the development process and it simply wasn't feasible to redesign EVM and the app so near to deadline. At some point I'll do more research into that, there's plenty on the to-do list in the meantime!
Additional thanks
I couldn't have done this on my own, certainly not in the timeframe. I'd like to take a moment to thank my co-developer Mike and my sometimes eVitabu co-developer, but long time coding partner, Adam Campbell-Smith.
Hopefully you've found this brief introduction to eVitabu interesting. I'll write a bit more about the project in the coming weeks, keep an eye on the eVitabu tag.