Spontaneous Praise

[Adam Feinstein]

A nice fellow by the name of LucidWindspark beat me to the punch by posting to Reddit about Familiar. The post he started is here. It warms my heart to see a user do something like this. I saw Jon left a few comments, and I did as well. Feel free to pipe in, or upvote, or whatever.

So yeah, great job all around! *high fives*

Oh, and I published 2.0.4 and patched in Sorin v Tibalt. I'll worry about merging 2.0.4 into trunk later. What a busy night!

[Jonathan Bettger]

So it looks like there is some kind of strange bug with Fuse cards. You can't get prices directly on the Wishlist/Trade List. (But if you card search, price grab, then pull on the wishlist/tradelist it works fine.) It looks like because I never bothered to save the multiverse ID, and the card name doesn't quiet do it for PriceFetch. I tried to fix it this morning before work, but I should have it fixed by tonight. Just FYI. Do we want to push a fix with 2.0.5 or just start pushing for finishing 2.1? (What do we want in 2.1 too?)

--
You received this message because you are subscribed to the Google Groups "MTG Familiar Devs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mtg-familiar-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Adam Feinstein]

That's probably sufficiently broken enough to warrant another band-aid release. I'll give it a week between when you check it in and when I publish to test, although we'll just find things after 8 days :/

The targets for 2.1 are tablet optimized search / mojhosto (at least) and judge's corner. Speaking of ye olde JC, if we go with the html/css approach over the database one, how much of a pain would it be to get new rules on there without an apk update?

[Alex Levine]

Fair question. Without looking into it, I'm going to guess that Android doesn't have a way of altering a raw resource programmatically, although if it does we could just re-write the entire .html file with each update. Alternatively, we could go with a ridiculous workaround I just thought up, in which we have a database table with one column and two rows, containing the contents of the two .html files, and we could load them from that table instead of loading the files from /raw. Then we could just update the database rows like we do for our card patches. But it's a tad on the convoluted side. I think the best solution really is for me to stop being lazy and figure out a good way to parse the JC rules files into a usable database so we don't need to do the html nonsense at all. I'll continue poking at it.

[Michael Shick]

Anything in the APK is cryptographically assured to be read-only

[April King]

We could distribute an HTML file with the installer, and then on the usual schedule, pull down an HTML file from a remote location, put it into the usual storage area, and then read from that.  I don't think it's too complex; apps pull down files and read from them all the time.

[Michael Shick]

I'm with April; It's almost the same to read from the files directory as it is to nab something from res/raw, except then its writable.  That will mean doing something like the initial card db inflation where we do have a baseline html file in res/raw and if we fail to find the file in the files directory we copy from res/raw first.

I had to do something like that for my bus schedule program; I supplied an initial pre-populated sqlite db as an asset, copied it to the databases folder on first run and then used it like a normal db
.

[Alex Levine]

Seems like a pretty good idea. And the auto-updating framework will already be in place (albeit without the parsing) if and when we change it over to use databases instead of html documents.

[Jonathan Bettger]

Fix the fuse cards for PriceFetch finally last night. It was a bit harder to do then I expected it to be, or I was trying to make the solution too simple.