}

zenonet

Creating a fast timetable app for my highschool

My highschool has it's own timetable webapp. Unfortunately, ... it's awful. First of all, it has absurdly high start-up times. I benchmarked it on a mobile device from 2021 and got startup times of ~7 seconds for loading a cached timetable. In my opinion this is unacceptable. Imagine having to find the right classroom quickly but you first need to wait for the timetable app to load for 7 seconds.

At some point, I was annoyed of this and decided to reverse-engineer the private API behind this TimeTable Webapp...

Reverse engineering

While tracking network requests, I noticed that that WebApp was actually even worse than I thought. It actually downloads 5 static images (used as a background for weeks with holidays) everytime your start up the app. Caching of these images is explicitly disabled using request headers. Motivated by this sign of a need for an alternative client, I continued reverse-engineering the API and implementing a Client. First in C# for quick testing, then I translated it into Java to create a native android app.

My own native android client

After a lot of work, I finally managed to completely show a timetable from the API in my own app. This was really cool. I implemented a caching system that asynchronously loads and displays a timetable from cache while trying to load a potentially changed version from the API. Having the whole app as a native android app and implementing custom high performance caching granted my app massive startup time advantages. While comparing my app to the official react-based PWA on that older phone mentioned earlier, I managed to get my startup-time down to 11% of that of the offical app. In other words, my app is 8.8x faster than the offical app.

Authentication

While I really liked my app, there was one thing holding me back from publishing it: There was no way for normal people to log in. At that time, the way I logged in way copying a refresh token from devtools into my app. The problem with login was that I couldn't just reverse-engineer that one too, that wasn't just any login, that was a microsoft login. Our timetable app used micrsoft 365 account for logging in. Eventually, I managed to create an activity in my app that opens a webview with the microsoft login, waits for it to redirect to the official timetable webapp, then intercepts that redirection and takes the OAuth-Code from it. I could then use this OAuth-Code to get a refresh-token from my schools API.

A WearOS App

After successfully creating a native android client, I kind of wanted to create a WearOS-App for android-based smartwatches. I just tried it out and tested it on an emulator and it worked quite well! In the end, this actually convinced my dad to buy me smartwatch to test it on. So, now you can also have your timetable on your wrist. (At least if you're a student at my highschool)

Conclusion

After completing the base functionality of the app, I added quite a lot of additional features like complications for WearOS (having your current room and subject right on your watchface) and a place for intelligently compiled context-aware information about your timetable.

The App is available in the Playstore. There is also a demo-mode that works with example timetable-data in case you'd like to try it out without being a student of my school. Unfortunately the whole UI is purely in german. Localization just isn't worth it for a local highschool.