Skip to content

Latest commit

 

History

History
139 lines (118 loc) · 8.48 KB

D4.md

File metadata and controls

139 lines (118 loc) · 8.48 KB

D.4 Implementation 1

Introduction

  • The "Project Calandar" Project aims to give the user a way to track their daily activities and whether or not they are complete. The system enables users to create a calendar for an activity, and populates a calendar for it. The calendar shows a monthly view, and when a day is clicked the user has the option of selecting if they have completed, not completed, or if they want to clear it for that day. Their responses are stored on a remote server and loaded into the application at start up.
  • Value Proposition:
    • "Project Calandar" Project is a free calendar app that helps users track habits and routines on a daily basis. Individuals can track their workout routines, eating habits, smoking habits, and other habits in a visual way which provides the individual with instant feedback. This gives the user gratification and motivation to continue keeping up with their habits. Our product is unique in that the user of the app can extensively customize the colors of the app's user interface and receive reminders about their habits.
  • Found on:

Implemented Requirements

  • Use cases:

    • Create calendar for activity - Calvin, Zach
    • Mark a day in the calendar as completed or incomplete - Logan
    • View tracking summary - Trevor

  • MVP Requirements:

    • A view of one full calendar - Calvin, Zach, Logan
    • Create a popup when the user clicks on a day - Calvin
    • Make and parse JSON objects from get request to load them into the calendar - Calvin
    • Make put requests to update the calendar database - Calvin
    • An activity with an associated color - Adam
    • Syncing calendar with the server - Adam, Kadan
    • Accessable summary view - Trevor

  • Overall coding breakdown:

    • Adam - All CSV and database classes and controllers, server-side activity class
    • Kadan - Server-side month, day, and calendar classes
    • Trevor - Summary class and controller
    • Calvin - Main menu class, http request handling, popup menu
    • Zach - App-side calendar, month, and day classes
    • Logan - App-side activity class

Adopted Technologies

Android Studio (Front End)
  • What is it?
    • Official IDE for Android Development
    • Based on IntelliJ IDEA
    • Gradle-based build system
  • Why did we choose it?
    • Android platform is easier to work with than Apple/Xcode
    • Built in compiler (Xcode requires a build stage)
    • Primarily Java based
      • Comfortable language choice for the group
    • XML very similar to HTML

Spring Boot (Back End)

  • What is it?
    • Open source framework
    • Built on top of the Spring Framework
    • Includes dependencies to shorten code length and simplifying Spring set up
    • Allows development of enterprise-class applications
    • Utilizes the Tomcat servlet container
  • Why did we choose it?
    • Website packages all dependencies into a zip file making set up very easy
    • Industry professional recommended it for our application
    • Extensive documentation and reference material available online

Gradle

  • What is it?
    • An automated build tool
    • Runs automated tests
  • Why did we choose it?
    • Built into Android Studio
    • Automatic with Android Studio

Maven

  • What is it?
    • Maven is an automated build ssytem
    • Simple way to build and test executables
  • Why did we choose it?
    • To learn multiple technologies (in addition to Gradle
    • Simple to use for our requirements
    • Easy to deploy executable
    • Integration with Spring)

Learning/Training

To Learn:

Each side of this project (front-end/back-end) had one major developmental tool to learn. The front-end had to learn the tricks of Android Studio, while the back-end had to learn Spring. To learn Android Studio and XML to create the feeling and user-interface of the app, we looked up a bunch of examples for parts that we wished to implement. For example, to lay the buttons out in the way that we wanted, we looked for examples online for how to create buttons. For the back-end, we were fortunate in our learning experience. We had the ability to contact a software engineer who used Spring on a daily basis, and they were generous enough to give an overview on the tool. Since that overview, we have continued to revieve assistance from them. Outside of their help, we have used Spring's own resources to further our learning.

To Train:

We split our group into two groups of three, which each group focusing on one half of the project. To bring the other half up to speed, we did a q&a during one of our weekly meetings. During this time, we each presented the code we wrote, describing how things work and why. Then everyone else asked questions, which were answered by the presenter and other members of the group. This helped concrete the knowledge for the presenter, and built an understanding for the rest of the group.

Deployment

Licensing

GNU License:

We chose a GNU license so people can do a lot of things to our project for the most part, we just do not want people distributing the project.
We want to make sure people can still do stuff with our project without profitting from it

Readme File

  • Create readme file with a bunch of stuff

Look & Feel

  • Approach used to design user interface
    • Feel
      • We strived to create a simplistic and familiar user interface for our app. The app makes use of one menu screen where the user is prompted to enter the name of their first calendar. Once the user enters the name of their app they click a button to create their calandar and then they click a second button to confirm the name of their calendar. This menu is designed to be self explanatory and prevents the user from entering a name they don't want.
      • Once the user enters the name of their calendar the app transitions to the calendar view. From this view the user can click on any day in the calandar where they can then select whether they completed their activity on that day. The user is prompted with a popup with three buttons which are named in a way to make their functions obvious to the user. Once the user marks the day in the calendar the popup goes away and no input is required from the user.
    • Look
      • The colors for each of the UI elements in our app were choosen for their simplicity and minimalism. We wanted a clean and refined look for our calendar which we achieved with the small amount of colors used. The colors associated with activity completion are red and green. They were chosen because they commonly represent good and bad which should be intuitive for most people when trying to differentiate between completion and non completion of an activity.

Lessons Learned

  • What did we learn during the first release

    • How to implement a java-based sever
    • How to create an android app using android studio.
    • How to make HTTP requests (GET, PUT, POST) through an android application.
    • How to respond to HTTP requests (GET, PUT, POST) through a server.
    • How to communicate between a server and a web application
    • Packaging and distribution of a server
    • How to use the spring BOOT API to create a server that communicates with an android application.

  • What can we improve on for the second release

    • Spend more time speaking with the group about the basic functionality of our app to ensure each group member is on the same page.
    • Spend more time planning the architecture of our app before dispersing the group to start creating it.
    • Discuss solutions before coding them.

Main Menu
Calendar View

Demo