Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
joetesta
Roku Guru

Re: SDK documentation: links to fix, missing/broken/etc

There's a misspelling on this page that tripped me up when I copied and pasted (note the extra "T" after the "N"): "EPGLaunchIntitiate"
https://developer.roku.com/docs/developer-program/performance-guide/measuring-channel-performance.md
aspiring
0 Kudos
RokuTomC
Community Moderator
Community Moderator

Re: SDK documentation: links to fix, missing/broken/etc

"joetesta" wrote:
There's a misspelling on this page that tripped me up when I copied and pasted (note the extra "T" after the "N"): "EPGLaunchIntitiate"
https://developer.roku.com/docs/developer-program/performance-guide/measuring-channel-performance.md

Thanks Joe, good catch. This is now resolved!
0 Kudos
marcelo_cabral
Roku Guru

Re: SDK documentation: links to fix, missing/broken/etc

"RokuTomC" wrote:
"Komag" wrote:
Looks like "game" is back, right near the bottom, just above "Screensaver attributes"

I would like solid definitive correct sizes for things as well:

icon
540x405?
290x218?
336x210?

When I set mine to 290x218, it looks PIXEL PERFECT on my Roku 4 and on my 4k Roku TV where the UI is 1080p.
Maybe the 540x405 is for the larger channel picture that you see when surfing the channel store?

Komag and Marcelo, I've confirmed the dimensions listed for the manifest attributes in the documentation is accurate. However, please be aware that these assets are only used when your channel is side-loaded. When your channel is published and installed from the Channel Store, the channel icon that renders is the one that you upload during the channel creation/submission flow.

540x405 is the dimension for the asset uploaded during channel submission. This is the pixel perfect spec, and scaling is handled by the firmware.
If this is incongruous with your experience, can you shine a little more light on the specific use cases where things are going array?

I just think that there is no point to have those old dimensions standards as they looked distorted because the aspect ratio is different from the current firmware UI. Just make a single standard as 502x405 and avoid this confusion. My final 5 cents on this. 🙂
0 Kudos
joetesta
Roku Guru

Re: SDK documentation: links to fix, missing/broken/etc

The last example entry on this page is incorrect:
https://developer.roku.com/en-gb/docs/d ... -search.md

For the sign up flow use case, call 
dispatchEvent("Sign_Up|pageNumber=<int>|pageType=<type>")
 or 
dispatchEvent("Sign_Up|pageNumber=<int>|pageType=<type>``") when a page is submitted or field is entered.``


It should be more like the first example that has different field values in the 2nd entry:
dispatch an event for the sign-up flow, assign
{RED: {eventName: "Sign_Up|pageNumber=<int>|pageType=<type>"}
or
{RED: {eventName: "Sign_Up_Form"|field=<string>"}
aspiring
0 Kudos
joetesta
Roku Guru

Re: SDK documentation: links to fix, missing/broken/etc

There is insufficient guidance wrt pageNumber or pageType values:
 https://developer.roku.com/en-gb/docs/developer-program/discovery/search/prioritizing-authenticated-...

Should pages use consistent values for pageNumber (ie should a specific view be assigned a pageNum that's then used consistently for all users, no matter which path they follow to the page; or should the pageNum be incremented arbitrarily as the user steps through the process (such as maintaining a global pageCounter that's incremented on each page in the flow)?

What values may be used for pageType and where does it matter?  Can we create our own arbitrary types?
aspiring
0 Kudos
joetesta
Roku Guru

Re: SDK documentation: links to fix, missing/broken/etc

Types listed do not match example:

pages: landing, sign in, registration, device activation, subscription selection, payment, and cancellation.


Examples:
"Sign_Up|pageNumber=1|pageType=Landing Page" "Sign_Up|pageNumber=2|pageType=Sign In"


Note: "Landing Page" vs "landing"

Can we use any arbitrary values we want for these?  Please clarify in the documentation.
https://developer.roku.com/en-gb/docs/developer-program/discovery/search/prioritizing-authenticated-...
aspiring
0 Kudos
RokuJonathanD
Community Moderator
Community Moderator

Re: SDK documentation: links to fix, missing/broken/etc

"joetesta" wrote:
There is insufficient guidance wrt pageNumber or pageType values:
 https://developer.roku.com/en-gb/docs/developer-program/discovery/search/prioritizing-authenticated-...

Should pages use consistent values for pageNumber (ie should a specific view be assigned a pageNum that's then used consistently for all users, no matter which path they follow to the page; or should the pageNum be incremented arbitrarily as the user steps through the process (such as maintaining a global pageCounter that's incremented on each page in the flow)?

What values may be used for pageType and where does it matter?  Can we create our own arbitrary types?

JD: The idea is to use the provided syntax so the Roku and you can easily identify the page where sign-up abandonments may be occuring...so for page numbering, it should just be based on a single path so that the page can be easily identifed. You don't need to number pages differently based on different user paths. 
0 Kudos
joetesta
Roku Guru

Re: SDK documentation: links to fix, missing/broken/etc

Thanks JD.  Given your reply I am assuming that the answer is "yes" to whether these values can be anything we want to put there.
Can we create our own arbitrary types?
aspiring
0 Kudos
joetesta
Roku Guru

Re: SDK documentation: links to fix, missing/broken/etc

A challenge I'm facing is that our registration and sign-in flows are non-linear.  The "polling" screen could be screen number 3, 4 or 5 depending on the path and options the user chose.  I wish there were more guidance or an example of how this could work in a more complex / non-linear process.

Is it required that RED calls send incremental page numbers, or could we assign a distinct page number to each of our views and then a user might follow a path with non-sequential pageNumbers?
aspiring
0 Kudos
RokuJonathanD
Community Moderator
Community Moderator

Re: SDK documentation: links to fix, missing/broken/etc

"joetesta" wrote:
A challenge I'm facing is that our registration and sign-in flows are non-linear.  The "polling" screen could be screen number 3, 4 or 5 depending on the path and options the user chose.  I wish there were more guidance or an example of how this could work in a more complex / non-linear process.

Is it required that RED calls send incremental page numbers, or could we assign a distinct page number to each of our views and then a user might follow a path with non-sequential pageNumbers?

JD: They can be non-sequential, but the pages numbers should be increasing as a user progresses on a path. So one flow could have pages 1, 2, 4, 7 for example, and another might be 1, 3, 4, 5, 7, and so on.
0 Kudos