When implementing a Sonos Music API, how do I get a menu listing "collection" items, to display a "Play All" button? - sonos

What I'm trying to achieve
I want to display the same "Play All" menu item I get when listing tracks (menus with itemType=trackList) for menus of other itemTypes e.g. Playlists. Is that possible?
So for example, representing each menu as a nested list, I want:
Collection 1
Play All <---- I don't get this one!
Playlist 1
Play All <-- I get this
Track 1
Track 2
...
Playlist 2
Play All <-- I get this
Track 1
Track 1
...
It's fine if this behaviour is not possible, but I just wanted to double-check.
What the docs say
According to the Sonos API docs, you can make other itemTypes playable by setting canPlay=true. In fact, it specifically mentions my use case:
The canPlay flag is used to indicate that the collection can be queued up for playback in its entirety. In order to accomplish this, the client will call getMetadata passing in a Boolean parameter “recursive” set to true. This will return a flattened list of all mediaItem elements in the collection. For example, “canPlay” might be true for a collection that represents a playlist of tracks...
When I set canPlay=true I'm able to press and hold on the Collection in the prior menu, and have a menu popup that let's me play everything that way, but I don't get an actual "Play All" icon in the subsequent menu. Is that intended, or is there any way to display the "Play All" icon?
The SMAPI itemTypes page says:
a mediaCollection of itemType trackList with a canEnumerate = true will enable the "All Tracks" node once you browse into the container, as shown below
Is that the only itemType that this will work for?
My getMetadata Responses
In case it's useful, here's my getMetadata responses:
getMetadata call that displays the menu containing the Collection:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getMetadataResponse xmlns="http://www.sonos.com/Services/1.1">
<getMetadataResult>
<index>0</index>
<count>10</count>
<total>10</total>
...
<mediaCollection>
<id>collections:134</id>
<itemType>collection</itemType>
<displayType>standardView</displayType>
<title>Collection 1</title>
<summary>Collection 1 Summary</summary>
<canPlay>true</canPlay>
<albumArtURI>https://path/to/album_art.jpg</albumArtURI>
</mediaCollection>
...
</getMetadataResult>
</getMetadataResponse>
</soap:Body>
</soap:Envelope>
getMetadata call that lists the Collection's Playlists:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getMetadataResponse xmlns="http://www.sonos.com/Services/1.1">
<getMetadataResult>
<index>0</index>
<count>1</count>
<total>1</total>
<mediaCollection>
<id>collections:134:playlists:506</id>
<itemType>trackList</itemType>
<displayType>standardView</displayType>
<title>Playlist 1</title>
<summary>Playlist 1 summary</summary>
<canPlay>true</canPlay>
<albumArtURI>http://path/to/album_art.jpg</albumArtURI>
</mediaCollection>
</getMetadataResult>
</getMetadataResponse>
</soap:Body>
</soap:Envelope>

It sounds like what you are trying to display is the "All Songs" node at the top of a collection of tracks. As you mention, setting "canPlay" equal to true will cause a "Play All" node to be displayed, and this should work for any mediaCollection regardless of container type. Similarly, setting "canEnumerate" to true should result in the "All Tracks" node being displayed at the the top of a container for any mediaCollection. There is unfortunately no way to display a Play all button at the top of a container.

Related

LabVIEW Parsing XML String without using tools

I am creating an information displaying mini-app for a device. The response I receive from the device when I send an HTTP Get request is literally as follows:
<?xml version="1.0" encoding="iso-8859-2"?>
<root xmlns="http://www.papouch.com/xml/th2e/act">
<sns id="1" type="1" status="0" unit="0" val="25.0" w-min="" w-max="" e-min-val=" -0.3" e-max-val=" 124.0" e-min-dte="01/01/2014 13:16:44" e-max-dte="05/14/2014 10:00:43" /><sns id="2" type="2" status="0" unit="3" val="56.4" w-min="" w-max="" e-min-val=" 0.1" e-max-val=" 100.0" e-min-dte="01/27/2014 08:39:14" e-max-dte="03/04/2014 11:02:40" /><sns id="3" type="3" status="0" unit="0" val="15.7" w-min="" w-max="" e-min-val=" -21.3" e-max-val=" 85.9" e-min-dte="01/27/2014 12:21:28" e-max-dte="03/04/2014 11:29:32" /><status frm="1" location="NONAME" time="01/02/2014 7:12:00" typesens="3" /></root>
There are 3 sns elements with incrementing ids, I need to read the val attribute of the sns element with the id 1.
I tried implementing the suggested way here:Get specific XML element attributes in Labview , and shown below is my implementation, but it does not work. I tested the XPath on http://xpather.com/ and it fetches the value I need just fine.
The XPath I am using is: //root/sns[#id="1"]/#val
The result I get when I run is just nothing, no Parsing errors, no any other errors, everything seems to be okay but the String indicator is always empty, String 2 displays the HTTP response fine.
I am using (and have to use) LabVIEW 2011 SP1.
The reason why the result is empty is the wrong input of Get Node Text Content.

How to get ID's of the records in Cross-reference field using Web API in RSA Archer?

I need to get the ID's of the records in a cross-reference field using Web API. Is there an API method to solve this type of task? Or at least I want to know, how to get the value of a specific field?
There are many different methods described in the documentation for operating with list fields (such as GetValuesListValue) and I wonder if there a same way to solve my task.
I can use ExecuteSeach method, but it isn't very convenient.
Alexander, you can either use the REST or Webservices APIs.
REST APIs
Using the Get content by id, /api/core/content/*contentid*
Then you can pass OData to just get the field (id) contents by passing the following in the body
{"Value":"?$filter=FieldId eq '*field id of cross-reference field*'"}
Webservices APIs
You can call the /ws/record.asmx GetRecordById passing the following
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetRecordById xmlns="http://archer-tech.com/webservices/">
<sessionToken>session token</sessionToken>
<moduleId>int</moduleId>
<contentId>int</contentId>
</GetRecordById>
</soap:Body>
</soap:Envelope>
Then you'd have to iterate through the returned XML to get the field contents.

SoapUI Assertions - either XPath or Contains Assertion would be fine

Sample response below. I want to check the existence of a specific error code (860) in the response below. Technically, to avoid picking the error up accidentally in a reference number, I need to be checking it is in the bit labelled < code >860< /code > (inserted spaces so it would show).
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:activatePortResponse xmlns:ns2="http://transferobjects.abc.abc.org">
<return som="6001365" state="Approved">
<errors>
<error>
<code>860</code>
<description>The Port cannot be activated outside the ready for service dateTime window (grace period taken into account).</description>
<mnemonic>RFS_WINDOW</mnemonic>
</error>
<name>som</name>
</errors>
<success>false</success>
</return>
</ns2:activatePortResponse>
</soap:Body>
</soap:Envelope>
I was trying to build a set of calls with expected error results to check the the error responses are returned as they should. Going through all the usual garbage messages that meant nothing to me, I just kept tweaking.
Turned out I could use a Contains method and just paste in more, rather than just 860 or even < code >860< /code > I just had to paste in a bigger chunk like this:
<error>
<code>860</code>
<description>The Port cannot be activated outside the ready for service dateTime window (grace period taken into account).</description>
<mnemonic>RFS_WINDOW</mnemonic>
</error>
So I have a solution, but if anyone wants to show me how to do it with XPath, in a less hamfisted way, that would be cool.
You could do an XPath Match assertion with the following expression //error/code, which in the above response message would find 860. This way you know that this 860 has been found at a particular place in the XML hierarchy.

Davical Sync-Token web request

I am trying not to re-invent the wheel here...
I have found some nice documentation on CalDav sync implementation there
According to its website, DaviCal is rfc6578-compliant since v. 0.9.8 (see here).
I therefore first send my request to get the sync token as follows:
PROPFIND http://my_cal_srv/user/calendar_path HTTP/1.1
Content-Type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<d:propfind xmlns:d='DAV:'>
<d:prop>
<d:displayname />
<d:sync-token />
</d:prop>
</d:propfind>
This returns data as expected:
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>/caldav.php/user/calendar_path/</href>
<propstat>
<prop>
<displayname>My Calendar</displayname>
<sync-token>data:,9</sync-token>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
So far so good, I have a token, it's "data: ,9". So, let's just try to get changes since 8, the token I had when I queried the server prior to adding some event.
REPORT http://my_cal_srv/user/calendar_path HTTP/1.1
Content-Type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<d:sync-collection xmlns:d="DAV:">
<d:sync-token>8</d:sync-token>
<d:sync-level>1</d:sync-level>
<d:prop>
<d:getetag/>
</d:prop>
</d:sync-collection>
The answer is:
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>/caldav.php/user/path/86166f9c-3e2e-4242-9a28-0f3bfb1dd67a-caldavsyncadapter.ics</href>
<propstat>
<prop>
<getetag>"5ed2101b0c867e490dbd71d40c7071bb"</getetag>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/caldav.php/user/path/cb354fab-b41d-49ad-8a4f-8d68c9090ea0.ics</href>
<propstat>
<prop>
<getetag>"334892703f4151024e9232eab9b515a7"</getetag>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<sync-token>data:,9</sync-token>
</multistatus>
After deleting an entry (so I get sync-token 10, and still compare using token 8), I get following result :
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>/caldav.php/user/cal_path/86166f9c-3e2e-4242-9a28-0f3bfb1dd67a-caldavsyncadapter.ics</href>
<status>HTTP/1.1 404 Not Found</status>
</response>
<response>
<href>/caldav.php/user/cal_path/cb354fab-b41d-49ad-8a4f-8d68c9090ea0.ics</href>
<propstat>
<prop>
<getetag>"334892703f4151024e9232eab9b515a7"</getetag>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<sync-token>data:,10</sync-token>
</multistatus>
So I am a little confused here as I don't really know how to interpret these results...
Could anybody please explain to me how to extract the sync info from here? It is a little hard to figure out the changes types because the ICS namings are unclear...
Thanks in advance for helping out... And merry X-Mas !
Regards,
N.
That you get a "data:,9" doesn't imply you can actually query "data:,8" or ,7 etc. Sync tokens are opaque and do NOT give you a versioning system (you need sth like DAV Versioning Extensions for that).
DAV sync-tokens are a simple optimization technique - nothing more. They are completely opaque to the client and the server can expire sync tokens at any time (and is not required to save tombstones and such). Eg a server which can't store tombstones can simply expire tokens on DELETE requests.
The way you use sync-tokens is:
to figure out which child collections of a parent collection need to be re-synced
to optimize syncing of a the resources within a child collection
1) Which child collections need to be synced
Assume you have a collection of calendars (e.g. my_cal_srv/user/) and you do a PROPFIND Depth:1 on this collection, asking for the sync-tokens of the child collections. If those don't match the ones of your clients cache anymore, you know you need to perform a sync of just those child collections.
Note: do NOT use the token you got back from this request to sync the child collection (which is what you do above). It might have expired already. Within sync-reports only use tokens you got from sync-reports!
2) Optimizing syncing of the collection contents
Again: sync-token's are an optimization, nothing more. You always need to be prepared to get an (in)valid-sync-token precondition error (which means the server expired the token) and do a full refetch of the collection contents! And then compare that (URL,ETag) to your cached version to figure out what the changes are. (essentially all the steps you need to do when you have a server which doesn't support sync-reports).
If you get a sync-token in the sync-report results, you can then use it in the next sync-request. If the server still has the state, it'll just give you the changes. If it expired the token, it'll give you the sync-token error.
Note: In case it isn't obvious - in the very first sync-request you don't (can't) provide a token. You run the query w/o a token and get back all the contents. You do the same again if the server sends you an (in)valid-sync-token error.
You're not doing a correct request. In your request you have:
<d:sync-token>8</d:sync-token>
But this should be:
<d:sync-token>data:,8</d:sync-token>
Aside from that, the first response you are getting tells you that:
These resources have been changed or newly created:
/caldav.php/user/path/86166f9c-3e2e-4242-9a28-0f3bfb1dd67a-caldavsyncadapter.ics
/caldav.php/user/path/cb354fab-b41d-49ad-8a4f-8d68c9090ea0.ics
The second response tells you:
This resource has been changed or newly created:
/caldav.php/user/cal_path/cb354fab-b41d-49ad-8a4f-8d68c9090ea0.ics
This resource has been deleted:
/caldav.php/user/cal_path/86166f9c-3e2e-4242-9a28-0f3bfb1dd67a-caldavsyncadapter.ics

REST wrapping a single resource in a collection

I have a small dilemma.
If you have the following URI endpoints:
/item
/item/{id}
If I make a GET request to /item I expect something like this:
<Items>
<Item>...</Item>
<Item>...</Item>
...
</Items>
If I make a GET request to /item/{id} I expect something like this:
<Item>
...
</Item>
Some of my fellow team members argue we should design the API so when someone does a GET for /item/{id} it should be returned as a collection of a single element. Like this:
<Items>
<Item>...</Item>
</Items>
This seems wrong to me. Does it seem wrong to you too? Please explain why, so I might convince either myself to go with the always wrapped version of the resource or my fellow devs to go with the non-wrapped single resource.
Most importantly, there is no right and wrong answer to this question.
However, here is what I think.
If you want to return a single item, I would tend to do this:
GET /Item/{Id}
=>
<Item>
...
</Item>
If the {Id} does not exist then the server should return a 404.
If I want to return a collection of items, I would do
GET /Items
=>
<Items>
<Item>...</Item>
<Item>...</Item>
</Items>
If there are no items, then it should return a 200 with an empty <Items/> element.
If it really makes it easier for the client to deal with a collection that has just one element, then you could do something like this.
GET /Items?Id={Id}
=>
<Items>
<Item> ... </Item>
</Items>
The difference here is that if the {Id} did not exist then I would tend to return 200 not a 404.
Seems counterintuitive to me. You are potentially saving code effort on the client side by having one way of reading data from your two GET methods. This is of course countered by having extra code to wrap your single GET method in a collection.
If you want real world examples,
twitter returns an individual
representation of a resource not
wrapped in a collection
basecamp, an
early proponent of REST based API,
also follows this model
EDIT: Our API uses this HTTP status code structure
I think your colleagues are right if you think about the consuming side of your REST service, which then can handle every response as a collection. And there's one more thing: If the {id} did not exist, what does your service return? Nothing? Then the consumer has to check for either a null result or error response, a single element or a collection. According to my experience getting a collection in any case (which may be empty) is the most convenient way to be served by a REST service.