Movie Guide

Find movies you'll love



Our Vision

MovieGuide is a convenient place to find a personalized selection of movies. Our app will allow the user to get suggestions by filtering through using their preferences and information to present them a list of movies that they will love.

How does it Work

Movie Guide uses your quiz answers to search through hundreds of movies to find the ones that you'll enjoy the most


Why Use Movie Guide?

Think back to the last time you wanted to watch a movie but didn’t know what to watch. If you’re anything like me, you probably spent hours scrolling just to end up watching something you weren’t even interested in in the first place. Well look no further, I have the perfect app for you. Introducing the Movie Guide, this is an app designed to make your movie selection quick and easy. With a list of over 400 movies, this powerful app helps narrow down the selection using your own personal interests so that you never have to spend extra time looking for something to watch. If you’re unsure what you’re feeling one day, you can take a simple quiz that takes less then 5 minutes to complete which will find a small selection of movies tailored to your answers. All movies also provide information on the selected movie such as rating and summary. Download the Movie Guide now and never worry about what you’re going to watch ever again!


Try out the app!

Make sure you've installed Android Studio and click here, then follow the instructions.



Features


Quiz

This is a short movie preference test that will help recommend movies based on your personal interests.

Movie list

A list of over 400 movies for you to choose from.

Search

This will help you find a movie based on the title of the movie or the genre.

Filter

his will help narrow down the search function with more specific inputs such as year created, country made, movie rating, and movie score.

Login

Create an account and login to save your genre preferences and be greeted with a personal homepage."






The Team



Mohammadafaz Munshi

Afaz worked with all three layers of the architecture: UI, logic, and Querying the Database. It is amusing how one can integrate other people’s work to develop their features. He learned various UI aspects like using different Layouts and constraints, passing data between activities, etc. One of the course concepts that he found really useful was technical debt, one must keep this in mind while working on the project to avoid pushing release dates.



Thomas Peters

Thomas learned how to deal with large datasets when generating the randomized data of over 400 movies in the database. There were many times were they had to help out a teammate by helping find bugs, SOLID violations, and any random tasks that popped up and needed to get done



Mostafa Raad

Testing had been a very unknown software aspect for all of us to the date before this course. So throughout this project, Mostafa tried to bolster overall team confidence by doing the critical part which happened to set up tools' environments to do testing. Different libraries such as Mockito, Junit and Espresso helped us simplify our tests. While working with such a lovely team, I did get chances to hone my skills in overly interesting areas which are Database implementation and UI in Android studio especially did enjoy playing with spring and strut.



Nathan Gagné

Nathan took charge of the database and gained experience working with HSQLDB. At first, working with UI was their biggest challenge as they were not familiar with Android Studio before this project. With the support of their group members, they became better versed in the fundamentals of software development.



Chandra Hofer

Making the ground work for the apps UI in the logic layer and the presentation layer of the project and handling secretarial duties. Development skills gained during this class would be working with Android studios to make a multi-activity app and how to communicate data through all activities.



Brian lim

Working with Android Studio, Brian was able to develop skills in different UI implementations such as the dropdown view. As time went on and they got more familiar with software development, they were able to better sniff out smelly code and become better at recognizing SOLID violations.



Velocity Chart


What the chart means

As is clear from the chart above, our estimates got better through the course. The estimate for iteration 1 that was wildly off can be explained by the fact that we were inexperienced when it came to estimating how long a single feature would take to implement. Now that we have implemented some basic building blocks of an Android app from the ground up, we have a better idea of how long things take. We overestimated the time setting up a database would take, among other things. The much more accurate estimate of iteration 3 is due to the fact that we had a very good idea of what was left to be done and had gauged how long certain types of features take.


Improvements since our Iteration 2 Retrospective

• Finishing nearly all aspects of the project days before the deadline.
• Moving minor features to a “future” iteration to reduce the scope of the project.
• Removing unused elements of the database.
• Adding a SearchPreferences object to keep track of query parameters between activities.
• Removing unused commented code.
• Paying off more technical debt.


The Ups and Downs

The Positives

• Over the course of the project, we developed a good rapport as a team that allowed us to work together more efficiently.
• We were consistently impressed by the quality of the contributions of all members.
• Communication was encouraged and facilitated by keeping a central chat where everyone could give updates and share information.
• Where some group members struggled with certain aspects of the project, others were able to take charge.

The Negatives

• Emphasis on testing was not as strong as it could have been.
• Some work was left to the last minute on submission dates.
• Paying off reckless technical debt caused some issues in the second half of the project.
• Rare examples of miscommunication led to lost marks. For example, only certain group members knew that a certain class caused all tests with that code in it to fail, which resulted in unnoticed failed tests in our iteration 2 submission.


Postmortem

What took the most time? The least? Any surprises?

During the development of our project, the database was the hardest thing to implement and took the most amount of time. The database being one of the main components of the project led to a lot of bugs/issues during development. Specifically, we had significant technical debt because we implemented a real database using SQLite in Iteration 1. Later, we found out that it was too highly coupled with Android context and with code that is not completely based in Java. Paying off this debt at the beginning of iteration 2 caused some time and resources that could have been used towards adding new features to be spent elsewhere. Creating the UI for many of the activities did not require as much time as we expected. Although the unfamiliarity of Android Studio caused some issues in the beginning, as group members became more familiar with the IDE, the development became a lot smoother and less time consuming. Members were better able to contribute to parts of the project others worked on as everyone became more comfortable with Android Studio, leading to a more seamless/cohesive development process.

How did the project change from your initial (iteration 0) vision or stories, or did it work out as predicted?

The project had to change from our initial vision at iteration 0 due to various factors. We are all students taking many classes and have a limited amount of hours to dedicate to a project like this. We were ambitious during the planning phase and created 13 feature issues. The scope creep of certain features became apparent near the end of Iteration 3 and we decided it was more prudent to move the remaining low-priority features to a “Future” milestone. This allowed us to spend more time polishing the current state of our application and writing the required tests. Some of these low-priority features that we mentioned in the vision statement would have taken many more work hours than we had access to. In particular, the watchlist, sharing to social media, and the ability to upvote and downvote movies have all been pushed to a future milestone. The search feature also became a larger part of the application during the course of development, so the usage of our application after iteration 3 is largely focused on having a database of fake movies that can be filtered by using various attributes or by searching by name.

What did you learn about team or large project development? What will you start doing, keep doing, or stop doing next time?

We learned that communication is the most important aspect of project development. Also, for efficient collaboration, version control needs to be continuous and consistent using a centralized repository where people can push the code that they worked on individually. Next time, we will start to ensure that the code we write for new features is as lowly coupled as possible so that merge conflicts are easier to fix. We will also plan every user story and dev task at the beginning of the iteration and avoid deviating from that plan. During the iteration, we will properly track the amount of time spent on each dev task. We will also write tests while we are implementing new user stories/features instead of waiting until the end of an iteration. We will keep dividing tasks amongst group members and holding weekly meetings to keep track of progress on various features and offer support to other team members.