Roku Developer Program

[EnTerr]

"belltown" wrote:
It's the mystery, undocumented Count().
Isn't it just a little annoying that the Roku docs don't tell the whole picture?

It sure is annoying, to say the least. It is also counter-productive, having to spend time experimenting things that should be able to find with a glance at documentation. Or the cases when they fail to mention there are version issues (i.e. something not supported in fw3) - that is negligence.

I have proposed in the past, if RokuCo cannot muster the workforce to maintain the docs - then to give access to select few of the outside dev.community, so they can fix obvious mistakes and omissions. Sure it's a touchy subject but if the attitude is "we could do this ourselves", they should as well do it. As @squirreltown put it aptly elsewhere, "This is just embarrassing. Like people who bondo their dents but never paint them. So close to finishing the job and then....Squirrel!"

To the limited extent i could, i try to help - in two steps:
1. When i discover omission/issue in the docs, i post a separate thread on that (so a discussion or explanation may happen) and
2. Link to it in viewtopic.php?f=34&t=69731 , in hopes that some faithful day someone may start going over these and resolving them. (admittedly i have slacked recently on linking there, should catch up)

Sometimes attempts of Roku personnel to help may end up making things worse though. There is a case that still bothers me but i just couldn't figure mentioning it without being complete arse. Because the person who did the edit i am sure had good intent and probably acted to the best of their abilities but... their "fix" made things worse than they were. I was asking about ifGetMessagePort/ifSetMessagePort of roCaptionRenderer - why they were not returned by getInterface. And then someone apparently decided "solution" to that was to just delete ifGetMessagePort/ifSetMessagePort from the page. It feels as if i called the city water district to report a water mains leak and their solution ended being to turn off the water supply for the neighborhood... permanently. Doh.

PS. First step to fixing a problem is admitting there is a problem - but i don't know if even internally RokuCo admits there is one.

[RokuKC]

"EnTerr" wrote:

...
I was asking about ifGetMessagePort/ifSetMessagePort of roCaptionRenderer - why they were not returned by getInterface. And then someone apparently decided "solution" to that was to just delete ifGetMessagePort/ifSetMessagePort from the page.
...

That is correct. roCaptionRenderer does not support ifGetMessagePort/ifSetMessagePort.

[TheEndless]

"RokuKC" wrote:

"EnTerr" wrote:

...
I was asking about ifGetMessagePort/ifSetMessagePort of roCaptionRenderer - why they were not returned by getInterface. And then someone apparently decided "solution" to that was to just delete ifGetMessagePort/ifSetMessagePort from the page.
...

That is correct. roCaptionRenderer does not support ifGetMessagePort/ifSetMessagePort.

Err.. While whoever wrote the component may not have explicitly implemented the interfaces themselves, it should be pointed out that the roCaptionRenderer absolutely has (at least) a SetMessagePort() method. SetMessagePort() is required in order to get the roCaptionRenderEvents, which are kind of critical to the whole implementation. Implementing the method without implementing the interface is just an attempt to confuse us, I guess.

[EnTerr]

"TheEndless" wrote:
Implementing the method without implementing the interface is just an attempt to confuse us, I guess.

Well if that was the goal - "Mission accomplished!" :twisted:

Because the above quoted 3.7.2 says

Every member function of a BrightScript Component is part of an interface.

"Every" method belongs to an interface, it said - not "most", "many" or "oftentimes".
And that made sense to me, seemed like a law of nature - until i saw this. Is that no longer true?
Could orphan methods exist or is roCaptionRenderer.setMessagePort() a member of a "secret" interface?

My point was that the cure was worse than the disease: if ifSetMessagePort was removed from roCaptionRenderer doco, mentioning setMessagePort() should have replaced it.

[TheEndless]

"EnTerr" wrote:
"Every" method belongs to an interface, it said - not "most", "many" or "oftentimes".
And that made sense to me, seemed like a law of nature - until i saw this. Is that no longer true?
Could orphan methods exist or is roCaptionRenderer.setMessagePort() a member of a "secret" interface?

My point was that the cure was worse than the disease: if ifSetMessagePort was removed from roCaptionRenderer doco, mentioning setMessagePort() should have replaced it.

SetMessagePort is there, and technically it is part of an interface... it was just, inexplicably, added to the ifCaptionRenderer interface instead: http://sdkdocs.roku.com/display/sdkdoc/ ... jectasVoid

[belltown]

"RokuKC" wrote:

"EnTerr" wrote:

...
I was asking about ifGetMessagePort/ifSetMessagePort of roCaptionRenderer - why they were not returned by getInterface. And then someone apparently decided "solution" to that was to just delete ifGetMessagePort/ifSetMessagePort from the page.
...

That is correct. roCaptionRenderer does not support ifGetMessagePort/ifSetMessagePort.

RokuKC, could you explain the following please ...

The following interfaces are documented but not returned by GetInterface:

ifSetMessagePort and ifGetMessagePort for the following components:


roAudioPlayer
roChannelStore
roCodeRegistrationScreen
roDeviceInfo
roFileSystem
roGridScreen
roKeyboardScreen
roListScreen
roMessageDialog
roOneLineDialog
roParagraphScreen
roPinEntryDialog
roSearchScreen
roSpringboardScreen
roTextScreen
roTextureManager
roVideoPlayer


ifSocketCast / roDataGramSocket
ifDateTime / roDateTime
ifSearchScreen / roSearchScreen

The following interfaces are returned by GetInterface but not documented:

ifHttpAgent / roAppManager
ifEnum / roMessagePort
ifHttpAgent / roParagraphScreen
ifSocketOption / roStreamSocket
ifHttpAgent / roTextScreen
ifArray / roXMLList
ifArrayGet / roXMLList
ifArraySet / roXMLList
ifEnum / roXMLList

The following interfaces appear to exist but are neither documented nor returned by GetInterface:

ifSetMessagePort and ifGetMessagePort / roImageCanvas

[EnTerr]

"TheEndless" wrote:
SetMessagePort is there, and technically it is part of an interface... it was just, inexplicably, added to the ifCaptionRenderer interface instead: http://sdkdocs.roku.com/display/sdkdoc/ ... jectasVoid

Ha, that's new development - setMessagePort was added to ifCaptionRenderer page today. And it even resolves as such, exactly as it was foretold:

BrightScript Debugger> cr = createobject("rocaptionrenderer")
BrightScript Debugger> cr.ifCaptionRenderer.setMessagePort("Thanks, RokuKC!") 
BrightScript Debugger>

I am left wonder if there could be "nude" methods or is it that when i find one i just don't know its parent interface?

[RokuKC]

"EnTerr" wrote:

...
Because a component may implement 2 interfaces with overlapping method names (as the case is here - roXmlList implements both ifList and ifArray and both have .count()s ) - there should always be a way to "explicitate" which of the two methods i want, shouldn't it?!

There shouldn't be any reason to call via an interface name, that I know of.
In case where a member function is listed on multiple interfaces it should be the same underlying implementation.

"EnTerr" wrote:

"Every" method belongs to an interface, it said - not "most", "many" or "oftentimes".

Yes, that's right.

[EnTerr]

"RokuKC" wrote:

"EnTerr" wrote:

"Every" method belongs to an interface, it said - not "most", "many" or "oftentimes".

Yes, that's right.

Thank you for the clarification!
So the discrepancies discovered by @belltown above - half of them are probably by methods implemented in the wrong interface, the other half by forgetting to document them?

Shouldn't that be fixed?! The doco part is easy to do at least.