Skip to content

stephaneK123/weatherNotification

Repository files navigation

weatherNotification:calling:

A wise men once said:

If you can’t explain it to a six-year-old, you don’t understand it yourself:stuck_out_tongue:.

What is included in the README:

  1. General Info
    • Why the project exists
    • A demo of the project
    • What is the project
    • How the project is meant to be used
    • Progress
  2. Expetation from Authors
    • How to work on the project
    • Writing readable code
    • Communication
    • Testing
  3. List of Authors
    • A list of all the authors 😍
  4. License & copyright
    • Typical we will sue if you do this blablahblah.

◀️General Info

Why the project exists

This is a final project for a class. The task is to write and present a full Android Application. The deadline is 7 weeks.

Demo

Here's a quick demo of the project, it may become outdated at some point in the future.

What is the project

Our project is to write a weather alerting app that uses the openweather api to notify the user (through android notifications) about certain weather changes. These changes could by anything, with examples being:

  • Hurricane or flood alerts
  • Humidity above 65%
  • Tempature above 65F
  • Incoming snowfall expected
  • Sky will be clear (go outside loser)

How is the project meant to be used

The project is meant to be used to gain experience with Android Studio and app developement with a team. The app is meant to be used for education purpose and as a reflect of past accomplishment. The app is meant as a learning experience, and therefor could have a few to a bunch of mistakes.

Progress

This is the list of tasks to have to be compled. The list will be update as need be and a ✔️ will be added once a task is completed.

Status Description Author Expected due Date
☑ Done Set up github and complete README StephaneK 3/23/21
☐ Done App story board Tom,Xavier 3/29/21
☐ Done Project Plan n/a 4/2/21
☐ Done Project Update I n/a 4/5/21
☐ Done Project Update II n/a 4/12/21
☐ Done Project Update III n/a 4/26/21
☐ Done Project Update IV n/a 5/2/21
☐ Done Final Presentation n/a 5/13/21
☐ Done Final Project Delivery n/a 5/20/21

◀️Expectations from Authors

How to work on the project

Important :

  • The Master branch has the last FULLY (release ready) functional version of the app.
  • The testing branch has the the most up to date fully functional (not revised or tested) version of the app. (All three author branches merged into one).
  • The author branch has the respective author's most up to date version of the app with thier designated features (Working UI, improved version..).

It is important that everyone is on the same page. This github will be used for the production of the app and the final version will be on the Master branch. All the authors have their own seperate branch that they will work on actively. Once an author is done with their work they will commit to thier respective branch. Once enough progress has been made all the 3 branches will be merge to make a fully functional test branch. The test branch is meant to be used prior to the full merge into the Master branch.

Writing readable code

You are working as a team and not an individual. We can not read into your head and think how you think. It is important that you write clear and readable code. Here are things to keep in mind to make your code easier to understand

You are responsible for the quality  of your code 

#1: You're responsible for code quality. 

#2: Use meaningful names. 
int x = 0;? 
int timeLeft = 0; //better 

#3: Write code that expresses intent.
public void boo();? 
public void changeFormat(); //better and less comments 

#4: Code should speak for itself. Less comments = less maintenance. 
the code should be readable enough and the more comments the more time spent fixing 

#5: Leave the code better than you found it. 
if you see bad code, fix it

#6: Single-responsibility code. i.e function does 1 thing well. Less arguments = better function. 
classes: most methods use most of the class' properties.
do one thing, do it well and do it only 

#7: Tests (TDD). 
test driven development 

#8: Work on big picture skeleton, then fill in the details later (interface first, implementation later). 

#9: Independent components that can be used in different places.
things are not too attached to their environment
#10: Master your craft. SPEND TIME AND UNDERSTAND WHAT YOU ARE DOING AND WHY

Comunnication

You should be communicating with the team members to give update and ask for help. Everyone should be aware of who is doing what and when it is expected to be done. Everyone has a task but that does not mean tasks can not be switched or delayed. If you are struggling ask for help or go to google. You should be commeting on your commits and giving a brief description of what you did.

Testing

Your own branch does not need to be fully testing until all the three branches have made enoough progress to make a test branch. However, it is in your best effort to test your code as you write it to save time. It is okay to test your code after you've made enough progress. Your code should be tested and have as less bugs as possible proir to the team being ready to merge into the testing branch.


◀️List of Authors


◀️License & copyright

Education use only, may not be distrubuted for non-comercial use only ty :) © VTC, Vermont Technical College Williston 3/24/21

About

A weather alerting app made with Android.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages