Major Project Blog


Introduction

This blog will document my progress throughout the next 3 months as I work on my Major Project: 'Android App for Local Taxi Bookings'. The purpose of the app is to behave as an intermediary between local taxi companies and their customers. It will provide features such as taxi tracking, booking status view and automatic booking delegation. For more information see the Project Outline Document below. I will be using aspects of the Extreme Programming software development methodology to develop this application. The blog will be updated Friday each week with a summary of the work done that week and what I hope to accomplish in the coming week.

Week 8 - Booking Overview and Cancellation, Booking History, Networking Refactor and Change Password

The main tasks to complete this week involved booking viewing, cancellation, booking history, some refactoring for the app's networking and support for changina password. In order to support the booking view some changes had to be made both to the API and to the android views. Since we're approaching the final weeks of development for the project, this will be the first of a few long blog posts (sorry).

/users/{id}/bookings Route

In order to support the viewing of bookings on the app I implemented a new route on the API to return a populated list of all of the user's bookings. This included creating unit tests etc for the new route. Through the use of this route all of the user's bookings can be viewed (history screen), however, it also allows the retrieval of the user's most recent booking using query parameters.

Booking Overview Screen and Booking Cancellation

The main bulk of this week's work was to properly implement the booking overview screen, this involved refactoring the app's networking module to conform to the MVVM design pattern, I also implemented view models for users and bookings. Due to the dynamic nature of the booking JSON response, I also had to create a custom GSON Deserializer. A SwipeRefreshLayout was used to support refreshing the booking overview. Implementing the booking cancellation was fairly straight forward and simply involved adding a confirmation dialog and sending a PUT request to the API to change the status.

The boooking overview fragment and view was designed to be very portable, allowing the fragment to be used to display a booking by specific ID. This is particularly handy for the booking higstory list, allowing an entry to be clicked and display an overview of the booking.

Network Refactoring

Although a fairly minor bit of work, it might be worth a mention. Given that most interaction with the API so far had been relatively one-way, with POST and PUT requests. When it came time to add support for retrieval of a lot of data, I felt it was time to revise the app's consumption of the API. Therefore I created View Models for the user and booking models, allowing the app to conform to the MVVM design pattern. I also made use of Android's Data Binding Library to push data to the views, this was particularly useful when implementing the booking history...

Booking History

Although there was quite a bit of work to be done to implement the viewing of a user's booking history, a lot of the implementation was boilerplate. For example, creating the RecyclerView and its adapter was fairly straightforward, given that I had implemented a similar recycler view in a previous Android assignment. This implementation was made even easier through the use of the view model, meaning access to the actual backend data had a layer of abstraction. Once again I used a SwipeRefreshLayout to support refreshing the list, however, there was an animation issue with refreshing. Due to the changing nature of each booking entry's ID within the list, there was an unpleasant 'blinking' effect whenever the list was refreshed. To address this I had to create a mechanism for the list to apply a unique integer ID to each booking, to avoid needing to create a second unique ID (alongside MongoDB's object ID) for each booking. I simply converted the mongoDB object ID to a long by getting the ASCII values of each character and creating a (very very) long number.

In addition to the actual list of bookings I also added support for clicking a specific entry and viewing that particular booking's contents. This was fairly straightforward, I just had to create an activity with a custom toolbar (as seen previously in other activities) and populate the activity with a Booking Overview Fragment. And of course, pass the booking's object ID to the fragment so it could retrieve the booking's info from the API.

Changing Password

Last week I added support within the app for changing full name, as support for this had existed in the API since nearly the beginning. I also created UI support for changing password, however, the API lacked the support for confirming the user's old password. Therefore this week, I decided to quickly implement this support in the API whilst I was adding the new route mentioned earlier in this post.

To Do

In the coming week I will tackle the following:

  • Implement the Home Screen of the App
  • Implement a Push Notification Mechanism
  • Begin supporting Drivers within the app

Week 7 - Booking Creation, Account Management, Landscape Orientation and Welsh Language Support

This week's main focus was implementing booking creation and adding support for various account actions. Although I had hoped to get started on the booking overview page, I decided it was best to spend extra time polishing the booking creation screen (fancier dialogs and confirmation etc.).

Booking Creation

I was able to fully implement bookings in the server side and push release 0.2 of the API in the first half of the week. This includes support for creation, updating and retrieval of bookings (and unit tests for all routes). Once the API support had been tested and documented, I created the UI skeleton for the booking creation Activity. In order to get the feature up and running in time for the mid-project demo, I hard-coded the time value and number of passengers. I then had to impmlement the Retrofit interface for all HTTP actions to do with the booking route. Error handling was much easier this time as I was able to make use of the generic error handling class I made in Week 5. The only thing to do was update the string resource file and error parse to support the 3 new error messages added.

Account Management

Becuase I had a bit of leftover time at the end of the week I decided to implement some of the dummy account actions in the 'Account' page of the app. This included an about screen, change name screen and change password screen. Although the change password screen isn't currently fully implemented as there is some API support that still needs to be created.

Support for Landscape

After implementing the booking creation activity I realised that I had been avoiding screen orientation throughout the project so far. I decided to remove the orientation lock from AndroidManifest.xml and see what kind of problems we had. It actually wasn't too bad, there were some UI issues here and there with non-scrolling forms; These were simple to address. I also decided that the account screen didn't make sense when in landscape so I created the layout-land resource file and created a custom view for landscape. Handling Asynchronous tasks together with screen orientation was where the headache started, if the activity was re-created any rxJava subscriptions would be binned and the progress indicator would dissapear. I opted for the lazy approach of simply locking the screen orientation whilst the HTTP request is in progress, although it's likely not ideal to block any kind of user interaction I'm already fading the whole screen with the progress indicator so why not?

Welsh Language Support

This bit only took me about 30 minutes one evening, I simply went through each entry in the 'strings' resource and translated it to Welsh (shamefully I had to use google translate for some words). Doing this highlighted some minor issues in the UI but nothing too major.

To Do

In the coming week I will tackle the following:

  • Implement Active Booking Overview
  • Implement Booking Cancelling
  • Implement Booking History
  • Look into / Prototype Push Notifications

Week 6 - API Deployment and Mid-Project Demo Prep

This week didn't involve much implementation (aside from some UI stuff on the Android front). I mainly focused on getting the API deployed to a remote server so that the app could be properly demonstrated from any device. I also worked on creating a plan for the mid project demonstration and what I would like to show.

API Deployment

In order to deploy the app I considered many options, I also needed to decide whether I should continue using Docker for deployment. Eventually, after experimentation with services such as Heroku, AWS EC2 etc. I decided it would be best to 'un-dockerize' the API for deployment, although docker is working excellently for me in development, I do not yet feel I have enough experience with it to use it safely in production. Therefore, I decided to deploy the API to a remote server of mine using PM2 and Nginx, PM2 is a NPM process manager that allows node applications to be ran as services and track their usages. I opted for NGINX due to its efficiency in serving static content and its support for rate limiting etc. In future deployments I would like to use a commercial VPS or one provided by the University for better SSL support and general security.

Mid-Project Demo Prep

Lastly, I needed to prepare for my Mid-Project demonstration on Monday. In preperation for this I first had to decide what I wanted to show. I would have liked to have booking creation fully implemented by now, but I got hit by a nasty cold at the start of the week so implementation was somewhat halted :(. Therefore I decided I would start the demonstration by showing the project's poster and some other visual aids whilst I describe the aims of the app and progress so far. I will then demonstrate use of the app (in its current form) and let the 2nd marker to have a go. Whilst I am demonstrating the app'suse I would like to have the database open in a terminal to show the CRUD operations live. Once I have demonstrated the app, I will show some of the UI prototypes I have drafted, along with my Release plan and trello board to discuss future plans and implementations.

To Do

In the coming week I will tackle the following (extra to catch up):

  • Do the mid-project demonstration
  • Implement Booking Creation
  • Implement the Account Management Aspects
  • Implement Booking View

Week 5 - API Testing and App Implementation

This week I worked on writing unit tests and documentation for all of the API routes. Once this was done I started work on the Android App itself, implementing the skeleton of the app's screens and navigation and adding support for authentication.

API Tests

In order to create automated tests for the API I used the Mocha testing environment along with the Chai assertation library and Chai-HTTP. For each route within the API there are roughly 4/5 tests, to ensure validation, authorization etc are working as expected. In addition to writing the API's Tests, I also documented each route for reference when implementing the android app's REST client support, the documentaiton can be found [HERE].

App Implementation

I made progress in two main areas of the app's implementation. The authorization screens (login and register) are fully implemented with support for error handling, client-side validation and token persistence. When the app's main activity is loaded, it checks if a token is present in the shared preferences if so, the app lets the user straight into the main activity of the app, if not, the app sends the user to log in. The app's error handling is able to parse the errors sent in HTTP to messages stored in the app's res/values/strings.xml file. This allows for easier localization / internationalization support for the app. If a user is authenticated successfully their non-sensitive information is persisted via the shared preferences, which allows for easy access of the user's ID, role and name for presentation and future API requests (which require a valid token). Future implementation in this area will involve allowing the user to make changes to their account, dealing with expired tokens correctly and implementing a 'remember me' functionality. I will also need to write unit tests for all of the above features.

In addition to implementing the app's authentication screens, I also created the app's main navigation and fragments. The app's main activity contains a Bottom Navigation View, that supports switching between fragments. There are currently 4 placeholder fragments, one of which contains a 'log out' button that simply deletes the contents of the shared preferences and forces the user back to the login screen.

To Do

In the coming week I will tackle the following:

  • Allow support for account management (update name and password)
  • Begin work on booking creation (both on the API and the App)
  • Look into deployment options for mid-project demo

Week 4 - Implementing Authentication API

The main focus of this week was developing the app's REST API, specifically, the authentication or user API. This includes adding support for registering new users, authenticating users and viewing users. I also set up the two git repositories needed for this project, one for the REST API and one for the Android App. This involved setting up the docker containers and travis CI tool to support various different environments.

Implementing the Authentication API

The main chunk of this week's work involved working on the app's API with all user actions, the spike work that I previously undertook helped a lot with this. The main tasks of implementing the API were to properly lay out the required routes, validate the input of the POST methods, handle errors correctly and set up the user's model and controller. The node.js project is split up into routes, controllers, models, middleware and services for each aspect (currently only user). In addition to implementing the routes, I also had to develop middleware to validate the HTTP requests, initially I planned on using a third party validator (express-validator) from npm. However, decided against this for simplicity and fine grain control over error management etc.

Setting up Docker Containers for MongoDB, Production and Testing

In order to have clear and separate environments for the app's testing and for it to run easily and be very portable, I created two docker containers. One for running the program normally, and another (which is built from the first) to run the mocha testing environment

Creating the Base Android Studio Project

In order to create the repository for the Android App I created a README file and a base Android Studio project with a hello world screen and proper colour variables. This is simply a placeholder ready for development of the app.

To Do

In the coming week I will tackle the following:

  • Create tests for authentication API
  • Develop a UI to support authentication/access control in the Android App
  • Implement Authentication within the Android App

Week 3 - Prototyping

This week was the first official week of the project's weekly cycles, (Release 1, Week 1). I focused on prototyping and spike work, I mainly worked on prototyping the app's authentication system and mobile UI.

Authentication Server Prototyping

In order to best estimate the effort required to implement the authentication server I prototyped a REST API with express.js, node.js and mongoDB. This process took roughly 2 days, however, I now have a functioning API to build on when developing the final system. I was also able to decide whether a third party authentication library or SDK would be more appropriate, for example Okta, Firebase or Passport.js etc. During this process I was also able to better understand the potential issues I would encounter when developing the authentication API. Such as, the challenges and pros of using token based authentication systems, the benefits of containerization, and methods for testing RESTful APIs.

Android REST Client Prototyping

In addition to prototyping a REST API for authentication, I also created a very basic android app that would serve as a REST client. This allowed me to guage the feasibility of a token based authentication system for mobile applications. It also allowed me to get a grasp of the technologies needed to make the application a REST client, these included rxJava and Retrofit. Although I have no previous experience with either, Retrofit was fairly easy to grasp and rxJava had similarities to Android's existing observable and lifecycle implementations. Creating this application confirmed my thinking that token based authentication was the most appropriate approach for this project.

Styleguide and UI Prototypes

The last task of the week was to create and evaluate UI prototypes of varying levels of fidelity. To begin with I used pen and paper to give the application a rough structure and get an idea of how I wanted the navigation to work, roughly what screens would be needed, etc. I then decided on a colour scheme and font style for the app, below is the colours I decided on.



Using the colours I had decided on I created a higher fidelity set of prototype stacks for all current functionalities of the app. This was done in Adobe XD, the prototypes are not interactive, however they appear in cronological order to display the intended flow of the app. During the creation of the I prototypes I asked friends for their opinion on various aspects. I found that showing them a given screen and giving them a scenario, then asking them how they would go about doing it using the UI gave me very valuable, reliable feedback on the success and usability of the design. These prototype stacks will be available in the project's repository when it is created (oops). A PDF with each screen can be found [HERE].

To Do

In the coming week I will tackle the following:

  • Create Git Repository for project
  • Begin implementing the authentication server
  • Begin implementing a skeleton for the android app's UI

Week 2 - Methodology, User Stories and Technologies

This week's focus was getting everything ready to start a weekly development cycle. Therefore, the first task for the week was to formalize my Methodology decision. As a result of this I produced the Methdology Outline Document. The next task was the one that consumed most of my allocated project time this week, I wrote up User Stories for each aspect of the overall system (see below):



Each User Story is written formally in the "as a (persona), I want (feature) so that (reason)" format, for each story there is also a set of acceptance criteria. Now that all stories were written up I could begin Release (or Quarterly Cycle) planning. The project is currently split up into 3 releases, each consisting of 3 weeks. From this week onwards this works out to the first release being ready just in time for the mid project demo and the final release being ready roughly two weeks before the final hand in. Currently I have allocated stories to each iteration in release 1, these are likely to be shuffled around depending on the progress that is made, these allocations can be seen in the Project Trello Page.

Lastly, I researched the various technologies that will be needed for this project, this includes development tools and third party libraries and frameworks. I researched various Continuous Integration tools and eventually decided on Travis-CI, I made this decision because it seems like the easiest to learn, the fastest to set up and overall the most lightweight. It also integrates seamlessly with GitHub repositories. I also decided that I will be using the MEAN (MongoDB, Express.js, Angular and Node.js) stack for the web and server based aspects of the project. In addition to Node.js and Express.js I will use a third party authentication library such as Okta or Passport.js. I will also use Docker to containerize the serverside software.

To Do

In the coming week I will try to tackle the following tasks:

  • Create UI Prototype Stacks for the App
  • Evaluate and gather user feedback on the UI Prototypes
  • Undertake spike work on the app's authentication service
  • Set up the project's GitHub Repository
  • Implement Authentication System

Week 1 - Project Outline Document and Gearing Up

This week was week 1/12 of the Major Project. I mainly focused on writing the Project Outline Document, this document got me to focus on what exactly this project is. What purpose does the project serve? What are the goals of the project? Who is the project for? All these questions are answered in the first section of the document. It also got me to create a clear breakdown of the tasks (at a high level) that need to be completed in the next 12 weeks, these tasks will allow me to prioritise and focus my efforts. In laying out the tasks, I also collected a fair few resources for my initial bibliography. These include tutorials and documentation for the tools/technologies I am considering for the project. This week I also decided on Extreme Programming (XP) as my chosen development methodology. It will be an altered version of Extreme Programming that is more focused towards individual work.

To Do

In the coming week I will try to tackle the following tasks:

  • Create story cards for each requirement
  • Look into, decide and start learning a CI tool to use in the project
  • Look into, and perhaps start learning Node.js, Express.js and MongoDB
  • Look into and learn to use a containerization system (likely docker?)
  • Start drafting a methodology and coding standards document