satshabad / queue-api Goto Github PK

For both lastFMUsername and twitterUsername.

Considering possible ways of handling this - aside from just leaving it.

IMO a song that two of my friends have both told me to listen to, or that I've added at some point and then you've mentioned as well - has more priority, and is something I should be kept aware of so I can check it out.

We can think about if we want to, and possible ways To do this. Thoughts include visual indicators in or around the cell that indicate priority, or a simple count of the times an item has been added. Plus bringing it to the top of the Queue each time it's added (or even keeping high priority items at the top).

So the app can access that property (otherwise Jastor throws it out - since everything else uses 'fbId').

For shared items. As discussed.
Think about possible UI Implementations, simplicity being key.

After some research, I'm pushing this to after 0.6.0. If it's a real problem for us, we'll work it out. Otherwise it's opening a large can of worms I don't want to get into for now.

@fskhalsa

Check the validity of Last.fm usernames when they are PUT to the server. Return an error if the name isn't valid (something that can be distinguished from other errors, so an appropriate message can be shown to the user).

Think about it. It's something I feel I would use.
We can ask our testers too once we get some more.

Basically everything we just talked about:

Images and listeners in track results (listeners lets Queue show the most relevant result - artist vs track - at the top).

Standard format for results, sticking with the way listens and queue items are already returned:

Search results contains a dictionary with keys for two arrays: 'artistResults', and 'trackResults' (this is how it already is, no change needed).

trackResults contains track result items, which are dictionaries containing:

• song (object)
• listeners (string)

artistResults contains artist result items, which are dictionaries containing:

• artist (object)
• listeners (string)

Digging in, song contains:

• name (string)
• artist (object)
• album (object - may be added to queue items afterwards instead)
• images (dictionary of strings - as usual with all four sizes)

artist, both in artist result and in song contains:

• name (string)
• images (dictionary, as before - may not be available for artist in song)

album contains:

• name (string)

As a overall change (including in queue and listens - which this is the same as), we might want to consider the 'images' dictionary in 'song' going into 'album', as that may be more fitting. This would require a change for the other two things (queue and recent tracks) to work, but is probably more logical, and now is probably as good a time as any. Let me know what you think.

Other note - I noticed a few inconsistencies in listens results - mostly stuff like 'mbid' still being there, which maybe you want to remove. I'll log another issue for that though.

^

Return "", or no key instead. NULL is not typically used in Objective-C, and will crash the code when accessed if not checked for. Implement this across all return data.

Actually, just make sure and return everything that gets sent to you (excepting the items we've discussed that don't make sense for that).

Since, as we continue through creating this app, we'll likely be adding new properties to user info and possibly other things as we go, can you make it so the server will simply accept any new properties it doesn't recognize, and just use the ones it does know how to deal with, and forget the rest?

Currently, whenever a new change is added to the app, all posting/puting of user data fails until the server has been updated to handle that new data. It seems better practice to simple have a case to handle those changes, but not necessarily return an error code.

I've got push notifications mostly finished now in the app. I've got a few relevant things in my head so I figured I'd put them down in an issue:

Some various things that are relevant for when you start. Obviously do your own reading too, these are just key points that I'm recalling at the moment:

• Push notifications will need to include (for the app): the name of the alert sound we choose, the message to be displayed, AND the new badge count (which will have to vary depending on the user's settings - options are: no badge, total unlistened, or total shared (and unlistened)) - We'll need a way for this setting to be pushed to the server (probably in the user dictionary)
• Each device has a unique device token that the app will PUT with the user dictionary in the same way as lastFMUsername (it's called "deviceToken")
• These device tokens can change, so if the app gets a new one, it'll PUT that to the server, which will need to save it over the old one
• We don't want to be sending notifications to people who don't have the app installed anymore, so the server will need to check with Apple's feedback server every hour or so to get a list of disabled tokens (see doc for feedback server info)
• The app is already using a Production server certificate, so don't use Apple's sandbox server (most tutorials will reference that one, but just remove 'sandbox' from the address and it'll work fine)
• The certificate will expire in a year, and need to be renewed (so we'll need a simple mechanism for doing that, without any downtime preferrably)
• Apple strongly recommends keeping an open connection with the push notification server, rather than creating a new one for every notification - as setting up a new connection over and over is very costly in terms of processing power and network resources
• Obviously keep in mind that some users may opt out of push notifications, so there's no point in monitoring accounts without a deviceToken for newly shared items (it'd just be a waste of resources)

Here's Apple's doc on Push Notifications:
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction.html

And a tutorial that goes over a lot of good info (just skip the app-relevant stuff, unless you wanna know):
http://www.raywenderlich.com/32960/apple-push-notification-services-in-ios-6-tutorial-part-1

...and to keep it consistent with our class structure and the standard set by queue items:

All inside 'song' dictionary:

• album dictionary still has 'mbid' and '#text' keys
• artist dictionary still has 'url' and 'mbid' keys
• artist dictionary still has the old 'image' dictionary, along with the new proper 'images' dictionary

None of this is critical at the moment, but I figured you'd wanna know, especially if we're about to go in and change anything anyways, might as well do this at the same time.

Also consider the 'recommendedAlbum' again - I know I'd use it, and it also gives me something to put for the detail text in the Queue with artists, which keeps the look consistent. Now is as good a time as any to add that if we'll ever use it.

As discussed. Also add more URLs for listening - priority Grooveshark.

Get and return a user's Soundhound/Shazam tagged tracks as part of their recent tracks. Results should be in a mixed list based on when they were scrobbled/tagged, and have a "type" property for the app to use for UI differentiation.

If neither app has an open api, implementation of this will likely be through scraping of a user's Twitter/Facebook for auto-shared items in a certain format (which is defined by how the app shares).

Seems to be an intermittent problem related to the other services we rely on for link getting (Spotify in particular?).

A solution would be to try and get links, but if it's not possible within a short time interval, return the posted item without the links (or only with the ones that were available quickly), and push the link getting for that item into an asynchronous queue. The user can then reload the links from the UI after the fact, and UX isn't impacted speed-wise.

Plus this solution allows links to be available to the user without reload whenever the services ARE operating quickly.