In my ex work place staff worked according to the rolling rota.There were 7 rotas. Basically we worked 5 days in a row and after that we had 2 days off.But there were exception to the mentioned rule because every 4 weeks we could work 6 times in a row or we could have 3 days off instead of 2.
The environment I work for required to have the balanced rota so the business could run smoothly. That is why different rotas have different days off. Staff knew their rotas for the whole year in advance so we could easily plan holidays for example..
screenshots of Rotaholic
 |
 |
 |
 |
 |
 |
 |
 |
 |
The goal of the app is to show days off for different rotas and different years. Also user of the app can mark on the calendar their taken and future holidays. It is possible to change the standard 8h of taken holidays to 2 h . It used to be quite popular among the staff to shorten their working day.
| Development of the app. The technical words.
The main reason of writing it was to gain some experience in the software development process. The app is written in dart and Flutter framework is used. The google cross platform development kit. The version of the Flutter framework I used is <2.0 so the null safety feature is not used.
I put lots of attention to software architecture. I tried to structure the code in the way to follow the domain driven design. The written software is divided into modules in order to achieve the visual separation of these layers. High level module:domain doesn't depend on low level. This is achieved by dependency inversion. Use cases communicate with infrastructure layer through interfaces. There is requirement forced by domain level that concrete repositories implement interface , which is required if these to 2 layers want to communicate.
The role of the repositories is to cache the data , retrieve the data . They talk to local or/and remote data sources using of course interfaces. Again it is easy to change the database because details /what kind of data source is used/ depend on abstraction.
Data source's api can be fit into repositories / using adapter design pattern/
I use BLOC as a state management .User by interaction with ui emits the events. These flow to Bloc which answers on events by calling the use cases and streaming states .That causes ui to refresh. Under the hood the Observer pattern is used when blocBuilder widget responds to ui state changes. It is very important that this ui level is not polluted with direct calls to databases or with other objects which don't belong to the layer.That is why presentation layer is not hard coupled with other domains.I avoid this spaghetti code and maintenance nightmare with the help of the BLOC-state management technique.
I would like to point out on the visuals here. Flutter uses Material Design to nicely show interaction between the user and the app. The developer has only to choose the main (primary) color of the app. Material Widgets are already preprogrammed how to graphically represent data on the screen, how to show interactive elements on the screen.