Task 2 - financial app. CodeAcademy2

Task 2 - financial app

# CodePay - Project 2

# API

## Base URL for students

## Endpoints

### Search parameters

# UI

You're free to make any UI based on the requirements. You can use your favourite banking application as an inspiration.

# Scenes

Concrete error handling is not defined with each scene. Handle appropriate validation or network errors in the 
application by showing erros to user. 

## Login

Fields:
- Phone number
- Password
- Submit button

On Submit:
- Check if user with this phone number exists (/user)
- Check if password is correct (/user)
- GET /user/:id to get access token and its expiration. Save access token and expiration in the app. 
Renew (GET new one) when it expires

## Register

Fields:
- Phone number
- Password
- Confirm password
- Currency
- Submit button

On Submit:
- Create user (/user)
- Create account (/account)

## Home

When home screen opens, load current account transactions (where current account is sender or receiver) 
and related accounts from API and save to local storage.

Fields:
- Current account balance with currency
- Add money button
- Send Money button
- Settings button
- Transaction List (Shows 5 newest transactions loaded from local storage)
  - See all button

## Transaction List

Show all current account transactions loaded from local storage.

- Search field which filters transaction list based on input (by note, by phone number)
- Filter button
- Clear filter button (clears search and filter)

### Transaction Filter
- Date (range)
- Amount (range)
- Currency
- Outgoing or incoming transactions

## Transaction Info 

- Outgoing or incoming transaction
- Formatted date
- Sender phone number
- Receiver phone number
- Note (reference)
- Amount and currency
- Repeat button (Opens prefilled Send Money scene)

## Add Money

- Enter amount and PUT new balance (/account)

## Send Money

- Recepient phone number
- Prefill sender currency
- Add note (reference)
- Enter sum

Validation
- Check if recepient exists
- Check if recepient currency is equal to your currency
- Check if your sender balance is sufficient

After validation
- Create new trasaction and POST (/transaction)
- Change recepient Account balance and PUT (/account)
- Change sender Account balance and PUT (/account)

## Settings

- Update password (/user)
- Update currency (/account)
- Update phone number (first update /user, then update /account, then update locally saved information)

# Technical Requirements

## General
- This is your time to shine by writing as clean as you can
- Do not forget about Swift style guides (either Ray Wenderlich - https://github.com/raywenderlich/swift-style-guide
 or Google - https://google.github.io/swift/) 
- Use proper naming, code structure and spacing
- Do not forget about access control (`private`, `internal`, `public` etc.)
- Use subclassing, where it is relevant and needed
- Try to make your code easy to understand just by looking at it, avoid massive functions
- Try to think of all possible failure scenarios, so your application would be without any surprises if something 
goes wrong
- Use extensions, split huge functions into smaller ones (if possible, of course)
- When you finish some part of the functionality, take a look of what you have already written and check if you can
 refactor something and make it look cleaner
- Handle all the errors through the application - user should know if something goes wrong
- Differentiate between structs and classes by situation (do not mix them - use `struct` where struct is best, 
use `class` where class is best)
- Functions with clear purpose, without unexpected side-effects
- Use “weak” when needed

## Networking
- API layer should be separated from other parts of application
- Using `URLSession`, `Encodable`/`Decodable`
- Separate data structure for building endpoint URLs
- Using `URLQueryItems` to build URLs with query parameters
- Networking methods should provide both data and errors
- Error handling. API methods should always notify about its failures or successes
- Use PUT / GET / POST where appropriate

## Storage
- Storage layer should be separated from other parts of application
- Use `UserDefaults` and `CoreData`
  - Fetch and save transactions and accounts locally. Create relationship between transaction and account. 
In API, transaction keeps sender and receiver ids. In local storage, keep reference to sender and receiver 
accounts instead of ids. 

## UI
- Application should only support `Vertical` orientation
- Application should support all screen sizes, all required elements should fit
- Write UI programatically without `Xibs`, `Storyboards` or `SwiftUI`
- Use `UINavigationController` for navigating between scenes
- You can write progamatic UI constraints by using Apple methods or using `SnapKit` (or other 3rd party constraint 
wrapper library)
- Aim for consistent colors and consistent spacing
- All shared functionality between view controllers should be moved to parent view controller, which would be 
subclassed by child view controllers
- You can use https://icons8.com/ or any other icon website for images

# Evaluation

We will evaluate:

1. **User side** - we will be your application users and see if we can break them. We will check if everything 
works as expected, there are no unhandled scenarios, there are no crashes or other things that could affect user 
experience
2. **Code functionality** - this is similar to user functionality testing but this time we will go into your code 
and check if everything is handled correctly code-wise. We will check if you used appropriate things for specific 
tasks, if there are no loopholes, if everything is handled correctly etc. In other words, we will check how you 
implement requirements code-wise.
3. **Code cleanliness** - in this part we will check is your code clean. Do you split your functions, do you use 
extensions, if code is structured correctly, if you use proper naming, is styling okay etc.

# Deadline
The work needs to be sent as an archive to Arnas via Teams private message until **2021-05-16**