32

CHAPTER 4 PROJECT IMPLEMETATION

4.1 Introduction
This chapter shows the process of building the application, views in detail the
process of building a mobile app and dealing with the programming environment, as
well as engaging with other tools that help facilitate the process and working from
different devices simultaneously.

4.2 Project phases

Like any other programming projects, the process of mobile application
development needs to be organized, and to achieve that, a certain set of steps must
be followed:

4.2.1 Creating flutter project

Using Android Studio, a new flutter app is created, named, and stored it in the
desired path as shown in figure (4.1).

Figure (4.1): Create new Flutter app

33
CHAPTER 4 PROJECT IMPLEMETATION

Figure (4.2): A demo Flutter code

A demo flutter application code will be placed in the new project figure (4.2), the
unnecessary code can deleted.
Now, it is time to take two steps:
1. Start creating project files according to the design patterned (file architecture)
that was chosen.
2. Initiate a Git Repository in the project and associate it to a Gitlab project so it
can be managed remotely by multiple users.

4.2.2 File Architecture

There are several design patterns that can be used when developing any
programming app, this project will follow MVC (Model, View, and Controller)
design pattern See figure (4.3).
34
 CHAPTER 4 PROJECT IMPLEMETATION

Figure (4.3): Flutter Architecture pattern for any programming app

In this pattern the application is divided into three main folders:

1. The Model contains only the pure application data (in this case the KPIs data
model), it contains no logic describing how to present the data to a user.
2. The View presents the model’s data to the user. The view knows how to access
the model’s data, but it does not know what this data means or what the user
can do to manipulate it (it can be thought of as the code that represents the
UI).
3. The Controller exists between the view and the model. It listens to events
triggered by the view (or another external source) and executes the appropriate
reaction to these events. In most cases, the reaction is to call a method on the
model. In other words, the controller represents the logic of the application.

Now it is time to create the main folders figure (4.4)

35
 CHAPTER 4 PROJECT IMPLEMETATION

Figure (4.4): Creating the project folders

Note that all project files written in Dart language will be under the lib folder under
one of these three folders.

Figure (4.5) shows the initial files in each of the three folders:
1. The device info controller file holds the methods that will fetch KPI and store
them in the database.
2. The KPIs model represents fetched data.
3. The about, home, and network info screens represent the main screens.
4. The widgets folder contains any extracted code so that everything stays
organized.
Before moving forward in writing the code, it is time to initiate a Git repository in
the project.

Figure (4.5): Creating initial files in the project folder

36
CHAPTER 4 PROJECT IMPLEMETATION

4.2.3 Adding Git to the project

First, a new Gitlab project is created on www.gitlab.com figure (4.6)
The name of the Gitlab project should not be the same as the Flutter project, though
it would be more consistent if it was.

Figure (4.6): Adding Git to the project

Then Gitlab gives an option of adding other participants in the project, by inviting
them via email address figure (4.7):

Figure (4.7): Inviting members to the project

37
 CHAPTER 4 PROJECT IMPLEMETATION

Under the project directory in the command line interface, the following commands
are issued figure (4.8):
After issuing the previous commands, all team members can work on the project
simultaneously, and push changes whenever needed, so everyone stays updated.
4.3 Git flow:
Before starting to write the code, it is important to show the power of Git and Git
flow. GitFlow refers to the flow of the project development, figure (4.8) shows the
GitFlow chart

Figure (4.8): Git flow chart

Figure (4.9): Git commands for pushing a folder into Git repository

38
 CHAPTER 4 PROJECT IMPLEMETATION

Every Git project is divided into branches, and each branch indicates a phase or a
section in the project:

4.3.1 Main Branches

These includes:

Master Represent production-ready state of source code

Develop Represent latest delivered development changes or also called

integration branch.

4.3.2 Feature branches

These May branch off from develop and must merge back into develop

1. Feature branches are also sometimes called topic branches

2. Merge back to develop when adding the new feature to the upcoming release,
if the feature is unstable/incomplete do not merge feature into develop branch
3. Typically exist in developer repos only, not in origin.
4. Use --no-ff flag to merge changes in to develop branch to keep track of the
historical existence of feature branches
5. Delete feature branches when they are finished or discard them in case of a
bad experiment.

39
CHAPTER 4 PROJECT IMPLEMETATION

4.3.3 Release branches:

May branch off from develop and must merge (update the changes) back into
develop and master.

1. Represent preparation of a new production release to deploy changes on

Testing server
2. Do bug fixing in this branch, bug fixes may be continuously merged back into
the develop branch
3. In this branch Adding large new features here is strictly prohibited
4. All features that are targeted for the release must be merged into develop
5. Create a release branch with a name reflecting the new version number
e.g.(git checkout -b release-1.7 develop)

So to conclude the concept of Gitflow, it allows programmers to organize

projects, and go back to any point of their projects without any risk of losing
parts of the project.

In the project, there are two key feature branches:

1. Data fetching branch.

2. Data storing branch.

4.4 Working on the code

This section goes through the important pieces of the code, and will not cover
unnecessary code (e.g. code related to the UI).

40
 CHAPTER 4 PROJECT IMPLEMETATION

4.4.1 Data modeling

Starting by KPIs model as shown in figure:

Figure (4.10): The selected KPIs, location and phone number

Notice in figure (4.10) the selected KPIs, in addition to two important fields:
phoneNumer and location and the reason that they’re both are annotated by the
keyword @required is because of their importance when fetching the data from the
user, any data will be clueless if it was missing one of these elements, so this prevents
the creation of an instance of the class KPIs for a user without fetching these two
parameters, whereas other fields can be empty.
The next table shows the chosen fetched KPIs, and their applicability in
each mobile generation.

41
CHAPTER 4 PROJECT IMPLEMETATION

Table (4.1): shows the chosen fetched KPIs, and their applicability in each mobile generation

4G 3G 2G
KPIs
Service & Service & Service &
Neighbor cells Neighbor cells Neighbor cells
Cell Identify Code Cid
Yes Yes Yes

Complaint
Yes Yes Yes

Location Area Code lac

Not applicable Yes Yes

operator
Yes Yes Yes

Reference signal received

Yes Not applicable Not applicable
power rsrp
Signal strength rssi
Yes Yes Yes

Reference signal received

Yes Not applicable Not applicable
quality rsrq
Reference signal-signal to noise
Yes Not applicable Not applicable
ratio rssnr
Timing advance ta
Yes Not applicable Not applicable

4.4.2 Data fetching

In order to fetch the data from the device a code that communicates with the
mobile phone sensors, namely antenna(s) is needed, so that it can capture the data
and store it in a readable format. Such code is considered platform specific code and
can’t be written in dart inside the lib folder (where most of the code resides).

Luckily flutter allows us to write native code inside the project and then invoke it
back inside the project, this method is called: Flutter platform channel.
42
CHAPTER 4 PROJECT IMPLEMETATION

Since the project is only working on android, platform specific codes is only written
on the android folders as follows:

1. In the mainactivity file inside the android folder, the following code is placed
inside the mainActivity class:
The code snippet in figure (4.11) shows the typical way of creating a platform
channel from the android side, notice some additional lines of code to assure that
the permissions are granted to read the desired data from the phone.

Figure (4.11): The mainActivity file

2. function that fetches the data:

Figure (4.12): getData() Function to fetch data:

43
CHAPTER 4 PROJECT IMPLEMETATION

In (figure 4.12) the method getData() returns a string that holds allCellInfo, which
means all needed KPIs, and the advantage here is that no need to change the code
according to the mobile generation.
3. Before going back to flutter and invoking the method, the following lines of code
should go inside the AndroidManifest file, in order to grant permission to the
application (figure 4.13).

Figure (4.13): The permission code to the application

4. Now that everything is set, it is time to work in flutter and write the lines of
code as shown in figure (4.14).

44
CHAPTER 4 PROJECT IMPLEMETATION

5. The method getKeyValuePair in figure (4.14) searches for the desired KPIs in
the string response from the android side to a list of entries, whereas the other
method getDeviceInfo puts them in a list so that they can displayed in the UI
and/or sent to the database to store.

Figure (4.14): The getKeyValuePair and getDeviceInfo

4.4.3 Storing data:
As mentioned previously, the data will be stored in an online database, namely
Firebase for practical reasons (see chapter 2 for more details).
In order to prepare the database, follow these steps:
1. Go to www.console.firebase.google.com and create a new project, it is handy
to follow the documents that google offers on www.firebase.google.com/docs
where every step is documented and easy to follow.

45
CHAPTER 4 PROJECT IMPLEMETATION

2. Set the database to accept data as modeled in the KPIs model class, by going
to cloud store and create the following collection as shown in figure (4.15):

3. Get back to the project and add firebase in it, again by following the
documents in step 1.

Figure (4.15): Preparing the database for storing the data

4. Inside the device info controller, define a function that to store data on the
hbv
database.
5. This function will be called whenever the user will send a report to the
company using the app.
Now that everything is in place, it is time to design the UI for the screens.

4.4.4 Designing the layout (View):

As mentioned before, the app consists of three main screens:
1. Home screen
2. About screen
3. Network info screen

46
CHAPTER 4 PROJECT IMPLEMETATION

Home screen:
This is the default screen where the user can test current network performance,
and send a report to the company in case there are any issues (figure 4.16).

Figure (4.17): The Reporting window Figure (4.16): The Home screen

If the user presses Test, the indicator (needle) will point out to the signal quality
according to the signal strength.

47
CHAPTER 4 PROJECT IMPLEMETATION

And if the user presses report the following pop-up window will appear as shown in
figure (4.17).
The user now can simply enter his phone number, and address his problem, and when
presses send report the KPI measurements will be sent as well to the database, this
process happens behind the scene, to reduce complexity for the users.
Network info screen:
This screen is responsible for viewing the KPIs on it, in case the user was
curious to read the measurements and see the cellular network quality on his own,
the KPIs will appear to him as he presses “Test network” figure (4.18)
About screen:
This screen is designed for users to view information about the app, namely
the app version, copyrights if exist, and means to contact the developers in case
they need any extra information as shown in figure (4.19)

Figure (4.19): The About screen Figure (4.18): The About screen

48