goalvc shows also a goal's rate #611
Conversation
krugerk
force-pushed
the
feature/557-show-the-goal-rate
branch
from
b7d855d to
f6f524f
Compare
| /// Unix timestamp (in seconds) of the goal date. | ||
| @NSManaged public var goalDateRaw: NSNumber? | ||
| /// Goal value — the number the bright red line will eventually reach. E.g., 70 kilograms. | ||
| @NSManaged public var goalValueRaw: NSNumber? |
There was a problem hiding this comment.
Let's work out how to do this without the Raw values and separate wrappers.
There was a problem hiding this comment.
As we know, the commitment dial allows specifying any two of the three. At the goal level, two of goalDate, goalVal, and rate will be defined and the other one null. It might be handy to have this as an enum or similar:
enum CommitmentType {
case targetValueAndDate
case targetValueAndRate
case targetDateAndRate
}And we would still need some transformer for storing such a thing in core data. I think though just for displaying the rate, the app does not really need to know which commitment type is in use. At least I checked on the Android app and that is what it seemed to me.
Goal.mathishard contains the three values, regardless of which two had been set via the commitment dial.
Using that I might have just gone with Double instead of NSNumber?. However, the api doc also mentions mathishard itself can be null and to handle this and use the fallbacks, any of which could be null, I went with the NSNumber?.
| if let calculatedGoalDateGoalValueAndGoalRate, calculatedGoalDateGoalValueAndGoalRate.count == 3 { | ||
| self.goalDate = calculatedGoalDateGoalValueAndGoalRate[0].doubleValue | ||
| self.goalValue = calculatedGoalDateGoalValueAndGoalRate[1].doubleValue | ||
| self.goalRate = calculatedGoalDateGoalValueAndGoalRate[2].doubleValue |
There was a problem hiding this comment.
The problem with this approach is what this is the rate for. From the docs:
rate (number): The slope of the (final section of the) bright red line.
This means it can easily not be the gradient for the graph section you are currently in. For that reason I think the due by table approach makes more sense.
There was a problem hiding this comment.
As is, it would show what the Android app shows.
|
I'm going to close this out because I think we should be exploring due by table approaches rather than this one. |
The Android App shows both the rates and the due-by table with its deltas. |
Summary
In its current form, the app neither shows the deltas/totals nor does it show a goal's rate. Thus it takes guess work from looking at the graph to determine how many units are needed for a number of safe days.
(Deltas in #547)
This is a basic implementation that shows the goal rate, consisting of gunits, rate, and gunits.
The three attributes have been added to the Goal model and to the definition for Core Data. A new label has been introduced on the goalvc, between the graph and the recent datapoints, showing the rate.
For UI changes including screenshots of before and after is great.
Validation
ran app in simulator
Issues
Fixes #557