In many schools here the internet is not absent so much as intermittent: there at eight in the morning, gone by ten, back some time after lunch. Software that quietly assumes a connection is a particular kind of useless in that setting, because it fails at exactly the wrong moment — a teacher standing in front of thirty children with a register to fill in. So the parts of PDP Shikshya a school touches every day were built to work with no connection at all, and to catch up on their own once there is one.
What keeps working with no connection
Three things are saved on the device the moment you save them, without waiting for the server to answer, and sent to the school's records afterwards whenever there is a line to send them on:
- Marking the attendance register — the marks and any corrections to them, for any class whose list has been opened in range at least once, so it is already on the device
- A student submitting typed homework
- Writing and keeping study notes
On these screens work is written to the device first and shown as done immediately, rather than held behind a spinner waiting for the server to answer. The register is honest about where each mark stands: a dot beside a student means saved here but not yet sent, a counter shows how many marks are still waiting to go, and it turns to Synced once the school's copy has them. A strip along the bottom says when you are offline and, where it can tell, how recently the pages held on the device were refreshed — a number with no date attached is only a guess.
What does not work offline, and we would rather say so
Not everything does, and a post claiming otherwise would be found out by the first teacher who tried it. Most of the app works the ordinary way: it asks the server a question and needs an answer. The tutor, building a worksheet or an exam paper, planning a lesson — anything leaning on our AI features needs a connection by its nature. So does uploading a photograph of handwritten homework, because the picture itself has to travel: a typed answer will wait in the queue, a photograph will not.
Alongside those three screens there is a second, narrower mechanism for writes that are better delivered late than lost: a teacher's marks and feedback on a piece of homework, a message sent in chat, the score from a finished practice round, a student's submitted task, an entry in the class diary, and a few smaller things such as marking a notification read. Made while the line is down, these are kept and delivered on the next connection. It is deliberately not applied to everything, because a write replayed an hour later can arrive after a colleague has already changed the same thing, and one delivered twice is not always harmless — so it is used where a late delivery plainly beats a lost one, rather than as a blanket. A few actions are left to fail loudly on purpose — starting a timed assignment is one, since pretending the clock had started would be worse than saying it could not.
The hard part is not saving. It is deciding which version wins.
Storing a mark on a phone is easy. The difficulty arrives when the connection does. Suppose a teacher marks a child absent at ten past ten, and a minute later the child walks in and she corrects it to present. Both changes sit on her device, unsent. When the line returns they travel together — and if they arrive in the wrong order, the correction is compared against the mark it was correcting, looks like the older of the two, and is discarded. The register is then wrong, and nobody is told.
So the waiting changes are sent in the order they were actually made, and each is compared against what the records already hold before it is applied. On those three screens, sending the same change twice — which happens whenever a connection dies halfway through — cannot produce a duplicate: every change carries its own identifier, and one the records already hold is recognised and skipped. Where a change genuinely was overtaken, because someone edited that record from another device meanwhile, the newer version stands, and on the register the page says so rather than silently swapping a number while the teacher looks elsewhere.
A phone whose clock is wrong
This case taught us the most, and it is not rare. A phone that has run flat in a bag, or been switched off and on again in a classroom, can come back with a badly wrong clock until it reaches the internet to correct itself — which, offline, is precisely what it cannot do. If we asked that device when a mark was made and believed the answer, every mark it held would look old on arrival, lose the comparison against the records, and be thrown away. A whole morning of marking, gone behind one small grey line of text.
So we do not take the device's clock at face value. Normally we trust it only alongside a freshly measured difference against the school's server. When that measurement cannot be relied on, we fall back on something changing a clock cannot touch: each change also records how long ago it was made, measured as elapsed time — a stopwatch rather than a calendar — and the server works backwards from that. Where no honest measurement of a change's age exists, the app says so rather than inventing one, since a guessed timestamp is worse than none: it is confidently wrong in whichever direction the clock moved. And an impossible timestamp is never grounds for refusing the work. It is brought back inside a believable range and recorded, because a lost register is far worse than one mark ordered imperfectly.
Signing out does not throw work away
Signing out happens more often than people choose it: a session expires, a password is changed elsewhere, an administrator ends a session. So signing out does not clear the device. Unsent work stays where it is, and only copies of things the server already holds are dropped. Nothing a teacher has typed is destroyed by an event she did not initiate.
Shared devices — a tablet passing between teachers — need care in the other direction: the next person must not see the last person's data, and must certainly not have it sent up under their name. So when a different person signs in on the same device, the previous user's unsent work is set aside where nothing will replay it, and everything else is cleared before the new session begins. Deliberate and recoverable, rather than silently sent or silently deleted.
A bad line is not a failure
One small rule has an effect out of proportion to its size: when a waiting write cannot be delivered because the network dropped mid-request, that does not count against it, and it is tried again. Only a real answer from the server counts. On a connection that drops five times an hour, work can fail to send many times over, and letting those attempts expire it would be data loss wearing the costume of tidiness.
A definite refusal is different and stops the retrying at once — a sign-in that has expired, a record that no longer exists. Even then the write is kept rather than deleted, and the app shows a count of changes that could not be sent, and points you to your school administrator. Not a happy outcome, but a visible one: work disappearing without anybody able to find out that it did is the failure this whole layer exists to prevent.
Why we spent the time on this
None of it is visible when things go well, which is rather the point. A teacher should be able to take a register at the back of a building with no signal, go and teach, and open the app again in range that afternoon to find the marks already filed, without having thought about it once. Connectivity is a fact of the environment our schools work in, not a fault to be apologised for, and we would rather build for that environment than ask a school to change it.