An alternative mobile client for the Untis timetable system.
You can also download the latest automated build from my website.
 |
 |
 |
 |
|---|
- Modern and intuitive user interface
- Simple and straight-forward login process
- Fast timetable loading with smart caching
- Multiple separate accounts/profiles
- RoomFinder to quickly find free rooms
- Info Center for viewing events, contact hours and own absences
- Class management features for teachers (Absence checking, lesson topic editing, ...)
- Break notifications and auto-mute during lessons
The original version of BetterUntis had many design and performance flaws. Since development became increasingly more difficult, the project was scrapepd and I started over from scratch.
Although some parts of the original code were reused, the codebase was entirely switched to Kotlin. Kotlin has many features and libraries that immensely help to communicate with the Untis API and process the timetable data.
Another major change is the use of a custom WeekView (based on Till Hellmund's fork of Android-Week-View) for the timetable display. This also improved performance by a lot.
This major version updated the WeekView component again to be based entirely on Jetpack Compose. Since the rest of the app was already built on Compose, this made it easier to develop and improve the WeekView component.
This version introduces a complete architecture overhaul to follow the latest Android Jetpack guidelines. Additionally, several components (like Untis API Client, Compose Preferences, ...) were separated to their own module to potentially reuse them in other projects.
I established a simple system to manage this Git repository. Basically, there are two main branches: master and develop. They both are permanent and cannot be deleted.
This branch always and only contains the latest release version. This includes alpha/beta releases.
This branch contains the current development version. Small changes and fixes can be committed directly to this branch.
When it reaches a state ready to release, it can be merged into the master-branch and a new release can be published.
Especially bigger features which require multiple commits should branch off develop and merge back into it. These should be named in a way to describe the feature as clearly as possible.
These branches have a limited lifetime. After the last merge back into develop, they should be deleted if no longer needed.
Your help is greatly appreciated, but first please read the following sections to prevent common mistakes:
If you haven't already, sign up for an account at weblate.org . You can then navigate to the BetterUntis translation project.
Select your desired language (or click the “Start new translation“ button at the bottom) and look at "Strings status". All categories marked in red are areas where translations are missing or potentially incorrect. Click on them to start translating.
Your translation will then be automatically included in the next release of BetterUntis.
Anything that requires you to perform code changes should be done on the develop branch. Pull requests should always be based on this branch, except for larger, experimental or incomplete features. These can be on their own, new feature branch.
Please do not submit pull requests that merge into the master branch, except for changes that only affect the repository on GitHub (e.g. README.md changes).
