This series (yes, it will be a series) is taken from the paper I have written in the university. It is a report on the process of building “Хочу в ТГУ” application.
In case you want to have a look at the application… all of a sudden it is only available in the Russian language now. If this doesn’t scare you, you may find an iOS version here and Android version here.
I decided to publish the text, first of all, since my paper was highly scored by four academics who had read it. I would also like to thank my supervisor Lidia Ivanova who has pushed me to make it much better than I would make it myself 😃.
I also have modified text a bit. Mostly changed dry and dull formal writing to something more alive.
Tomsk State University (I will mostly use “TSU” abbreviation here) has a special website with many important and helpful information for enrollees. With information about the application process, available programs and so forth.
And it’s also had a native application, but it did not support updated API, which caused many usability problems.
And, as I had an internship at university (where we had to work on real-world projects😃), I have been given the task to develop a new application😃.
Taking into account the fact that the application will be distributed to the Android and iOS marketplaces, the goal was to develop a cross-platform application.
To achieve this goal, the following things were done:
I will drop section with the research of the existing solutions out as it doesn’t bring any important information.
This article is intended to show the formal application design (a.k.a analysis) that is done to clarify:
After reviewing existing applications and receiving requirements for this application from the university stuff, functional and non-functional requirements were formed. This is a functionality that a complete application should provide to the user.
To show the functional requirements, UML Use-Cases diagram was drawn:
To represent the business domain(what is that), corresponding diagram was made:
Question entity represents fixed question-answers loaded from the server and shown to the user on the screen, while
PresonalQuestion represents an entity that is filled by the user-provided data(through the in-app form) that is sent to the server later on.
Considering that the app should run on both Android and iOS operating systems, cross-platform development framework was in favourable choice to native development.
Regarding main development, everything happened in Visual Studio Code editor from Microsoft. It allows to develop applications for Flutter and have a fast and minimalistic interface.
Additionally, Android Studio IDE from Google and Xcode IDE from Apple were used for working on platform-specific areas like creating and running Android Emulators and iOS Simulators, for setting applications ids, names, icons, splash screens.
In the application additional open-source libraries were also used to cover development needs:
Flutter framework does not have build-in architecture system, nor it provides one best-practice solution or approach. Developers should choose architecture solution by themselves from quite a significant amount of approaches that could differ a lot.
The vanilla approach represents an application where everything happens in application widgets. All logic, data operations, manipulations, UI encapsulated together. This approach is fast and easy to implement and follow for small applications with very low or no business logic. However, for more significant applications with different business processes, this results in huge classes that are hardly maintainable, updateable and testable.
BLoC approach put much more structure into the application compared to the vanilla approach. It separates an application into three layers: presentation, business logic, data (this is also discussed in more details next section). Each layer is picked out by the responsibility area and limited to what it should do in a concrete area(UI, business logic…).
Also, BLoC makes the use of Dart build-in reactive programming solutions, which helps to build a fast and reactive app with relatively easy implementation. An example: widgets subscribe to state stream of the BLoC and UI updates automatically as soon as the new state with data is available(which is loaded from the server, for example).
Thanks to the separation of responsibilities, it is easier to test and change different parts of the application.
MobX – this package and approach resemble BLoC in a reactive programming approach in connection UI and data. However, it puts a bit less structure on responsibilities separation and specializes mostly on reactive data delivery. Though, MobX also present separation of business logic and data operations from UI, but lack the level of testability of BLoC.
After the analysis, the BLoC approach has been chosen for the architecture. It’s one that suite well for the app that fetches a lot of data from the servers and wraps most of its logic around it.
To represent the architecture and show “layering” in the application UML package diagram was drawn:
Each package in the layer poses behaviour peculiar to only this layer.
As can be seen, there are three main layers:
Presentation – this layer contains everything that would be shown on the screen to the user:
Business Logic – this layer contains the business logic of the application. Elements in this layer are responsible for the correct work and behaviour of the application. Here are the packages that are responsible for that:
Data – this layer represents all objects that provide data to other parts of the application:
There are also additional packages that do not fit into the above layers:
For showing application screens and navigation between them, several UML State diagrams were drawn:
After launching the application Info Screen (above picture) opens. Here user can read news and open them in more detail or view stories.
If the user wants to use a calculator to search for different courses, he opens the corresponding screen (above) using the bottom navigation bar. On the screen open corresponding BLoC check if there are saved subjects for the calculator. If subjects persist in DB, they are loaded, and Program Preview screen opens automatically. If no, the user sees a welcome screen that asks to select subjects for the calculator on Subjects Choose screen, after that Program Preview screen opens.
For getting answers for different questions, the user can open FAQ screen (above) using the bottom navigation bar and browse some ready-made answers and questions. For example, read Undergraduate Frequently Asked Questions. If the user has a question that is not covered there, he can ask his personal question on Personal Question screen.
To find out upcoming events, the user can open the Calendar screen using the bottom navigation bar and browse the monthly calendar with events. If the user wants to read more details about the event, he can view them on the Event screen.
If the user wants to see his rank for enrolled courses, he opens the corresponding screen (above) using the bottom navigation bar. On the screen open corresponding BLoC check if there are saved user credentials. If user data persist in DB, they are loaded, and user rank is opened on Ranks screen. If no, the user sees a welcome screen that asks him to fill his full name on Name screen. After that screen with ranks opens.
Also, the user can close and exit application being on the first screen of the type.
As there is a need to cache some data loaded from the server application needed a database. Since the primary usage of the database is lying on news saving and loading them on every app launch, speed was an essential factor. With this regard in mind and the fact that data that would be stored has little or no relations (diagram below), Hive DB was chosen. It is a NoSQL key-value database that works incredibly fast compared to SQLite, the classic mobile relational database. Additionally, it is much faster in implementation compared to SQLite since it has needed queries build-in and require less management and provisioning.
These are what have been done to ensure a fluid start of application implementation in code.
Next article on how it all was implemented is running in process… stay tuned😉.
By the way, you always can change the share text.
By the way, you always can change the share text.