Week Eight

Monday (18/03/2018).

Bottom Navigation.

On Monday, I finished off working on the bottom navigation. I had successfully implemented a bottom navigation bar which directed you to the specified pages. However, I had no way of telling which page you were currently on.  I decided that the easiest way to tell what page you were currently on was by adding the text of that page to the bottom. For this I created a method in all my pages called GetBottomNavigationText() this would use the BottomNavigation stacklayout and get it’s children and find the label by name. After this it would set isVisible = true on that label.

Mid project demo.

After I finished the bottom navigation I started looking at preparing the mid-project demo which was tomorrow. I read MMP S09 which relates to the mid-project demonstration, and took notes of the tips Hannah Dee mentioned. I then created a video demonstration of my work so far, just in case the app didn’t work on the day, since previously during my meetings the OAuth wasn’t working due to the device not being connected to the Internet. I also created a short presentation which contained all the topics I would talk about which included:

• Aims of the project.
• Technical information.
• Screen designs, and feedback from those.
• A short demonstration.
• Technical difficulties.
• Remaining work.

These slides would help keep me on track, and refresh my memory as to what I was supposed to be talking about.

Tuesday (19/03/2018).

Finishing up the code.

On Tuesday, prior to finishing my preparation to my mid-project demo. I added Title=”Favourite Genres” to all my content pages, this ensured that the page name would be displayed on each page. Making it clearer what page you were currently on. I also added NavigationPage.HasBackButton=”False” to the top-level pages e.g. the notifications, favourites and books page. This ensured that the back button is only shown during an activity, e.g. the create account process. After I completed this I re-created the video to reflect my recent changes.

Mid project demo.

After this, I continued my preparation for the mid-project demo. Continuing my work from Monday I finished off the PowerPoint slides, I then practised what I was going to say and came up with a sample script of things I was going to say. It was particularly import to practise the demo as I needed to make sure that what I said  correlated to what was on the screen.

My demo was at 1.30, and it went well, while I felt like I was running out of time towards the end, I managed to save enough time for questions at the end. One of the critisms that was mentioned was that the use of Twitter as a form of OAuth limited the amount of potential users of the app. Whilst, I mentioned that Google authentication was a desirable I decided to look into it more later that day.

Google Authentication.

After my mid-project demo I decided to start looking back into Google Authentication, I looked at this tutorial and this tutorial which I used when configuring authentication with Twitter. However, the tutorials I was following returned a 403 ‘that’s an error’ message due to a disallowed user agent. I also completed the ethics form and am now waiting approval from that.

Wednesday (20/03/2018).

Google Authentication..

On Wednesday, I continued looking into OAuth, and I continued working on the tutorial I found Yesterday. However, one problem I was getting was that I kept receiving a redirect_uri_mismatch error on the redirect URI. I then read this article which illustrated that Google had blocked the use of web views, which is what would be used to generate the authentication screen. Therefore, the app would need to redirect to the Google Chrome app to display the redirect screen. I would then need to change this line of code: bool: isUsingNativeUi = true to false. I also needed to change the redirect URI to: ‘com.companyname.LibrarySystem:/oauth2redirect’ which is the name of the package in my manifest file. This then successfully took the user to the Google authentication screen, and allowed them to log in. However it just took them to the Google home page.

I researched into this issue and several people in the comments had a similar issue, which was solved by ensuring that the package name in the manifest file was all lower case. However, when I tried to change this my solution wouldn’t build, and I was unable to find another solution for the problem for the time being. Although over the course of the week I continued to look for a solution.

Validation.

I then added further validation to ensure that a library card had not previously been associated with an account. In my database library card numbers are unique and a user would only be allowed one account associated with the library card. However, this meant that if a user was authenticated with Twitter, they could not create a new Google account with that same library card.

Thursday (21/03/2018).

Image Loading Bug.

On Thursday, I started looking into the warning messages in the hope of trying to fix the Google Authentication so that it redirected into my app. Whilst, doing this I noticed that the FFImageLoading nuget package which I was using to display my images (which was this) was targeting the Android version of 9.0 which was Pie. However, my current Android project was only targeting Android 8.1 (Oreo). I updated the solution to target 9.0, and once this was working I tested it to ensure that when you scrolled down on the page it loaded in the new images automatically which it wasn’t doing previously. As previously it was only loading the first images that appeared on the screen without scrolling.

However, I later found out that as part of the changes I made, I had changed my image code from <CachedImage> to <Image>. This meant that I was no longer using the nuget package to show the images, enabling me to just uninstall the nuget package.

Login- authentication.

I then had another look at authentication, one thing I would need to implement was to ensure that if a user had already authenticated and created account, then they would be redirected to the home page. I implemented this by adding a TwitterId to my user table, and getting the TwitterId when a user authenticated. Then, when the user created an account this would be added to the user table alongside the other user details. After this was implemented I added a check prior to the redirect to see if the user with that Twitter Id had an account and if so it would redirect to the home page so that the user didn’t have to create an account.

Looking at the ratings.csv file.

After this I started thinking about the AI recommendation system. I would need to implement three separate algorithms.

• The first would show the top rated books regardless of genre. This would show if a user hadn’t selected a favourite genre.
• The second would show the top rated books in that genre.
• The third would show books similar to other books that have been rated by the user in terms of genre, this would then be ordered by rating.

For this I would need to use the ratings.csv file. However, this consisted of every rating in the dataset, I originally thought that I would have to count the number of ratings and calculate the mean. However, upon closer inspection of the books.csv file, I realised that it contained an average rating and number of ratings, meaning that I just had to re-import that file into the database.

I then realised that in the original books.csv file, there were two fields that would show the average rating and the number of ratings. I deleted my current books table, and re-imported it including these tables. This would later help me when working on the recommendation system.

Friday (22/03/2018).

Create an account page.

On Friday, I continued to work on the Current Account page in preparation for the recommendation system. The first thing I had to do was to add a provider type table to the database. This would contain two fields, one for Twitter and one for Google which are the authentication methods used for the app. I would then need to add a provider type ID and a provider ID to the username, this would ensure that if two people had the same provider ID they would have different provider type ID. I had previously been using a Twitter ID, this was renamed to provider ID, which could be used to refer to a Google ID or Twitter ID.

I also added a provider type constants class to my project, to avoid using hard-coded strings into my project. I then updated my code so that it checked that the provider ID already existed instead of the Twitter ID, prior to redirecting to either the create account or home screen.

I then changed the get all libraries method to get all those libraries and sort them alphabetically. And, I updated the database so that the id’s corresponded with those associated with the dropdowns. After this I tested that the right library was getting set upon save.

I then needed to ensure that the current user was accessible on all the different pages, I found that by using app.current.properties[“id”] I could save an ID which would be accessible on all the pages (link). I then added a line of code to ensure that the library card number of the current user was getting set to the id, which would mean I could get information specific to that user on other pages easily.