muhammadaljunied
commented
4 years ago Team's Response
(Assuming you are testing this as a developer instead of the Target user as mentioned in the User Guide), in the scope of this project, with the restriction to minimize internet use, it would less ideal to store historial data as it would bloat the app with time (as detailed in the Cons, Aternative 2 of the design consideration in the Developer guide) The reason to not go ahead with storing historical data was to satisfy the primary MSS, which is to capture the expense with the present-day rate (this rate is stored together with the expense) at the point of entry to ensure that the rate used for computing the monetry value of the expense in will always be with respect to the exchange rate on the day it was added. In addition to this, rates are updated from a remote source every time the app is started, which ensures that the exchange rates used are always up to date before the user starts adding new expenses.
In an ideal scenario with no restriction on internet use, this problem can be easily resolved by querying for historical exchange rates should the expense be backdated at the point of entry.
For the scope of this app, it has been detailed that any expense that is backdated will still use the exchage rate at the time the expense was added and is a design choice
Duplicate status (if any):
--
The exchange rate data in exchangedata.json is only valid for 14/11/2019. Given the time-sensitive nature of exchange rates, it would seem that these rates would need to be updated and historical rates would need to be stored.
I don't quite understand this part of the developer guide.
[original: nus-cs2103-AY1920S1/pe-interim#54]