pargi / pargi-ios Goto Github PK

Based on design done in #4, implement the view.

Requirements

1. The view shows the car that was parked
2. The view shows the zone in which the car was parked
3. The view shows the drive button that ends the parking (by calling the appropriate number)
4. The view shows information related to the parking "session" (the duration and expected cost)
5. The view continues to show the map, however, user interaction should be disabled. User's current location should be shown, as well as the location of the parked car. This will require changing the state that is stored to also include the location of the car.
6. OPTIONAL: If possible, the map should show walking directions to the car.

As an ideal companion, Pargi could have an extension on Apple Watch that would give a quick overview of the current parking session and allow you to end it. Similarly, it could be a nice way of starting parking with saved license plate and the "most likely zone". If the goal is to shorten the time it takes to pay for parking, doing it from your wrist with a single tap would be the ultimate solution.

Expected result

This task should culminate in ideas for interactions that a Watch OS extension could surface for Pargi. Ideally, these ideas would be formed as specific feature requests that also include wireframes/screenshots/mockups. These requests should be issues on this repository.

Once the app has started parking, we should show a view that has the following information on it:

1. The zone that you are parked in
2. The car you parked
3. The duration of the parking
4. The estimated cost of the parking
5. Button for ending the parking (which will make the phone call to end the parking)
6. OPTIONAL: Show a map with walking(!) directions from your current location to the spot you parked your car at. This would mean that we would need to also capture the parking location.

Expected result

Expected result of this task/issue is to come up with a proposed design (level of detail does not matter) for the view. It should take into account the requirements, as well as the logical layout of the app. One possible solution would be to repurpose the "drawer" that is currently on the main view, simply replacing the contents. Another possible solution would be to push a completely new view as a modal.

This task is not expected to result in concrete technical proposal, rather, should think through how the interactions of the app should be and what the user flow should be. Ideally, this would all culminate with either a wireframe or a sketch, which could then be turned into a fully-fledged design in the app.

When the pre-conditions are met and the user taps on the Park button, the app should open the SMS composer with the pre-composed message body and recipient number.

Requirements

1. Park button can only be pressed when both a zone has been selected as well as a license plate is entered (already implemented)
2. App opens the SMS composer on button press, with correct phone number and message body. (The phone number to start the parking on is 1902)
3. App composes the message body using the correct format. (license-plate<space>zone-code, for example 123ABC EP1)
4. App observes the callback from the SMS composer, and exposes success/failure internally (so that the "parked" state view can be pushed when added later).

Technical requirements

1. This code SHOULD be implemented in MainViewController.swift, which means the action of tapping the button has to likely be exposed as a delegate function from DetailViewController.swift. This is to make sure all business-logic is in, and only in, MainViewController.swift and all other controllers remain clean (meaning easily testable).
2. If successfully sent, the parking state should be captured. UserData.swift exposes some persisted values for storing parking state.

Currently, MapViewController either tracks the user location (i.e changes the region to keep the user location centered) or not, based on a flag - trackUserLocation. This should however, change dynamically based on how the user interacts with the map.

Expected result

1. By default the map view tracks user location, however, if the user drags the map with their finger (i.e changes the region themselves), then the automatic tracking should be turned off (in order to stay where-ever the user pointed us to).
2. When the user-tracking is turned off, the map view should enable a button that can be used to re-center the view on the user location and re-enable user-location tracking. Icon for said button is Assets/Locate (placement should roughly match what Maps does in iOS, see screenshot)
3. If the user re-enables user-location tracking, then the re-centering button is disabled.

References

Apple Maps has buttons in the top right corner of the map view, the button for re-enabling user-location tracking in Pargi should feel similar (but use a different icon, unless you are able to find the correct asset). In our case, it makes more sense to have the icon in bottom-right (reach zone of the thumb) as that way the interaction is faster with the app.

Attached a screenshot for reference.

The "Park" button due to its custom nature has a weird highlighted state, where the text is the same exact colour as the background colour is. The text should be inverted (be white) when the button is highlighted

Steps to reproduce

1. Have a zone selected
2. Have a license plate entered
3. Hold your finger on the Park button

Expected result

The Park button has white text and blue background

Actual result

The Park button text is the same colour as the background.

Attached a screenshot with the current result

Currently, the elapsed time of parking is only shown in the partially visible version of the drawer in parked view. Modify the drawer contents in a way, where a shorthand version is visible inline with the Drive button.

The proposed design would put the drive button on the right (similarly to the Park button) and on the left would have a single text label with duration and estimated cost. This would not affect the contents of the drawer. The elapsed time would not have a descriptive label next to it, just the formatted duration (i.e "1h 20m")

While currently the logic for determining the likeliest parking zone is based purely on distance, we could in the future use popularity as a metric as well (especially for zones that are really close by). In order to even plan doing something like this, we should start capturing usage data as soon as possible.

Expected result

This task should produce further issues on this repository that do the following:

1. Propose a backend solution for collecting/storing data that is either free or cheap.
2. Propose a collection method for the iOS app that anonymises the usage data and is safe (i.e no HTTP, only HTTPS and not using some incredibly invasive libraries).

Get the following error:

import Cereal -> Module compiled with Swift 3.1 cannot be imported in Swift 4.0.

If the map is still centering on location, button to start parking does not respond, even if the zone has been found and is available.

Currently, the app does not notify users of ongoing parking, this was a nice feature of the old version that should be reintroduced in some clever way.

The old approach was very manual, it had a few buttons and a settings option that controlled it, but nothing else, this wasn't particularly good (default values should be so good that you wouldn't need to fiddle with buttons).

Requirements

• Add back the time based notifications, with time interval at 1h and going up to 4h
• Add a geofence based notification, with the distance at 1km
• Both of these should be enabled by default. The geofence should be smart enough not to active if the user disallowed background location usage for the app.