Fuel 0.9.21: Reminder Oddities

[ralf.keimer]

Hi Rob,

I am using Fuel 0.9.21 and played around with reminders.
I like very mutch, that you added reminder finished timestamp and
odometer
(Anticipating my longed for cost-statistics including repairs etc.).

So I added complete dates for my old reminders "posthum" in the
program on the palm.
I exported regularly to GoogleDocs. When I got confused and destroyed
some reminders,
I purged everything and reloaded GoogleDocs (btw. Complete Set).
Now I have the situation that all reminders are there, but their
complete date always shows the
today date. I can change and save to another date, but ultimately when
I reopen the reminder again date is today.
When I export to Google, the date seems to be the one I entered, but
I'm not 100% shure.

I'm not shure whether this is just a display glitch or another error.
BTW the CompleteSet Export is missing the location-presets.

Nonetheless keep up the good work!

Regards Ralf Keimer

[Rob (rbtwhiz)]

Hi, Ralf.

Indeed, the addition of Completion Date and Odometer to Reminder
records are a precursor to being able to provide a more complete view
of calculated summaries, including maintenance and repairs. In the
0.9.21 build, the Completion Date displayed in the Reminder scene is
dependent on whether the Completion Odometer also has a value. If the
Odometer field doesn't also have a value, the Date is set to the
"current" date of the device when you enter the scene because it
assumes that "completion" hasn't really occurred unless the Odometer
value is also specified; in which case it will display the Date
recorded. To be clear, the [imported] Date of the record doesn't
actually change unless you commit. It actually does all of this as a
convenience, to remove a step [of having to pick the date], but I see
how it may be confusing... so I'll consider changing it. I'm still
undecided at the moment.

I had thought to require a value for all Completion inputs when the
Mark As Completed toggle is on, much like the Constraints for Date and
Distance, but ran into a problematic scenario, so opted to hold off on
that until I've decided how to mitigate the fallout. The scenario I'm
talking about is one created by the fact that the Cost field has not
been a requirement; and so it is likely that there are records where
this value is undefined. What I'm leaning toward right now is
automatically inserting a default Cost of "0" if a previously captured
record doesn't specify a Cost of its own. I can do this at the
database level now, using the new data migration routines that were
added as part of the recent update, which means I'd be a step closer
to actually being able to calculate Summary data for these records;
because the assumption that each record has a value in the fields used
by the calculation would be a fairly safe one.

The reason I even concern myself with whether or not I can make "safe"
assumptions in these summaries is speed and battery life; the less
validation I have to do, the faster the app runs and the less cycles
it uses to do its work... which translates to longer battery life.

On Location Presets... these are actually intended to be separate from
a "Complete Set" because they are not tied to a specific vehicle.
"Complete Set" is in reference to the set of records that are
specifically tied to a vehicle; i.e. the Vehicle itself, Reminders,
Reminder Presets, Fueling Events and Trip Events (Plus). Location
Presets [and Rate Presets (Plus)] are a common type of record that are
available regardless of the vehicle, so it makes sense to Import/
Export them separately. I've actually been prototyping some UI changes
[in Ares] that make this [and a few other things] much more clear;
things that have become apparent as Plus continues to evolve.

As always, I appreciate the feedback.

-Rob

[ralf.keimer]

Hi Rob,

ah that clarifies the behaviour, I will test this.

On 7 Dez., 18:00, "Rob (rbtwhiz)" <rbtw...@gmail.com> wrote:
> Hi, Ralf.
>
> Indeed, the addition of Completion Date and Odometer to Reminder
> records are a precursor to being able to provide a more complete view
> of calculated summaries, including maintenance and repairs. In the
> 0.9.21 build, the Completion Date displayed in the Reminder scene is
> dependent on whether the Completion Odometer also has a value. If the
> Odometer field doesn't also have a value, the Date is set to the
> "current" date of the device when you enter the scene because it
> assumes that "completion" hasn't really occurred unless the Odometer
> value is also specified; in which case it will display the Date
> recorded. To be clear, the [imported] Date of the record doesn't
> actually change unless you commit. It actually does all of this as a
> convenience, to remove a step [of having to pick the date], but I see
> how it may be confusing... so I'll consider changing it. I'm still
> undecided at the moment.

I think, that mandatory complete dates should correspond to set
Contsraints,
so if You have a date and an odometer constraint, both should be
mandatory.
If just one constraint is set, this should be mandatory, for reminders
without constraints
setting either should be sufficient.

I don't know if this is sufficient.