Developing a Fan Made Version Of My University’s App
Finding motivation
About three years ago, my university released an app that allowed students to see their timetable for the week, subjects and grades, attendance records, etc. All those features were really helpful, that’s why I used the app quite often. Although, the UI could’ve been much better, in my opinion. As a mobile developer, I knew that there were a lot of fairly easy improvements that could’ve been made to make the app more “usable”. But did those details stop me from using the app? Not at all.
It was all good until one day last year, the app was no longer available in the Play Store. Instead, there was a new app. “So they finally decided to improve the app, great!”, I thought. As this was a new, different app, I didn’t have to uninstall the previous one. I could have gotten rid of the older version in that moment… but luckily I didn’t. The new app was absolutely terrible.
A month before releasing that app, the university’s intranet was redesigned (for better, if compared with the previous version). It looked OK on desktop, but the design was definitely not mobile-first. The new app was basically an embedded web that displayed the intranet login. The main problems (which may be solved by now, IDK) with this new “solution” were:
- Probably the most important feature, the weekly timetable, was no longer available.
- The session was never saved. Not even the credentials, which you had to type every single time you opened the app.
- It was way too slow. Every action made the entire app reload.
- Navigation was too complicated. There were too many irrelevant options, and the important ones were not easy to find at all.
- You know something is seriously wrong when this happens:
You may say that maybe I’m too critical about embedded web apps. Maybe my mobile developer heart is too harsh with them. Maybe I was the only one feeling that this update was a huge mistake. Except I wasn’t. The rating, which used to be 3.9 at the previous app, dropped to 1.9. The reviews were all about demanding the old version back.
Despite everything, I tried to give it a try for a few days, but then I gave up and realised how much I needed the older version. It was no longer available at the Play Store, but luckily I still had it installed. But what about the ones who didn’t? They wanted and needed it as much as I did.
Eventually something shocking happened. When you publish apps on the store, you do everything in your hands to increase the number of installations. You try the description and screenshots to be perfect. You do campaigns and experiments trying to attract users who will hopefully install the app. How often do you see that users want your app so badly, that they decide to search for the APK and install it manually? The process is not straightforward. You have to enable the “Allow installations from unknown sources” option first (sounds safe, huh?), then get the APK, download and install it. How do you get your users to do all that? Desperate times, desperate measures, I assume. Eventually a fellow student posted a step-by-step guide (which included the APK) on a university group on Facebook. Before that, people care enough to google it themselves.
“So people are willing to do that, huh?”, I thought. If they were going through all that trouble to download a really old (but functional) app, why not make it really worth it? Many times before I saw the app and thought “I can do better”, so I did. As they say…
“If you want things to be done right, do them yourself”
Getting to work
I started from scratch and in 8 days I had the application released. Here is how I did it.
Note: from now on, a little background on software development may be necessary, yet I’ll do my best to make it as understandable as possible for everyone.
Phase 1: The Dirty Work of Mr. Curiosity
I could’ve had the best design ever in mind (which I didn’t), but if the app was not functional, the effort was pointless. To make it work properly, I had to somehow get access to the university system: login, timetables, grades, attendance, everything.
This was not the classical situation were my teammates provide the backend support, and the university was not going to give away its web services to a curious student. To find them out, I decided to apply reverse engineering to the old app. As described in Reversing: The Secrets of Reverse Engineering by Eldad Eilam:
In the software world reverse engineering boils down to taking an existing program for which source-code or proper documentation is not available and attempting to recover details regarding its’ design and implementation.
Reverse engineering applied to Android apps basically consists on a process called decompiling. There are some tools available online that allow you to upload a .apk, and get a bunch of files that contain the source code of the application. As a developer, you can apply some techniques to make that code as unreadable as possible (and therefore harder to reverse), but if someone really wants to unveil the secrets of your app, it’s always possible to find a way.
Once you have the source code, all you have to do is read it and try to understand how things work. In this case the code was not obfuscated, so that was a plus. However, the code base was like a compilation of bad practices, so it was painful to read. Eventually, I discovered all the web services that I needed to start working on the app.
So it was obviously tedious, but why do I call this phase “the dirty work”? Well, there was one concern I had about reverse engineering. Is it ethical? Is it legal? Can I go to jail for doing it? I did my research but didn’t find a conclusive answer. I decided to do it anyway, because… what where the odds of getting sued by my own university for applying “their teachings” to make something useful and harmless for their students? (or at least that would be my argument at my possible upcoming trial).
Until now I don’t have the definite answer, but I can tell you that right now I’m in my bedroom and not locked in a cell. My guess is that it’s because I didn’t distribute the app through Play Store, and because I did not make any kind of money out of it. Although, if you have some experience or expert opinion on the subject, please let me know!
Phase 2: Defining the scope — 1000 Things
At this point, I knew what I could and what I couldn’t do, given the web services I discovered. Based on them, I wrote down some simple user stories (descriptions of the functionalities) that the app had to have:
- As a student, I want to access the application using my university credentials, so that I can visualise relevant content for me.
- As a student, I want my session to remain opened and / or save my credentials, so that I don’t have to type them every single time. (this was one of the main criticisms against the new app)
- As a student, I want to visualise my weekly timetable, so that I know when and where my lectures are taking place everyday.
- As a student, I want to visualise my assessments and grades for each subject, so that I’m aware of how b̶a̶d I’m doing right now.
- As a student, I want to see my attendance record, so that I can avoid DPI (which is failing the module for missing over 30% of the lectures).
As you can see, all features are related to students. The previous app was also available for teachers, but that was out of the scope of mine. There were other features that I would later decide to either implement or not:
- As a student, I want to see my classmates info (name and photo) for every subject, so that I can stalk them on Facebook later. This was a feature that the iOS app had, but the Android one lacked. → it was included ✔ (Update: I didn’t notice it back then, but looking back, I regret implementing this feature. I never heard of anyone misusing it, but the fact that it could have potentially enabled a real stalker is no good. I should have known better.)
- As a student, I want to calculate my final grade on hypothetical scenarios, so that I can take informed decisions (study a lot, study a little, drop out, etc.) before sitting the exams. This was a feature that I took from my other app, uCalc. → it was included ✔︎
- As a student, I want to see my pending payments, so that I can avoid getting charged an extra fee for paying out of time. → possible, but not included… yet ✘
- As a student, I want to reserve university computers, so that I can use them later without getting kicked out. → it was included ✔︎
- As a student, I want to be notified when one of my grades is uploaded to the system, so that I don’t have to check it myself every five minutes. → out of my hands, no easy solution ✘
Phase 3: Prototyping a Beautiful Mess
One of the reasons why my first app took over two years to be launched was that I was never satisfied with the design. This was not happening again. I spent a few hours on Pinterest to get some inspiration. The material guidelines were helpful too. I had some thoughts in mind, and started prototyping by hand the basic app flow. I just wanted to have the basic structure so I could start coding: most of the details were in my head or could be figured out later anyway.
Phase 4: Work In Progress
Whenever developers have personal projects which involve no money, they usually put effort on them for a couple of reasons: to improve and learn new stuff. This project helped me to get introduced into:
- Retrofit
- RxJava
- MVVM
- Firebase
- Unit testing & Kotlin, but I played with those just a few weeks ago, way after deploying the app (it was released last October)
So, with the web services waiting to be used and the designs waiting to be brought to life, I started coding the application. I had plenty of free time at that moment, so I basically coded from 11am (lots of free time comes with lots of sleep too) to 3am for 6 days.
Phase 5: Unfold — Distributing the app
This was not the classical situation when you just generate an APK, upload it to Play Store, and you’re done. I didn’t consider it appropriate to a upload an app that uses web services for which I didn’t have the authorization. I made the right call, because I later talked with one of the representatives of my university, and he told me that was one of the reasons the university didn’t take any actions.
I decided to distribute the app just sharing the APK as a file on Google Drive. Most of the students of my university are members of a famous Facebook group, which I used to advertise the app. As explained earlier, most already knew how to install an APK manually, so I hoped that wouldn’t be an issue.
When the app was almost ready, I uploaded a GIF with a sneak peek of the app, with a caption that said “Soon”
The post got over 400 likes, so I supposed it was a good indicator. People where curious at the very least; they even started giving suggestions to make it better.
When the app was ready, I posted a link to the file on Google Drive, and explained briefly (kinda) why I decided to do it.
Results
Before distributing the app, I integrated as many analytics tools as I could. Fabric, Google Analytics, Facebook Analytics, Firebase Analytics, and Amplitude. Why not take the opportunity and experiment with everything? As the app was not on Play Store, I had to rely on other tools to know how good the user adoption was. The one I ended using the most was Fabric, because in my opinion it provides the most meaningful statistics.
After a few weeks I got some interesting figures:
- +2,500 installs
- ~1.2k daily users
- At one point, over half the users (52.2%) were highly active. A highly active user uses the app 6–7 days a week.
- The feature to calculate your hypothetical final grade, which I was not going to include in the first place, was used ~8 times a day by each user, and overall it’s been used +250,000 times! I was told several times that this feature made a HUGE difference, because it solves a very common problem that people have during examination period. Once again, giving the users something useful worked as a charm.
- Updates were a problem. As the app was not distributed through Play Store, updates were not automatic. Of course the first version was not perfect, so I fixed the errors on later versions. Even though I sent push notifications requesting users to update their apps manually, over half the users still have the very first version.
Too much talking, show me the code!
For a long time I decided not to publish the code. Not anymore, the code is now available here:
https://github.com/Bruno125/Unofficial-Ups
Final remarks
- I tried to talk with the university to make it the official app, but it’s complicated, because — I’ve always wanted to say this— it’s confidential. Plus, at the time all this happened I was v̶a̶c̶a̶t̶i̶o̶n̶i̶n̶g studying abroad, so the communication was even more complicated.
- It was amazing to know that thousands of students found the app useful and are grateful to me. I always knew I would get some recognition for doing it and I must admit that motivated me a bit.
- A common comment on my post was from people tagging their friends and saying “remember we had this idea?” or “that was our idea!”. Re-doing the university app was probably on every single student thoughts at one point. But nobody ever did it. Remember, ideas are worthless until you bring them to life!
- It was a fun project. I did every phase (requirement gathering, analysis and design, coding, deployment) in a completely different way of what I’m used to.
- Why not iOS? I’m an iOS developer too. The problem is that in iOS it’s not as easy to distribute an app to that many people as in Android, where you just share the APK. The only way is to upload it to the App Store, which was not an option. So, sorry, iOS users. I know you are pissed, I got your messages, but there’s not much I can do.
- I know the phases’ names on this article are a bit weird and confusing. It was not my initial intention, but out of nowhere I came out with the idea of hiding a secret message on them, so if you found it out please be my friend!