Set "Completed" date when completing an item about atarashii HOT 11 CLOSED

You know, I didn't even know this property existed. I don't think we need to store it locally, so it should be easy enough to add, just sending another parameter with the formatted date.

from atarashii.

Looking at the unofficial API site, it doesn't look like it supports sending dates and such. I know some other software will set this. Perhaps it's time for me to plug in a traffic sniffer to see how they do so.

from atarashii.

That would be neat. I'll also go bug Chu Yeow (the unofficial api creator) on Twitter about possibly getting this added to the api while we're at it.

from atarashii.

The official API offers more parameters for running updates, and this is what the other software I checked uses.

It looks like the official API offers nearly everything this application needs at the present moment and offers more options for update parameters. The only downside is that it works only with XML, not JSON. This makes it a bit heavier to work with.

from atarashii.

Mhm. That is true. I personally don't want to switch over to using the official API simply because XML isn't nearly as efficient in terms of parsing as JSON. Also there's the thing where we would have to rewrite the net code, something I avoided doing when I brought it over from the initial release way long ago because it wasn't broken

Mhm. Maybe I'll try my hand at extending the unofficial MAL API first though.

from atarashii.

Extending the API might be more work, and is likely to be fragile. I'd prefer to work out the rough patches of handling the XML over resorting to something else.

Maybe it would be worthwhile to encapsulate the whole MAL communication piece into a library? As long as the base API is the same, you could use either the unofficial or official API. It might be a bit much work for this application, but it is a good goal. There is actually a Java-based library for this: JMal. It's from the creator of the MALO app, which is crash-prone. The communication parts are pretty solid, though. No license is attached, but I'm sure the author can answer to that.

from atarashii.

Hmm. JMal might be a good option, but it would require a lot of reworking to integrate.

It might just be easier to convert our own implementation to use the official api and parse the XML response. Given the way we currently process data (passing record objects) we should be able to just change the method bodies of our bet code without too much fuss.

Also I like not having to depend on someone else's work, just a bit of a pride thing :)

from atarashii.

I might try working with JMal in my fork. It won't be focused so much on JMal itself, but on making our use of communication with MAL more loosely coupled. This means we could make our code for the unofficial API more of a library.

Also, it's stilly to re-write things when there's already an implementation available that works (assuming it does and is stable). Focus your pride on the unique qualities.

from atarashii.

Okay, so the official API was dead sometime around late 2009. Seriously. One interface was supposed to be replaced around that time, and it's still around and being used.

Unfortunately, there are a lot of limitations, like the inability to easily pull a synopsis for a single title. The workaround would be to do a search on the title, then look through the returned entries to get the synopsis. That, or scrape HTML.

I'm going to pause in my efforts for now. There are a lot of other things that need doing and cleaning up. After that, maybe some work on contributing to the unofficial api would be a better use of time.

from atarashii.

Contributing to the unofficial API I think would be beneficial not only to us in that it's probably the best solution, but to others as well in the spirit of open source.

I'll probably see what I can do about extending it after I finish up backporting to 2.2 with ABS.

from atarashii.

Closing ticket as invalid. We cannot control this with the unofficial API currently.

from atarashii.