# Product Code Report

This is a quick practical report about the current status of the project. The main purpose is to inform Jumpseller about how the LGP team left the project and list the known problems, bugs and improvements to the product in order to make it "market-ready".

We imagine that the project will go under major refactoring after LPG.

# Known Bugs

As said above: given that Jumpseller might refactor a lot of code there are some minor bugs that we will don't feel that are worth writing here.

We'll just note two that we found late in the App.

### App sending data twice when coming from background

**Steps to reproduce:**
1. Select any order for the delivery
2. Tap an order on the map and start delivering it (or on the Order List).
3. Tap the home button to send the app to the background.
4. At this point the app will continue to send information.
5. Open the app again.

**Actual result:** The App sends the information about the location/order twice to the backend.

**Expected Result:** The App should send it only once.

**Suggestion:** It might be related to the subscription made when the app comes to the foreground.

### Map not moving when taping the "center map" button

**Steps to reproduce:**
1. Select any order for the delivery
2. Move the map view away from courier current location.
3. Tap the center button

**Actual result:** The map doesn't move.

**Expected Result:** The map should center in the Courier's location

**Reason:** This happens because the position of the courier in the emulator is exactly the same if not moving. This package requires the position to be different for it center again.

We think in a real world situation this will not happen because the position/accuracy is always changing.

**Sugestion:** Edit manually the package. There is also a sugestion on how to fix this problem in the branch `lgp-core-fix-center-button-sugestion`.However, it is still not ideal given that it has a slight delay between the zoom adjustments and center map movements.

# Suggestions

Some suggestions for future features were [already mentioned in the Trello](
https://trello.com/b/SaP2sfHR/lgp4-big-data-real-time-gps-data-presenter).

However, we'll list the ones we feel are the most important at the moment:
## App-side

### Check if GPS or Internet connection is up

We tried to render an Alert component over the Map but it wasn't happening for some reason. We suspect it was because of the map package we were using (check the below for reasons why).

It would be nice for the Courier to receive a alert recommending him to turn on at least the GPS on his phone.

### Change the App Map Provider

We used a [Webview from Leaflet](https://github.com/reggie3/react-native-webview-leaflet) because it's you are using Leaflet on the website (when seeing an order in the admin page). From our limited search, we found that the web version of Leaflet has more features than the mobile webview, so it's not a solution we would recommend for the future.

**Main Problems:**
- The Markers behave weirdly and are not very customizable (the mapMarkers are HTMLElements and there's no HTMLElements in React Native. Maybe in React.js)
- Hard to display other elements on top of it (like an Alert).
- Depends on expo modules.
- Unintuitive to debug: it simply doesn't render if any props or marker is missing/bad formatted.
- Zoom and moving the map is not reliable and forces a lot of re-renders on the component.
- Markers disappear when not in frame and might take a while to display again.

**Our recommendation:** Consider Google Maps. Uber and Globo use it for their delivery services.

### Dynamic Zoom on the Map

Even though the map will serve as a "guideline" for the courier and not be use for actual delivers. It would be great it, after selecting and confirnm the orders, the map would frame all the orders and the courier position, so that the courier could view immediatly here the destinations are located.

At the moment the map open with a fixed zoom on the courier's position. But with the orders coordinates (and calculatin the distance) it would be easy to achieve. Tbd with the UX department.

### Admin / Courier User Accounts

This was discussed during our meetings.

This also can be integrated in a future *delivery history* feature.

### Sending extra data to the server

We are only sending the orderID and the location at the moment. There's no unique paramenter in the message that validates the courier or the orders.

For this app to be of any real value it should send a timestamp as well. That would avoid late packages or delays during the data transfer that could cause the courier position in the map to jitter.

It should also send something like a "Courier Token", that would validate the identity of the courier.

### Use AsyncStorage to save a delivery status if the app crashes.

Right now the app starts a new delivery process when tapping the "Delivery" on the Drawer. For the MVP this is "ok" but for real-world usage it's not ideal.

We've started a branch called `lgp-core-dev-resume-trip-feature`. However since the app might need major refactoring we didn't made further progress on it.

Something similar to this when trying to start a new delivery.

<div align="center">
<img src="https://i.imgur.com/09O46SK.png" height="400">
</div>

**This should use also Server data to verify any active delivery**

### Use React-Native-Keychain instead of AsyncStorage to save credentials

Lately Apple has been harsh on apps that use *AsyncStorage* to save tokens or credentials since it store information as plain text. Apple has different policies for apps that deal with payments, but since there's no payments on this app it might get away with it.

Here's the link for the npm page: https://www.npmjs.com/package/react-native-keychain

## Server-side

### Use Another Map provider

From what we've search, for road-snapping and map display using Google Maps is probably the safest solution. It is both a proven solution with a lot of features and with a lot of available support.

### Mobile View

We only did a desktop layout for showing the map to the final client. A mobile layout has been a must for many years now.

### Refactor how the data will be store in DynamoDB

The wiki we created with the specification of the communication protocols, as well as permanent storage strategy contains our rationale behind these design decisions. However, further care must be taken in order to make sure that 1) it's most efficient way to store and 2) nothing is missing.

### Architectural change

Websockets was enough for an Minimum Value Product/Proof of Concept. However we were not able to test the performance and viability in a real world, large scale scenario. In case the performance isn't up to par, we recommend other solutions like [Apache Kafka](https://kafka.apache.org/) or [Amazon Kinesis](https://aws.amazon.com/kinesis/).

## Project Suggestions

These are general ideas targetted at the project scope. More of them can be found in Trello.

**Information about the Package type:** A Courier delivering food would like to know if he's something fragile, p.e.)

**Brower Push notifications**: Might be helpful for the final Client.

**Automatic prompt Courier when near destination**: A "confirm delivery" prompt should appear when the courier is near the destination.

**Delivery Notes**: Delivery notes such as "Delivery at 9:00 - 13:00 if possible" or "leave the package with my grandma" or even "Avoid this street cause it's problematic" would be helpful.

-----

Created in 28 May 2021
Platypus, Team B