The Song Fight Bulletin Board

This RSS feed is described in the source for songfight.org as "Upcoming fight and song news" but it doesn't appear to have the song news:

http://www.songfight.org/rss.php

If that had the song news in it, you could use that...

Thanks! I can figure out the rest and scrape the news myself - this is good enough to get something working. As for enhancement requests:
- Since we only have one concurrent fight, it'd be kind of cool if there were a current.json like next.json...
- I kind of take issue with next.json, purely out of principal, if there were ever a fight titled that.
- Can pass down version so that apps don't break on major retooling of JSON? Perhaps XML is more equipped for this.
- Artist keys alongside artist names in most places/I don't feel comfortable that something won't break with the names

Manhattan Glutton wrote:Thanks! I can figure out the rest and scrape the news myself - this is good enough to get something working. As for enhancement requests:
- Since we only have one concurrent fight, it'd be kind of cool if there were a current.json like next.json...
- I kind of take issue with next.json, purely out of principal, if there were ever a fight titled that.
- Can pass down version so that apps don't break on major retooling of JSON? Perhaps XML is more equipped for this.
- Artist keys alongside artist names in most places/I don't feel comfortable that something won't break with the names

- I'd prefer not to change things to stop dealing with multiple concurrent fights because then when the whim strikes to return to multiple concurrent fights I'll just have to change things back. For now you could do something like: 1: GET "/fights.json?current=true" 2: for fight in response if fight.key not in locally stored set of current fight keys then GET "/fights/(key)" to get the full data. It's not much different than what you'd probably be doing anyway.
- Fair enough. Got a suggestion for a better URL for that data?
- My only plans for the foreseeable future are to add data to the JSON, which is backward compatible. If I introduce a new API that's not backward compatible I'll probably put the version in the URL, like "/v2/fights/(key)" or "/fights/v2/(key)".
- Sure. I'm not really using the artist keys myself anymore, though, as the songfight.org archive seems to be doing a good job of handling URL encoded full artist names, and my version of the process for creating the artist keys from the names never 100% matched up with whatever the PHP code is doing. EDIT: Done for "/artists" and "/artists/(artist name)".

fights.json?next=true ?

*whiny voice* But I don't waaaant to URL encode

Manhattan Glutton wrote:fights.json?next=true ?

*whiny voice* But I don't waaaant to URL encode

Done. I tweaked the format of the JSON a little to allow for the possibility of multiple next fights.

Cool! Thanks.

Now I'm all excited to work on this, but I have volleyball and karaoke tonight!

So the feature set I'm aiming for:
Phase 1
* News/Upcoming fights
* Current fight
* Archive browsing
* Images and streaming
* Audio backgrounding
Phase 2
* Notifications (title changes, vote reminders? due date reminders?)
Phase 3
* Downloading/favorites/media player
Phase 4
* Basic forum integration

Lunkhead wrote:This RSS feed is described in the source for songfight.org as "Upcoming fight and song news" but it doesn't appear to have the song news:

http://www.songfight.org/rss.php

If that had the song news in it, you could use that...

Yeah, I meant to add that in eventually but never got around to figuring out the details of the fiddly sidebar data format.

As far as notification goes, I just use the calendar feed.

Manhattan Glutton wrote:Now I'm all excited to work on this, but I have volleyball and karaoke tonight!

..... ........

Manhattan Glutton wrote:Phase 2
* Notifications (title changes, vote reminders? due date reminders?)

I've already got a setup for sending notifications for new titles, new songs, and fight results. It's flexible so I can code up new destinations for those notifications (e.g. Facebook, Twitter, email, Apple push notification, Google "cloud to device" messaging, etc.). So don't go writing that yourself unless you really want to.

I can set up time based reminders too though maybe push notifications aren't necessary for that, as they can probably be handled locally on a device without too much difficulty.

Stuff we know can be done using "local notifications" but push notifications require some fancy SSL certificate yatta yatta. I'll look into it later.

I see no reason why the due date needs to happen as anything other than a local reminder on either platform.

Also, I don't know about iOS, but on Android you can use a local "alarm" to trigger the polling of remote data to get the new title and due date and such, so there's no real reason to use push notifications for that either.

I don't think I can schedule network tasks like that, because it would ruin the iPhone's pristine battery life. The last I heard, all push notifications have to go through Apple's servers. AND IT IS BETTER THAT WAY.

So sayeth the Book of Jobs, anyway.

My T-Mobile G2X gets well over a full day of use even with a bunch of apps that do occasional polling (email, calendar updates, app updates from both Google and Amazon, weather, news, etc.) and I can't see something that triggers only once every 6 hours and downloads a tiny JSON blob as being a huge battery sink.

I'm not arguing anything. Just pointing out the reality we have to deal with. (And I love Steve Jobs and he's always right and your Droid sucks.)

Droid is Verizon's trademark for their Android phones.

No it's not.

The brand name Droid is a trademark of Lucasfilm licensed to Verizon Wireless.

It is licensed but is further trademarked for mobile phones by Verizon.

Either way I don't have a Droid.

What I do have is allowing me to post from a motherfucking bus via my Kindle Fire, though.

I disagree. Your evidence is insufficient, and your argument is not compelling.

I think push notifications might still be a good idea for the non-reminder stuff. It seems like, at least with the existing notifications I've set up, a lag of 6 hours like fluffy mentioned makes them not so useful. In six hours I'll probably have already checked the boards and seen that the title/songs/results are up, since I'm crazy like that about checking the boards.

Anyway, push notifications are also just way cool. And on Android you don't have to pay extra for it or set up an SSL certificate or any of that crazy stuff.

Once I figure out what we have to do, I'll let you know and maybe you can handle that on sfjukebox? I think it requires signing the notification with some encryption key and sending it to an Apple server. So I'll probably not get into that until I have a working app and developer's license.