It has been around 7 months since the iCARE Community project was launched and begun being widely used in Sierra Leonne. And whilst the app itself has been functioning excellently, there has still been various issues and challenges that are still on-going. This blog post is fundamentally about these challenges and how we’ve tried to work with or overcome them to this point.

Challenge #1: Transferring data from a remote location

Let’s start with the biggest challenge… and one that is ongoing is getting usage data from the app to our server. There are three main identifiers to the cause of this:

1. The internet connection speed is not very fast. Meaning transferring lots of data gets interrupted meaning transfer has to start again from the beginning. We kind of saw this one coming early on in the development of the backend code which we intentionally made to send many separate packages instead of one big package. However, further extensive testing with the sort of amounts of data that is being transferred has lead us to believe the following two things would help alleviate this…
2. Our server could use an upgrade! The server that is receiving this data seems to be struggling with the sheer amount of events being sent in a short period of time. Beefing up the server spec would help against overload. But there is also another way…
3. The method for transferring data can be refined. As mentioned above, the current logic in sending data is in many (MANY) separate packages transferring to the server individually. Whilst this in hindsight is not the fastest way to achieve copying data across, it made sense at the time due to known intermittent internet connectivity in Sierra Leonne. However, since updating the app to offer a plan B to the administrators of the app to instead email us a CSV export of the data in one go, this has been very successful! Meaning we should actually alter the automated data transfer logic to instead attempt to send much larger packages of data to the server in one go instead of individually. This is now on the to-do list for a future update!

Challenge #2: Updating the app remotely

The other ongoing challenge is updating the app. Or providing an efficient way for those managing the iPads in Sierra Leonne to update as easily as possible.

As the app is in the research phase, we haven’t submitted the app to the App Store yet. But even if we did this, this is actually not the easiest way for the app to be updated on multiple devices. Why? Well, there are 12 iPads to be updated and by publishing to the App Store, each device would need to connect to the internet to download the app. Tests showed this will fail regularly and very rarely reach the end.

What we provided is a web page with a link to all built versions of the app, with the latest being at the top. The difference is by providing this download link, the administrators in SL only need to download a copy of the updated app once to a laptop. When they have this, they can plug in each iPad to the laptop, then install the update without the need of an internet connection. When it works, it works really well! The main subproblem to this is, the laptop!

Challenge #2.1: Laptop issues

A few times it has been reported that updates cannot be installed as the laptop has been playing up. Things like failed software updates etc are a real problem in an area with intermittent connectivity. We have one laptop that is responsible for updating the iPads with any updates and when that goes, the updates are almost impossible to install or take a lot longer than necessary.

Challenge #3: Lightning!

There was a period in the location where the staff are based for this project in SL where they had zero internet connectivity due to a lightning storm. We only received replies to emails etc. once staff were somewhere off from their main location and found a connection elsewhere. This meant they couldn’t do much with regards to managing the devices and sending data. Though the app continued to work and capture data as it was built to fully function and capture data whilst offline, so nothing was lost as such. It just created more of a bottleneck in getting it back to the server. This issue took weeks to be resolved.

So what is there to learn from all this?

• Test any data-driven apps with a lot more data than you’d expect. Stress test not just from the “home” location but from wherever you feel is important.
• Offline apps are important! We made this standard for the app to function offline so never had this issue. But I feel it important to include here in case anyone else is reading this and taking notes!
• We ended up creating and posting a DVD to any remote locations as a backup to any failed software on a PC. So any important applications can be re-installed without the need of an internet connection. Though some apps require an internet connection to register, most are fine or at least only require a connection briefly to achieve this.
• Soon after realising the difficulty in updates being downloaded, we trialed using Dropbox to automatically sync files onto a computer. We had a period where this was very efficient. The staff member would login to the computer in the morning and the app update was there ready to be installed. We started having some issues later on where the file just would not sync via Dropbox. Possibly due to some caching issue. But it’s something to explore for similar projects with similar issues.
• If data capturing is important, develop a plan B and C whilst have a plan D and E in the backlog if need be. We’re currently at plan C!
• Try not to offer too many app updates too often. If updating remotely is going to be a challenge, think carefully about grouping updates instead of pushing little and often.

What’s next?

The next part of the project for me is to develop a simple dashboard which reveals any data captured from the app in an easy to read, useful way. This will help those that are using the data for research. The dashboard is still an early prototype, but below are some screenshots of some charts showing how parts of it look right now.

Google map of some of the locations visited in Sierra Leonne where the iCARE Community app was used.

Comparison charts which show correct vs incorrect actions. Here we can see users take food hygiene seriously.

Chart which shows a breakdown of occupations. A small questionnaire is built into the app before the story begins which asks this and a few other questions.

Talking of data… to date the app has delivered over 50,000 events, which is awesome! What does this mean? Each action in the app creates an event, a log snippet of information which can be used to see how the app is being interacted with and also allows research using this data to understand many things. This data could then be separated and compared between dates, locations and key data such as users of a particular occupation. This is beyond my participation of the project, but as the developer, I’m really quite proud the app continues to work well!