Warframe.NET
Warframe.NET copied to clipboard
Should we ignore some API properties like "asString" and "eta"?
Per the title, I wonder if we should just ignore some of the properties returned by the API. They seem to be generated by the data returned from the real Warframe API, and some of it really isn't needed as we can make it ourselves in the wrapper. This would reduce the clutter inside model classes like this:
[JsonProperty("eta")]
public string TimeRemainingString { get; private set; }
[JsonProperty("startString")]
public string TimeSinceStartString { get; private set; }
Thoughts?
Decided to go through and delete these properties, they're really just adding clutter to the models.
eta is an prediction for end time based on current running time, so i'd include those, and asString
are essentially the .toString()
outputs for several of them to give a simple format... I'd hardly call that "clutter"
By clutter I meant things that could easily be worked as an auto implemented property, such as the asString
property. However, I didn't know about the fact that eta
was a prediction so I will add it back. I might override ToString()
to replicate the asString
property.
I'll work on overriding ToString()
later.
Should ETA (property) be calculated if we knew the exact ETA (as DateTime
stored in another property, e.g. Activation, Expiry, etc.)? Time is always-running in real time so it doesn't make sense to store countdown as fixed String
s.
For example on Sortie
s, both Activation and Expiry exist as properties returning DateTime
; therefore, both "time since Sortie started" and "time until Sortie ends" can be calculated from DateTime.Now
.
Also I'd try not to use the phrase "ETA" when both start and end times are known, because the A in ETA can mean both (arrival vs. accomplish).
I just stored them since the API did, but yeah we could just calculate that in a property.
@VaslD the problem on invasions is that the "end" is not known, which i believe is the only usage of eta....