Implementing the Mobile Application
The particularity of XAML compared to Windows Forms is that the graphical user interface (GUI) must also be implemented in code. The code that defines the content of the initial page (or Log In page) can be seen below:
<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
x:Class="csNEA_mobileApp.LoginScreen"
BackgroundColor="{AppThemeBinding Dark=Black, Light=White}">
<ContentPage.Content>
<StackLayout HorizontalOptions="Center" VerticalOptions="Center">
<Label Text="Welcome! Please log in."/>
<Entry x:Name="entUserName" Placeholder="Username" />
<Entry x:Name="entPasswd" Placeholder="Password" IsPassword="True" />
<Entry x:Name="entAddress" Placeholder="Database Address" />
<Entry x:Name="entDBPass" Placeholder="Database Password" />
<Button Text="Log In" Clicked="Button_Clicked"/>
</StackLayout>
</ContentPage.Content>
</ContentPage>Similarly implemented as HTML code, objects are defined and properties such as their name, Clicked event name or text can be set. The name is especially useful to be able to link to it from the code-behind as seen below:
After logging in successfully, the Log In page will be popped and the main page will be on display. The code of the main page is run first regardless, since it is the first page to be accessed in the namespace and thus added to the stack of pages. The Log In page will be pushed onto the stack in case there is no user currently signed into the application. The stack is managed by Xamarin Forms.
Designing the Main Page is done with the below XAML code:
Data binding is used here, since the members of the ListView in the Feed page are constructed through the FeedPost class, the code of which can be found below:
As a list of the type ‘FeedPost’ is updated while the program is running, the contents of that list will be dynamically shown in the ListView due to this bond. Additionally, the ‘refresh’ state of the ListView is bound to a subroutine in the code-behind, to remove all members of the list and get them again from the database.
The c# implementation of the Main Page, or the ‘code-behind’ can be found below:
The above code is run first, which will determine whether a user has logged in previously or if the application was run without a user signed in. For the first condition, their timetable and feed posts are retrieved from the database. Otherwise the log in page will be pushed onto the stack of pages managed by Xamarin Forms with the procedure ShowLogin( ), shown below:
The below procedure will retrieve the information needed to access the database and assign it to the public SQL Builder variable. Part of the information will be retrieved from the application’s settings, where information can be stored (after the user has logged in) even when the application is not running.
The below procedure will get all rows from the database in the Feed table and update the list, the data of which the ListView in the 2nd tab is bound to.
The below procedure will get the logged in user’s “teachings”, AKA their timetable based on the day the application is launched. In the meantime, the appropriate lesson names based on the information in the teachings rows will be retrieved from the Lessons table so that the user can see the string name of lessons in their schedule, not just their numeric identifiers:
The below function will return the numeric representation of the week days:
The below procedure will update the text of the Frame on top of the first tab of the Main Page to greet the logged in user:
The below procedure will be called once the user clicks on the button btnChangePasswd – it will perform validation before sending the new password to the database.
The below procedures will be used to log the user out of the mobile application, set the appropriate setting so that the application requires a user to log in at launch and also push the Log-In screen to the stack of pages so it is visible.
The below procedure will push the AttendancePage to the stack of pages so it is visible to the user, if the date of the application’s launch exists (checked through the DateExists subroutine). It will also set a variable to the “code-behind” of the AttendancePage so that the user’s period selection is ‘passed’ to that class:
The below function will check whether the date of the application’s launch exists in the Dates table in the database:
The below function will get the current password of the logged in user from the database, since it is not retained between launches.
The below procedure will display “pop-ups” when an error occurs. Its numeric parameter determines what type of error will be displayed:
After the user selects a period in the first tab and tap on the “Take Attendance” button, the AttendancePage is displayed where the user will take the attendance for that day and period according to their timetable/teachings. The below XAML code designs the ContentPage:
Once again, data binding is used to link the custom items of the ListView that makes up the page to objects of the Student class. The code that makes up the Students class is as follows:
The C# ‘code-behind’ of the page follows:
The following code is run as the class is accessed from the namespace. It is responsible for eventually populating the list teachers must go through to mark students as present or absent. Students will be retrieved either on their own or along with pre-recorded attendance information which may be present if the teacher has filled in the register already.
The following code is run after the teacher has marked students in the list as present or absent. It sends the absence information to the database.
The following procedure keeps the database information temporarily to be accessed by the class:
The following function returns the numeric identification of today’s day based on DateTime:
The following function returns the group that the teacher is teaching for the passed period and day numeric representations:
The following function checks whether absence information for the group returned from the function above has been recorded already in the database:
Last updated