changed the logic of how derStandard puzzle ids are matched to dates

[LittleLui]

Instead of trying to match the actual release date of puzzles to their IDs (which was complex, error-prone and slow), we now assume daily releases (for easy conversion from date to id) with a freely configurable starting id for june 1 2014.

This simplifies this thing a LOT and gives us access to a large back-catalogue of puzzles; the latter is useful because actual puzzles aren't released daily (due to sundays/holidays) so we will catch up over time and eventually run out of puzzles. But that shall be handeled at a later date.

This also removes the neccessity for a cache file for puzzle metadata.

[adamantoise]

While I definitely like simplifying things and getting rid of the cache file (the best code is no code), doesn't this entirely break the whole date-to-puzzle mapping? If the puzzle is only published 6 days a week, then the app should only download the puzzle 6 days a week, not 7. If I ask for the puzzle on May 23, I should get the puzzle for May 23 (#7683), not whatever this happens to compute. There's no need for a user-configurable preference here since the publishing schedule is completely fixed for all users.

[LittleLui]

This absolutely breaks the date-to-puzzle mapping, yes. The main problem was that there is no reliable way to calculate the correct puzzle id purely from the date, as there are not only the sundays which lack a puzzle but also holidays (and austria has plenty of those). So by pure calculation I could only come up with an estimate id and I had to actually perform at least one HTTP get and parse the result to see if I got the right id, possibly several of those until i'd narrowed it down to just one id. On the other hand, by giving up on this, I not only can get rid of a lot of code, the cache file, but I - as a user - also gain another puzzle per week, as due to the big back catalogue I'm not bound to the actual schedule anymore. The price I pay for that is basically that I can't start working out a puzzle on paper and switch to the app or vice versa.

So in my personal judgement, it seemed to be a reasonable tradeoff to make. However, if your opposition to this change is as strong as I read from your comment, may I propose a compromise: We could offer both ways of operating, with the tied-to-the-date way being the default.

You'd have to give me a few weeks to come up with better code for that - maybe I'll incorporate a calendar of austrian holidays for a few years to come to increase the reliability of the first estimate - and perhaps that would be enough, as it seems the puzzles are produced a few weeks in advance so the chance of one being skipped due to illness of the author or something like that seems rather low and such a case could probably be handeled via an app update, so I could still get rid of those extra requests and parsing steps. Luckily there's plenty of historical data to test that hypothesis.

On Mon, Jun 2, 2014 at 6:32 AM, Adam Rosenfield notifications@github.com wrote:

While I definitely like simplifying things and getting rid of the cache file (the best code is no code), doesn't this entirely break the whole date-to-puzzle mapping? If the puzzle is only published 6 days a week, then the app should only download the puzzle 6 days a week, not 7. If I ask for the puzzle on May 23, I should get the puzzle for May 23 (#7683), not whatever this happens to compute. There's no need for a user-configurable preference here since the publishing schedule is completely fixed for all users.

— Reply to this email directly or view it on GitHub https://github.com/adamantoise/wordswithcrosses/pull/3#issuecomment-44801302 .

[adamantoise]

Given these constraints (that there's no simple mapping between puzzle date and puzzle ID), I think two approaches make sense: A) Keep the current approach of using a cached date-to-ID mapping which gets updated on-demand (note that there's plenty of room for optimization here); or B) Try to calculate the correct ID based on publishing schedule, holiday list, historical data, etc.; if the guess was wrong, adjust accordingly and retry

(A) is probably going to be more optimal in the long run (less network traffic, though more disk I/O) . (B) is simpler but results in more network traffic, which increases the failure rate (e.g. on a flaky network connection) and increases battery usage. Given that you've already implemented (A), I'm inclined to stick with that solution.

A low-priority feature I have on my list of future things to implement is a bulk puzzle download dialog—you're more than welcome to implement something like that, and I'd be happy to merge it in. If your goal is to be able to download lots of puzzles from the back catalog, then I think that would fit you nicely. The basic idea is that it'd be another menu option from the puzzle browser activity (or perhaps a sub-dialog of the current download dialog) which would let you select a puzzle source (or multiple sources) and a range of dates, and then it would download the selected puzzles for the selected date range.

[LittleLui]

After a bit of experimenting, it seems that with a calendar of holidays it is possible to calculate the ids from a date. This works flawlessly at least back to 2012 so I'm pretty confident it will work for the future, too.

While I'm at it, I'm also working on a bulk download dialog, so you might want to not start working on that in parallel :)

So far this seems to work reasonably well, but still needs some polish.

By the way, is there currently a way to have some kind of markup for the hint texts? I would need to set some parts of some hints in italics?

[adamantoise]

FYI I'm planning to merge this in (minus the WIP bulk download dialog stuff—could you actually separate that out into a separate pull request?), I just haven't had the time to test it out yet.

By the way, is there currently a way to have some kind of markup for the hint texts? I would need to set some parts of some hints in italics?

What do you mean by the hint texts? I'm not sure what context you mean, but HTML is the only kind of markup supported by any text in WWC, if any markup is.

[LittleLui]

Moved the bulk download onto a feature branch (haphazardly, showing my lack of git expertise).

As for the hint texts: see http://imgur.com/QX3OFd1 - i've highlighted in red what I called hint texts

[LittleLui]

Thanks :)

On Mon, Nov 3, 2014 at 2:09 AM, Adam Rosenfield notifications@github.com wrote:

Merged #3 https://github.com/adamantoise/wordswithcrosses/pull/3.

— Reply to this email directly or view it on GitHub https://github.com/adamantoise/wordswithcrosses/pull/3#event-187142303.