d3mastermind
Work / ChroniclesClose

These tablets left the factory with the apps already installed. If something broke later, getting to the device wasn't exactly easy.

Client
Chronicles Software Development Company
Country
Nigeria
Products
IGCSE MasterPrep · Success Reader · Common Entrance · Checkpoint Primary · Checkpoint Secondary
Role
Flutter, offline architecture, content pipeline
Platforms
Android tablets · Windows desktop
Status
Not public — preinstalled on the tablets
Evidence · tablet 4:3 · desktop · muted, captioned
Chronicles tablet app poster frame
Chronicles · Windows desktop 16:10
Recording loads behind a static poster · no autoplay · captions onFallback: cropped stills, same frames
Swipe · posters static, captions on

The constraint

These were educational tablets for students.

The apps were preinstalled by the manufacturer before the tablets were boxed and shipped.

They also had to work offline.

Not "the internet might be slow" offline.

Actually offline.

The only time a device needed a connection was during activation. After that, it might never connect to the internet again.

That meant the app couldn't depend on an API, a cloud database or downloading something when a student needed it.

The books, media, app logic and everything else the student needed had to already be on the device.

And because updates were manual, I couldn't assume I'd be able to push a quick fix whenever something went wrong.

The content pipeline

The source material came as ePub files from the client.

I couldn't just put them inside a generic ePub reader because the app needed to understand the structure of the books.

I had to extract things like titles, subtitles, chapters, links and other content and turn them into data the app could navigate and index.

Some of the books also contained video.

The video itself didn't need to work offline, but I didn't want students to leave the reading experience just to watch it.

So videos played inside the app rather than opening a browser, YouTube or another player.

The same idea applied to the other media in the books.

Audio, PDFs and other assets were handled as part of the reading experience, with the content stored locally and decrypted when it was needed.

The browser

The tablets were going to children, and they weren't going to have someone sitting beside them monitoring what they did on the device.

So the suite included its own browser with restrictions on what students could access.

A lot of the work here was testing.

I spent time trying to get around the restrictions myself — opening different types of sites, following redirects and trying the obvious things a teenager would try.

Whenever I found a way through, I closed it.

It wasn't particularly glamorous work, but it mattered more than making the browser look good.

The timeline

I joined the project fairly late.

The manufacturer had already finished its part and was waiting for the software, so there was a fixed hardware production schedule on the other side.

There were also several apps to finish.

The target was roughly two months for the whole suite.

That meant I had to make decisions quickly without creating a codebase that would become difficult to change later.

The database I changed halfway through

I initially built the local storage around Hive.

For the Android tablets, it made sense. Everything was local, it was fast, and I didn't need anything complicated.

Then I found out the suite also needed to run on Windows desktop.

Hive wasn't going to work for that setup, so I moved the storage layer to SQLite.

Fortunately, the architecture made the change fairly contained.

The rest of the app didn't know which database was underneath it. The data sources followed interfaces, so I could replace the implementations without rewriting the rest of the application.

It was still extra work I wouldn't have had to do if I'd known about the Windows requirement from the start.

But it was also a good example of why I keep infrastructure behind interfaces.

Where it is now

The apps were delivered as part of the tablet software and are used as preinstalled educational software.

Fillthe number of devices, number of titles, or production date
Why this project is here

Most mobile apps assume you have a few things available when you need them:

An internet connection.

An app store.

And the ability to release another version when you find a problem.

This project didn't really have any of those.

The software had to work on the device in front of the student, even if that device never connected to the internet again.

That changed the way I approached the architecture, content, storage and testing.