The problem
A course-management app for a school needs two very different views of the same data: what a student needs to see and do is not what a professor needs, without duplicating the underlying logic twice.
What I built
I built SAMS end to end as a personal project: separate registration and dashboards for students and professors, courses and groups, attendance tracking, grade entry and viewing, electronic course content, and a clubs section. Account flows include OTP and email verification and password changes, and an AES helper handles some of the app’s data protection. It’s a self-contained build I designed and tested myself, not software deployed at any real school or institution, though its screens and data model are built as if it were.
Tech stack
The Android client is written in Java, using Firebase Auth for accounts and Firebase Realtime Database for course, attendance, and grade data.
What I learned
Role-based apps should centralize permissions instead of repeating checks on every screen.
Building separate student and professor dashboards on the same underlying data model showed me how quickly permission checks sprawl across screens if they aren’t centralized early.