Hanu student core - an android application based on existing web service
HANU STUDENT CORE – AN ANDROID APPLICATION
BASED ON EXISTING WEB SERVICE
SVTH: Đỗ Hải Bình
GVHD: ThS Luyện Thu Trang
Abstract— Smartphones have become increasingly popular around the world in recent years,
therefore, smartphone applications, especially for Android and iOS, are greatly in need these days.
For legacy system with outdated user interface that has little usability on handheld devices such as
Hanoi University’s Student Management system for Students, a smartphone application built on
existing web service provides a convenient means of accessing student data on-the-fly. In this paper,
the construction of Hanu Student Core application on Android platform will be examined.
Key words— Android application, student management, web service
I. INTRODUCTION
Hanoi University has been using an excellent student management system for student
users which has a nice, simple to use user interface if viewed on desktop devices. However, in
recent years, the main audience of the application has been students who mainly use
smartphones to access the system, and the current system‘s user interface is not suitable for
interaction on small-screen devices. As a regular user of the system, the author of this paper
came up with an idea to build a web service exposing the current system‘s functionalities,
along with an Android application to provide a mobile-friendly user interface to the user.
II. BACKGROUND KNOWLEDGE
A. Android User Interface‘s core components: Activities and Fragments
In Android, Activities are among the most important components. Activities in Android
represent an entry point to some of an application‘s functionalities; for instance: when users
open the Facebook application from the Application drawer, the home page might be what
they see, but if they use a ―Share with Facebook‖ button, the Facebook app still launches but
goes straight to the screen where user composes an article. However the application is
structured, Activities remain one of the core building blocks.
Fragments represent a section of an activity that can be interacted with. Take Facebook
application as an example again: In the main activity, there are sections like news feed, group
feeds, profile, notifications and settings, each of which is a fragment. Fragments are different
from Activities in the sense that Fragments cannot exist in isolation but have to be attached to
an Activity host to function properly. Fragments‘ lifelines are the same as that of the Activity
hosting them: When the activity is paused, hosted fragments are put in paused state; when the
activity ends its lifetime, fragments inside it are also destroyed. When the activity is active, it
can directly manipulate the lifecycle of its fragments.
B. Android application recommended architecture: Model-View-View Model
130
There are several ways in which an Android application can be built. The architecture
can be Model-View-Controller, in which Views are layout files, Activities and Fragments act
as Controllers, and the Models contain domain objects holding the data along with the
mechanisms to interact with databases. However, Activities always have to do several view-
related works regardless of the architecture being applied; therefore, Activities have more
than one responsibility. This is a violation of Single Responsibility Rule which is a principle
of Object-Oriented Design and should be avoided due to poor testability. Then came better
architecture in terms of ―Separation of Concerns‖ – the fact that software components have
little dependence on each other so that the components can be reused without major
modifications across different projects. They are: Clean Architecture – which is proposed by
the author Uncle Bob in the book with the same name, based on Model-View-Presenter
architecture pattern, and the recommended architecture by Google, Model-View-View Model.
Both architecture patterns promote the separation of system components by defining several
architectural layers and strict communication disciplines between them.
Figure 1: Google‘s recommended Model-View-View Model architecture for Android
(Image courtesy of Android Developers)
In Android‘s Model-View-View Model architecture, there are three layers:
View layer: Comprises of Activities, Fragments and View components, the View
layer exists to deliver the rendered graphical content to the device‘s screen and to listen for
user interactions with the User Interface to trigger appropriate event handler.
View Model layer: Consists of ViewModels that are used by Views to render content.
ViewModels need to update their data regularly, which is facilitated by using implementations
of LiveData interface.
Data layer: This layer contains domain objects and their Repository to support data
operations with both remote data source and local data source. Usage of this layer includes:
getting data from a Web API, caching data to a local database provider such as the lightweight
SQLite database through an interface like Room.
In this architecture, a layer may only have knowledge about the next layer. In other
words: Views layer should only know what is in ViewModels, ViewModels should only
know what the Repositories does and should never know what will be done in the Views
layer. Therefore, the dependencies between system components are minimized. The author
has applied Model-View-ViewModel architecture in Hanu Students Core application to
demonstrate how the architecture works.
C.ASP.NET Core Web API
ASP.NET Core Web API is a web API technology based on Microsoft‘s .NET Core
Framework. It provides enormous support on quickly developing a mock Web API that works
right away. With its powerful Entity Framework, the Web API‘s connection to a database is
greatly simplified and takes little time to set up. The framework also allows for automatic
generation of REST API Controllers for given resources with a set of available HTTP
methods to interact with. For this project, a web service providing data for display in the
application is necessary, therefore I chose .NET Core to quickly draft a Web API application
based on the identified resources.
III. HANU STUDENT CORE ANDROID APPLICATION
Hanu Students Core is a mobile application project with the aim to create an application
that can replace the existing Student Management Web Application for Students for using on
smartphone and small-screen devices. In the Core version, available functionalities include:
Log in, log out, view profile, view student‘s related information including timetable, unpaid
tuition fee, enrolled classes‘ information and marks, and make course registration. In this
project, a mock web service written using ASP.NET Core framework was used locally in
place of the university‘s real backend server, however, if the project catches the attention of
Hanoi University‘s Student Management board, the web service will be adjusted to the
university‘s current backend so that the API design of the web service stays intact.
D.Method
Due to the requirements being fixed from the beginning, the development of this project
was based on Waterfall Software Development Lifecycle, with the following phases:
Requirements definition, Analysis, Design, Implementation, Testing. In such a length-
constrained paper, I will only discuss the most important phases in my development of this
application.
1) Requirements definition
Based on the proposal, the system is only for Hanoi University students, therefore there
is only one actor, Student. In this system, students can:
Log in/log out
View university‘s articles
View personal profile
132
View timetable for the current semester
View information of an enrolled class
View course marks
View unpaid tuition fee
Resolve unpaid tuition fee (mock feature, will work when the university allows the
development of this feature)
Make course registration choices during registration periods. This use case includes
deletion of an existing class registration made during the same period.
2) Application design
The design of this application is derived from Android developers‘ recommended
architecture – Model-View-ViewModel – discussed in Section II, part 2.b. Overall, the project
is divided into main packages:
base: Contains base interfaces and abstract class for implementation in other classes.
model: Contains model classes corresponding to outputs from Web Service.
repository: Contains repository classes with data operations, along with remote data
source classes.
ui: Contains fragments, activities and view components.
viewmodel: Contains ViewModel classes, each has access to corresponding
repository.
util: Container of helper classes that support operations of other classes in the
application.
Due to the length restriction of this paper, class diagrams are not attached. They can be
found in Hanu Students‘ Design Diagrams on Google Drive [Appendix. 4]
3) Implementation
a) Android application development
Due to the mobile application being more complex to build, the author made the
decision to build it first. The Android application was developed feature-by-feature, with API
connection to mock API service provided by Anypoint. In the development of each feature,
the Remote Data Source is developed first, followed by Repository, then comes the
development of individual view components within the fragment view, finally gluing them
together with their Fragment. What takes the most time in developing this application is to
build the User Interface using both XML markup and Java classes – which is much more
difficult handle as compared to simply building HTML user interfaces for web applications.
b) Web API development
The Web API‘s development was simplified as much as possible. The author used one
controller per resource, in which methods to handle specified HTTP methods in the API
specification. To serve dynamic data, the Web API is connected to a reused database from a
study project of mine in the previous semester. There are also Converters to handle the
conversion from database format to the format that will be returned as specified in API
specification.
Figure 2: A normal .NET Core Web API Controller method with Entity Framework used.
This method corresponding to the endpoint method GET /tuition which returns the
student‘s list of both paid and unpaid tuition fee up to the present. Note that students‘
usernames would always be their ID, which are integer numbers.
Figure 3: A custom converter to handle the conversion from FeeLine entity to
TuitionFee result as specified in the API design.
E. Results
After a long time working on this project, the complete Web API implementation was
134
done with data from the database of a previous project I have done on Student Management
System. The Android application‘s alpha version was also completed with all listed use cases
satisfied. Attached in this section are screenshots from the most outstanding use cases only.
Use cases such as view profile or view course marks are skipped from this paper due to their
simplicity: they only need to simply display the data in either textual form or tabular form.
Figure 4: University articles. All university articles are displayed in this fragment.
re 5: Register in course use case.
In this use case, students choose to enroll in several classes, then press the floating Save
button to save their choices. If successful, the student is successfully enrolled and the class‘
number of remaining slots is automatically updated.
Figure 6: View Timetable use case.
In this use case, students are first presented with a list of all timetable periods of classes
they enrolled in during course registration period. Then, students can tap on a course‘s
timetable unit to view details about the course and the class, including the list of students who
also enrolled in this class. In this screen, students can also create alarm for the class times of
the class.
F. Evaluation
1) Advantages of the application
After a long and hard time spent on the development of this application, a stable
working ALPHA version has been released, with all the features listed in Requirements
definition section are implemented. The implementation strictly followed Google‘s
recommended architecture for Android platform. The local web service is up and
running, providing correct data format for use in the application. The user interface is mobile-
friendly; features that are suitable for overall smartphone experience are implemented, for
example: setting alarm for a class – in a very same way as how Google implemented in its
Calendar application.
2) The application‘s shortcomings
However, such a development duration was not enough for an inexperience Android
application developer to justify the application in its finest; there are still a number of flaws
ongoing within the application. Firstly, multilingual is not yet taken in
consideration. Currently, the application only supports Vietnamese language, not yet having
support for English. This can be resolved by using localized resource files in
Android. Secondly, Android views are not optimized. The application can change to use
better performing layouts and containers to improve performance, such as using Recycler
136
View in place of Linear Layout to display a list of items. Next, API calls are made every
time the fragment is reload. Solution to this is to cache the fragment state in a local database
such as SQLite and keep it for an amount of time. Moreover, force reload in the application
may be implemented in the same way as applications like Facebook. Finally, support for real-
time data update is not available. This should be done by employing a Cloud Messaging
service like Google Cloud Messaging or Firebase to broadcast messages from the web
service to subscribed devices. Using a cloud messaging service also makes it possible to make
real-time push notifications, which are currently lacking in this application.
3) Future development
Based on what has been done and what had not been nailed after the development of the
application, there are several jobs to be done in the future development of the application.
Firstly, all the shortcomings of the application listed in the previous section need to be
resolved,
so
that
other
aspects
of
the
application
can
be
continued. Next, other useful functionalities may be added to the application, such
as: registering for dormitory, paying dormitory fee, and co-operate with a well-
known banking service provider to finalize use cases concerning about paying money. In
addition, the application can be expanded in such a way that a functional social network
is added into the system to attract students to use this application. Specifically, the student
can: find and add friends, make instant messaging with friends, join groups, publish articles in
a similar way as Facebook. The backend of the application should then be able to
automatically create student groups based on the list of enrolments in a course class. If those
new functionalities are added into this application, Hanu Students application will provide a
complete experience of the application to all students of Hanoi University.
IV. CONCLUSION
Building an Android application using a web service as data provider is becoming
increasingly popular in recent years, due to the massive widespread of Internet usage around
the world. While it is acceptable to develop a mobile-friendly application, it does not always
provide the complete mobile experience to users, therefore, mobile applications play an
important role in improving mobile user experience. In this paper, the creation of Hanu
Students Core Application for Android platform along with the use of a local web service was
examined. While the application is not the smoothest application to be used, it demonstrated
what mobile applications can offer beyond the native user interface and experience. In the
following time to come, the author will further develop the application so that its usability is
improved, and it will attract more attention from students of Hanoi University, which are the
target audience of this application.
REFERENCES
[1] developer.android.com. Introduction to Activities | Android Developers. [online] Available
[2] developer.android.com. Fragments | Android Developers. [online] Available at:
[3] developer.android.com. Guide to app architecture | Android Developers. [online]
[4] guides.codepath.com. Architecture of Android Apps | Codepath Android Cliffnotes [online]
2020]
[5] Patni, S., 2017. Pro Restful APIs. Apress.
APPENDIX
[1] Hanu Students application‘s repository | binhdoitsme/HanuStudentsAndroid, available on
[2] Hanu Students Web API‘s repository | binhdoitsme/HanuStudentsApi, available on Github
[3] Hanu Students (Core) API specification, available on Exchange at:
42360a72f385/hanustudents_core/minor/1.0/
[4] Hanu
Students‘
Design
Diagrams,
available
on
Google
Drive
at:
https://drive.google.com/open?id=1qbmAJ84_T86D-p8CYEbSTeT6BuzDXG_C
138
9 trang
17300
Free
Bạn đang xem tài liệu "Hanu student core - an android application based on existing web service", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- hanu_student_core_an_android_application_based_on_existing_w.pdf
