Roku Developer Program

[sjb64]

I've been using the query apps ability in my channel (snippet below), and it always worked, but since the XML was missing the header, I had to manually add '<?xml version='1.0' encoding='utf-8' ?> ' to the beginning of the string to get roXMLElement to properly parse the response.

Suddenly this missing header seems fixed, which is of course now breaking that section of code.

I am running version 7 of the software (the object graph beta), is this a coming fix that I am just bumping into early or was accidentally included?

I can easily adjust for this in my code by adding the header only if needed, but that requires a channel resubmission and the associated QA and so on. So if this is a version 7 issue only, then I know I don't have an issue in the field I need to be reacting to, and don't need to jump off on a channel upgrade prematurely.

HTTP = CreateObject("roUrlTransfer")
HTTP.SetURL("http://127.0.0.1:8060/query/apps") 
XML=CreateObject("roXMLElement")
XML.Parse("<?xml version='1.0' encoding='utf-8' ?> "+HTTP.GetToString())

[RokuKC]

In 7.0, some of the ECP code was cleaned up to use a common XML return value formatter, so the responses should now consistently have an XML declaration.

This is standard and in some cases needed by clients for proper content-type and text encoding identification.

My recommendation would be that you update your channel, and only add the XML declaration if the string doesn't already have one.
E.g. if it doesn't start with "<xml " already.

Though, I don't expect that roXMLElement should require an XML declaration to parse XML, and from a quick trivial check that seems to be true.
Did you find it necessary to add it to get the proper text encoding support, or was there another reason that you could share?

If more wide-spread issues are found to be caused by the ECP change, we might look at other remediation depending on the release scheduling.

Thanks,
--KC

[TheEndless]

"RokuKC" wrote:
Though, I don't expect that roXMLElement should require an XML declaration to parse XML, and from a quick trivial check that seems to be true.

I can confirm this. My "My Channels" channel has used query/apps and roXMLElement for years, and I've never run into a situation where I needed to add the declaration to get it to parse.

[sjb64]

It was just to get it to decode. I wrote this particular routine last October if that helps date the firmware, but I couldn't get roXMLElement to parse it until I added that header, and it's worked perfectly since until version 7.

I already made the change to check first, and know that I know this is version 7 only I don't have to rush out a fix, so all is good.

[sjb64]

I can confirm this. My "My Channels" channel has used query/apps and roXMLElement for years, and I've never run into a situation where I needed to add the declaration to get it to parse.

I was new to BRS and might have had some other bug messing with me and accidentally fixed it tinkering and then mistakenly thought since that this did the trick, and hadn't really looked at that code since, interesting.

Thanks both of you, will pull that adjustment out completely then.

[EnTerr]

"RokuKC" wrote:
If more wide-spread issues are found to be caused by the ECP change, we might look at other remediation depending on the release scheduling.

Eek!
Perish the thought of breaking apps, on a related note - can we get the firmware version# (included as part of the UPnP descriptor at http:// IP:8060/ root or SSDP response or whathaveyou) - so apps can consider what version they are talking to and act accordingly? (i.e. more general approach than "check for <?xml")

[RokuKC]

"EnTerr" wrote:
...
(i.e. more general approach than "check for <?xml")

I'm probably not understanding. If your goal is to add an XML declaration if one is not already present, I recommend looking at the data in question, not the firmware version.

[EnTerr]

"RokuKC" wrote:
I'm probably not understanding. If your goal is to add an XML declaration if one is not already present, I recommend looking at the data in question, not the firmware version.

The goal is to be prepared for future changes in protocol/behavior. So say when my ECP app sees fw >= 7, i can have it act accordingly. Like i said, not a piecemeal but more general approach.

In theory, need-to-know-version is a YAGNI - but not in practice. Case in point, Roku Inc's own "Roku" mobile app over a year ago (if i recollect when i looked) was checking the player firmware version (in a rather kludgy/roundabout, non-ECP-ish way). Give us the same in ECP?