Open AEFeinstein opened 10 years ago
Are we positive that simply converting a MTG single from a US Dollar price using an exchange rate is an accurate reflection of the card's price in the other currency?
I'd be interested in making this enhancement, but I'd like to know what the install base of this app looks like. Could you give me some numbers from your dashboard for installs by country?
We are not positive that a simple conversion is an accurate reflection, which is why issue #15 exists. There aren't many open data sources though. Below is the table of installs by country as of today:
Country | Users | Percentage |
---|---|---|
United States | 106,916 | 65.72% |
Canada | 10,217 | 6.28% |
United Kingdom | 5,122 | 3.15% |
Australia | 4,355 | 2.68% |
Brazil | 3,479 | 2.14% |
Germany | 2,646 | 1.63% |
Italy | 2,626 | 1.61% |
France | 2,042 | 1.26% |
Philippines | 1,838 | 1.13% |
Netherlands | 1,751 | 1.08% |
Others | 21,687 | 13.33% |
Hey guys, I'm a dev from Australia and I would be happy to lend a hand with this and possibly even price caching. What's the current status of this issue?
From what I've seen, doesn't look like anyone is working on it right now. I'd say take a crack at it!
Yeah, go for it! Parsing the XML above shouldn't be too difficult with libraries and such. You'll have to look into replacing currency symbols based on locale. $ and € and whatever else.
Price caching already exists, and the cache clears after 24 hours. I implemented it that way so that more nefarious traders would not be able to exploit cached prices of volatile cards, like Worldgorger Dragon. Was there something else you were thinking of?
As for price caching I think we could do a dailey cache of standard, the wish list and also the the decks/rares folder stuff after that gets implemented . Obviously this could be configurable but would probably see some user for those magic lovers in high school who don't have a data plan and want to have a fair trade.
Also, personally I think it should be optional to extend the price caching passed and show a time stamp next to the price for when the price data was captured.
The mobile github client doesn't let you eddit messages -__-
@grim-fendango that seems like a great idea (having a time stamp). That should be a configurable option if anything, and there should be a way to force a price update of a card in case you want the latest up to the minute price
I like the timestamp concept, though I'd want to see a UI mock-up first. That could get really cluttered really fast.
As for lookups, it could do something smarter, like check the 24hr cache, then check for network connectivity and if there is none, use an older cache with a timestamp. This discussion should be spun off into another ticket.
Work has been busy. Though I'm still very keen to get working on this.
Take your time, no rush.
Alright so update time. I've done some investigation and have identified two solutions for the currency conversion: a) convert it straight away before creating the cardPrice object thingo b) store it in USD and do the conversion as part of the view logic (e.g in the wishlist fragment) Both approaches would be optimised to some extent bu cachig the conversion rate and keeping floating point arithmetic away from the list view adapters. But my main question is: should we store the USD value when we are showing other currencies? Storing the USD and keeping conversion as part of the view logic might be more flexible and allow for fearures like displaying prices in two currencies at the same time. IDK if that's a valid use case hence some general feedback would be nice.
Other comments: Why aren't we using android annotations. The code base is so big and boiler platey :P
Also, we could show currency codes(eg., AUD USD) instead of just symbols. I think that that would be more usefull as it tells you exactly what currency you are dealing with. Also the american symbol and the australian one are the same so sellers could exploit people for more by demanding that the currency conversion be applied twice over.
Huh, so it is. Wiki also say AUD is sometimes represented as A$. Either way, it won't be a one character swap.
Any updates on this? Would be willing to put some time in if this is still a desired feature.
I have made zero progress on this. By all means, give it a shot! Actual currency conversion using the XML page noted above will be fairly easy. Tracking down all the "$"s and localizing them with a static function or something will be trickier.
Sounds good, will do.
The European Central Bank hosts some nice XML with current exchange rates. It would be nice to convert prices based on locale.