I am implementing two-button rating for tracks. When the user clicks vote up/down, rateItem gets called, and my server returns an empty rateItemResponse (I have defined AutoSkip and OnSuccessMessageId in the presentation map). Immediately afterwards, getLastUpdate is called, and my server returns a response with the favorites value incremented. However, after the getLastUpdate response is returned, getExtendedMetadata is not called on the rated track to get the new user rating. What is the specific setup in order for getExtendedMetadata to be called after seeing an updated favorites value?
There are a few things you need to do to get this going, not all of which you mention in your queston. So, in case you haven't done this already, run the test as described here: https://musicpartners.sonos.com/node/376
Specifically note this section on that page:
There is another test, test_meta_data, in the ratings fixture that verifies that both getExtendedMetadata and getMediaMetadata are implemented correctly. This means that when these SMAPI requests are made with the object ID's listed in the Self-Test config for Test Track and the responses should contain a dynamic tag as part of the mediaMetadata. Inside the dynamic tag you must set property tags, each of which should contain a name and a value which is mapped to in the presentation map.
Also, maybe Sonos doesn't call extendedMetadata because there were no dynamic or property tags (or something) in the initial call's answer (but still the getLastUpdate call is supposted handle that, I think).
EDIT:
This seems to me to be a bug in the sonos customsd system. It should send a getLastUpdate request after a rateItem response, but it doesn't. I expect that this is a known bug, but since I cannot find any SMAPI bug reports sites monitored by Sonos, I am not sure. At any rate, if you are planning to submit you music service to Sonos, they will test it and let you know whether this is also a problem in production.
Any Sonos employees that can shed light on this? (Since the move to Stackoverflow, it seems nearly impossible to contact anybody from Sonos....)
Related
I have set up two referral credit rules.
All acting users get 7 default credits every time they trigger the event mq_app_open
Referred acting users get 10 default credits every time they trigger the event mq_app_open
mq_app_open is a custom event that I am recording on app open.
I can see that rule 1 is getting applied but can never get rule 2 to be applied.
What actually does "Referred acting users" actually mean?
I think the issue probably relates to the fact that when I open the app from a (universal) deeplink I see two events
open
mq_app_open
For each of Session Referring Branch Link ID, Session Referring Click ID and Session Referring Link URL are all null.
Oddly, when I let the app go into the background and then the foreground again I see the following events
open
referred session
For these two events Session Referring Branch Link ID, Session Referring Click ID have values but Session Referring Link URL is null.
I am not sure why any of these values are null when it would seem they should all reference back to the link url that was clicked on.
Alex from Branch.io here:
Referred acting users is a rather confusing way to say 'users who take action and open the app after clicking on a Branch link'. We should probably adjust our terminology to make this a bit clearer. For most purposes, you can think of this as Referred users.
I am actually not certain why rule 1 is working but rule 2 is not. Possibly there is some conflict with having two rules applying to the same user from the same event — you could try refactoring the rules so that Referring users get 7 points and Referred users get 17.
Those session parameters should be coming back with values, assuming a link was clicked. We probably need to do a bit more debugging to see what's going on — would you mind submitting a ticket to the Branch integrations team so that we can dig into the code and the backend config of your specific app?
I need to use themoviedb.org for one of the apps I am working on. For using the API, I need an API key. How do I get an API key on themoviedb.org?
I found this in the forum:
You can request an API key by clicking on the "API" link from within your account page on the left hand sidebar. See here
In terms of making things faster for people, the URL for application is here these days (Under Account>Settings>API as previously mentioned): https://www.themoviedb.org/settings/api
You'll want to start with a Developer key as wait time for a Developer key is zero (immediate). A commercial key, as far as I understand it, is only appropriate once the app is developed and running. Turnaround for a commercial API key is about 3 days-ish though obviously could vary.
Once you have a key, inside the doco pages there's a "Try It Out" tab which lets you do calls. The normal code flow (for getting movie details) would be something like:
Get Configuration (needed for image paths, should be cached)
Search Movies (returns a list, find the numeric id for the one you want in the list returned). Be aware there might be duplicates returned - you can use the year of release, title and language to find the one you want.
Get Movie Details with the movie numeric ID, with "append_to_response" of "credits,images,trailers" so that actors, writers, directors, and trailers (aka videos) are returned.
Check doco for how to find the actual image paths, using configuration values fetched above. It's generally considered courteous to copy the images you want to use to your own server rather than serving them from TMDB's server.
Right, this is really working on my nerves, but Instagram has to do something about their bloody documentation.
I am already trying for a week to live update my website with new instagram posts without refreshing the page. Twitter was fairly easy, but instagram is just one big mess. Basically I use the realtime Instagram API, the callback and all that stuff is working fine, but thanks to Instagram it does not return me an ID from the post that is new, the callback only returns some basic stuff:
[{"changed_aspect": "media", "object": "tag", "object_id": "nofilter", "time": 1391091743, "subscription_id": xxxxx, "data": {}}]
with this data you are nothing, except for the Tag, but I knew the tag before this callback too so doesn't matter. It actually only tells me that there is a new post. I have tried doing the same request as when the page loads, when this callback occurs, and get the posts that are newer than those already on the page. Unfortunately I have not succeeded in this yet. I have picked the ID from the last posted instagram post, and checked if it is in the callback request, and it's not.
What am I doing wrong?
I'd appreciate some help, thanks!
Edit:
I'd like to note that this is not only a problem with the realtime api, but also with the normal API. I just don't know how to compare data so I don't get duplicates in my database(normal api), or on my website (realtime). I can't find any tutorial or documentation (Yes, I might be blind), that explains to me how to compare data. I can only find the min_id and max_id, but no explanation what these id's contains. I checked these id's with id's from results, and they do not match. It's not an ID from a media item.
I also checked the next_url, and in my logic thinking, this should be a URL to the next page (like Twitter).
Am I looking at this all wrong?
Ok strike my old answer, I changed the way I do this. Here's how I'll do it now.
I still wait for 10 hits on my Real-time subscription, when I reach 10 I send off a new thread (if one is not already running).
The sync thread queries my DB for a value, I need the last min_tag_id I used. Then I query:
https://api.instagram.com/v1/tags/*/media/recent?access_token=*&min_tag_id=*
Try it out here: https://api.instagram.com/v1/tags/montreal/media/recent?access_token=*
You'll get 20 results, and a min_tag_id value. Append that to your url, you'll see you get no results. Wait a couple of seconds and refresh. Eventually you'll get some media, and a new min_tag_id.
(You can ignore the "next_url" value they give you, you won't be using that).
Basically you only need to store that min_tag_id and query until you have no more results, that means you're done then.
When you get a subscription push, you need to query that endpoint (tag / recent).
I normally start an synchronous thread to perform this so I can answer in under 2 seconds to Instagram.
Then you parse that endpoint and look for a "next url" value.
Keep querying that end point, parsing the media and going to the next url until you find your stop condition.
For me I try to match 10 consecutive records in my DB. Basically from the tag, I store media when then meet my business rules.
The Instagram documentation is accurate and actually well written.
The realtime API is working correctly. As stated in the documentation:
The changed data is not included in the payload, so it is up to you
how you'd like to fetch the new data. For example, you may decide only
to fetch new data for specific users, or after a certain number of
photos have been posted.
http://instagram.com/developer/realtime/
You only receive a notification that an update has happened to your subscribed object. It is up to you to call the API to find out what that data is.
You can call the /tags/[tag-name]/media/recent with an access token that you have previously stored on your own server or DB. Then, you should be able to compare the data returned from that endpoint with any data you have retrieved prior, and just pull the objects that you do not yet have.
I'm making a REST interface to a management system (let's call this system A) for network equipment and I have everything working. A fetches the equipment information from another backend system (let's call this system B) and index it in a database and then whenever a client asks for the information over the REST interface it returns it as JSON.
However sometimes a client needs to forcefully make A refresh some equipment information by requesting it from B (without the client being involved besides asking A to refresh it). Refreshing the information for a single node takes several seconds so the information should probably not be returned in the same request as in which it is requested. Currently we've modeled this as that you create a job of a "refresh information" type using POST /jobs with some data. But this feels very over engineered and we'd much rather want something like POST /equipment/<id>/refresh but this feels to go against the "REST way"?
Is there any other solution to this than the one mentioned with jobs above but still follow the "REST way"?
I would use GET /equipment/<id>?since=<timestamp>, where the since parameter is optional. Semantically this means:
Get the equipment with the given id as of whenever it happened to be last refreshed (when timestamp not given), or
Get the equipment with the given id refreshed no earlier than the given timestamp
Each equipment in your system would have a last_refreshed timestamp. The GET with the since=<timestamp> parameter would refresh the equipment if last_refreshed < since and then return the equipment.
A user of your service could then say GET /equipment/123?since=<15 minutes ago> and be sure they're always getting info that's no older than 15 minutes. GET /equipment/123?since=<now> means "force a refresh."
Keep in mind that POST in Rest services means that you will create some object.
To refresh one object, or update, it's recommended the PUT method.
Like um CRUD, when you have Create, Read, Update, and Delete, in REST will be POST, GET, PUT, DELETE (in order).
Maybe in your case the best URL for this is a PUT to /equipment/<id>.
URLs:
POST to /equipment/ : Create equipment
GET to /equipment/<id>: Read equipment with id <id>
PUT to /equipment/<id>: Update equipment with id <id>
DELETE to /equipment/<id>: Delete the equipment with id <id>
I hope that solve you doubt.
Anyway, a good reference it's the Apigee ebooks
I've got that they changed their api according to this: https://groups.google.com/forum/?fromgroups#!topic/foursquare-api/sQMuHlv9wiU
But it sais I should be able to get people near-by if I'm checked-in to the specific place. However it gives me back the same response before check-in and after check-in ...
Edit: A couple other devs have run into this issue, and in many cases, it looks like the issue is that lat/lng isn't being passed into the checkins/add request (the "ll" param). You're not included in hereNow unless you're deemed to be plausibly close to the venue.
You should be able to get other people checked into the venue after having checked in, but remember, there might not always be other people checked in.
In general, for the venue you've checked in at, you should see roughly the same number of people listed in the hereNow block as the "count" field shows. However, people can opt out of showing up in hereNow, so you will still occasionally see fewer people than the count field shows.
Remember that you're only considered "checked in" to a venue if (a) it's been less than 3 hours since you checked in and (b) you haven't checked in anywhere else.
If you're still having problems, email api (at) foursquare.com with the specific request to hereNow made before checking in, the request you made to check in, followed by the request to hereNow you made after checking in, and we can help you debug.