Roku Developer Program

[belltown]

"ioan" wrote:
I tried "ui_resolutions=hd,fhd", "ui_resolutions=hd" and "ui_resolutions=fhd". All look fine. I'm recalculating the position and size for all elements to look good on any resolution. I know that the image for "easy add" in HD doesn't fit on the screen... I was too lazy to fix it 🙂 Let me know if you saw a problem where the text overlaps, because I can't reproduce it.

The value you should use for ui_resolutions should represent the canvas size that your code is drawing to. It has nothing whatsoever to do with what resolution it will run on. So, if your code assumes a canvas size of 1280x720, then use: ui_resolutions=hd. However, if your code computes sizes and coordinates automatically based on the values of ifDeviceInfo.GetUIResolution() then it may not matter what value you use.

If you have a specific image that is a particular size, assuming it was made to fit within a specific screen canvas size, then you may find it helpful to specify the associated ui_resolutions value (otherwise you'd have to specify multiple image sizes).

When your code runs on any device that is NOT listed in your ui_resolutions list, then the UI will scale AUTOMATICALLY for that device. This automatic scaling ONLY happens for a resolution you do NOT specify. If you specify fhd,hd for example, and you draw a 640x360 image that was designed to take up half the width and height on an HD canvas, the image will render correctly on the hd device (because it was sized for a resolution you specified), will also render somewhat okay on an SD device (because it will be automatically scaled, since you didn't specify sd), but will NOT render correctly on the FHD device (because it won't automatically scale if you specified fhd and it's running on an FHD device -- so you'd either need a separate image sized for FHD dimensions, or only specify ui_resolutions=hd).

[EnTerr]

"ioan" wrote:
I tried "ui_resolutions=hd,fhd", "ui_resolutions=hd" and "ui_resolutions=fhd". All look fine. I'm recalculating the position and size for all elements to look good on any resolution. I know that the image for "easy add" in HD doesn't fit on the screen... I was too lazy to fix it 🙂 Let me know if you saw a problem where the text overlaps, because I can't reproduce it.

indeed, i did [spoiler=screenshot:3ojanfqk][/spoiler:3ojanfqk]

"EnTerr" wrote:
On a stylistic note, seems to me better would be if in the edit screen there are no separate "* Edit blah" buttons next to the fields but instead the cursor walks the fields directly and pressing OK atop one goes into entry edit screen.

Can I focus on a Text field? I didn't know I could do that...

You can focus on Buttons. Is that not enough? 8-)

Yes, the problem probably is with the basic authentication. Probably D-Link cameras sends back a "realm" attribute that my application doesn't handle yet. I have the algorithm to handle the "realm" attribute working on the PC, I just have to port it to BS.

Yes, it does. roUrlTransfer has disability on this but see https://forums.roku.com/viewtopic.php?f ... 15#p159384

< HTTP/1.0 401 Authorization Required
< Server: alphapd
< Date: Sun Mar 26 16:30:20 2017
< Pragma: no-cache
< Cache-Control: no-cache
< Content-type: text/html
< WWW-Authenticate: Basic realm="DCS-934L"

Anyway, it shows in the beginning only if you don't have any cameras added. As soon as you add a camera (aka really use the application) the message goes away. I'll get rid of the message in the next update.

Oh, i see what you did there - not having cameras from registry makes it show the popup. It also does it after i delete the (last) camera.

By the way, is there a limit on how often I can submit updates to my channels?

Not that i know of.

[ioan]

"belltown" wrote:

The value you should use for ui_resolutions should represent the canvas size that your code is drawing to. It has nothing whatsoever to do with what resolution it will run on. So, if your code assumes a canvas size of 1280x720, then use: ui_resolutions=hd. However, if your code computes sizes and coordinates automatically based on the values of ifDeviceInfo.GetUIResolution() then it may not matter what value you use.

If you have a specific image that is a particular size, assuming it was made to fit within a specific screen canvas size, then you may find it helpful to specify the associated ui_resolutions value (otherwise you'd have to specify multiple image sizes).

When your code runs on any device that is NOT listed in your ui_resolutions list, then the UI will scale AUTOMATICALLY for that device. This automatic scaling ONLY happens for a resolution you do NOT specify. If you specify fhd,hd for example, and you draw a 640x360 image that was designed to take up half the width and height on an HD canvas, the image will render correctly on the hd device (because it was sized for a resolution you specified), will also render somewhat okay on an SD device (because it will be automatically scaled, since you didn't specify sd), but will NOT render correctly on the FHD device (because it won't automatically scale if you specified fhd and it's running on an FHD device -- so you'd either need a separate image sized for FHD dimensions, or only specify ui_resolutions=hd).

Man, this makes it SO MUCH easier... Few times I wanted to start a thread how bad is that Roku doesn't auto scale for whatever resolution. I don't know how I ended up with ui_resolutions=hd, fhd in the manifest so I had to take care of scaling all elements by hand.  Here is some code I wrote to make sure everything looks good in hd and fhd and I call those functions on all UI elements:

function getScaleWH()
    di = CreateObject("roDeviceInfo")
    ds = di.GetDisplaySize()
    return {dw: ds.w, dh: ds.h, w: 1280, h: 720}
end function

function screenWH()
    ds = getScaleWH()
    return {w: ds.dw, h: ds.dh}
end function

function calculateWH(w as float, h as float)
  ds = getScaleWH()
  return {w: ((ds.dw * w)/ds.w), h: ((ds.dh * h)/ds.h)}
end function

sub calculateTranslation(obj as object)
  ds = getScaleWH()
  obj.translation = [((ds.dw * obj.translation[0])/ds.w), ((ds.dh * obj.translation[1])/ds.h)]
end sub

sub calculateObjWH(obj as object)
  ds = getScaleWH()
  if obj.width <> invalid then
    obj.width = ((ds.dw * obj.width)/ds.w) 
    if obj.height <> invalid then
      obj.height = ((ds.dh * obj.height)/ds.h)
    end if
  else if obj.minWidth <> invalid then
    obj.minWidth = ((ds.dw * obj.minWidth)/ds.w) 
    obj.height = ((ds.dh * obj.height)/ds.h)
  else if obj.itemSize <> invalid then
    obj.itemSize = [((ds.dw * obj.itemSize[0])/ds.w), ((ds.dh * obj.itemSize[1])/ds.h)]
  else 
    ' nothing yet
    print "nothing to size"
  end if
end sub

I was designing the UI in HD but then it didn't look well when FHD was in the manifest (which I thought it was necessary to support FHD)... Well, I guess I'll have to delete some of my code and make everything simpler. BTW, which screen size should I make the UI for (aka "what value should I have in ui_resolutions)? Majority of TVs now are FHD, right?

[ioan]

"EnTerr" wrote:

Yes, it does. roUrlTransfer has disability on this but see https://forums.roku.com/viewtopic.php?f ... 15#p159384

< HTTP/1.0 401 Authorization Required
< Server: alphapd
< Date: Sun Mar 26 16:30:20 2017
< Pragma: no-cache
< Cache-Control: no-cache
< Content-type: text/html
< WWW-Authenticate: Basic realm="DCS-934L"

I don't use roUrlTransfer at all im my code because of this problem. I use "roStreamSocket" and I handles the basic authentication similar with what is in the post you quoted. The basic authentication with realm is a little different though. The server provides a challenge using the realm and you have to create the response accordingly. Quote from RFC 1945:

The realm attribute (case-insensitive) is required for all
  authentication schemes which issue a challenge. The realm value
  (case-sensitive), in combination with the canonical root URL of the
  server being accessed, defines the protection space. These realms
  allow the protected resources on a server to be partitioned into a
  set of protection spaces, each with its own authentication scheme
  and/or authorization database. The realm value is a string, generally
  assigned by the origin server, which may have additional semantics
  specific to the authentication scheme.

I'll have to implement this soon because I expect many cameras uses this authentication scheme. 

[belltown]

"ioan" wrote:
which screen size should I make the UI for (aka "what value should I have in ui_resolutions)? Majority of TVs now are FHD, right?

Roku's official position, according to https://sdkdocs.roku.com/display/sdkdoc/Specifying+Display+Resolution is:

Recommended Intended Resolution

For Scene Graph applications, Roku recommends you design and develop for an intended 1080 screen resolution. But for performance reasons, for Roku players and display screens that do not support full high-definition resolution, you should supply both 1080 and 720 graphical images for your application. The Scene Graph application will scale the design elements and the graphical images for the actual supported resolution, but you can achieve the best appearance for all supported resolutions if you provide both resolutions of graphical images. If you can only provide one resolution of graphical images, provide 720 graphical images.

There may be reasons why you wouldn't want to develop in FHD, like not having an FHD-capable TV or Roku player to test on, or being concerned that your package will be too large to store lots of hi-def images. In the end, it comes down to a personal choice.

If you do rely on autoscaling, then be sure to read the "Autoscaling Guidelines" on that same page.

[ioan]

"EnTerr" wrote:
On a stylistic note, seems to me better would be if in the edit screen there are no separate "* Edit blah" buttons next to the fields but instead the cursor walks the fields directly and pressing OK atop one goes into entry edit screen.

Can I focus on a Text field? I didn't know I could do that...

You can focus on Buttons. Is that not enough? 8-)

You got me confused 🙂 You said "get rid of the buttons" and then "you can focus on buttons". How do I get rid of the buttons if I have to focus on the buttons? 

[EnTerr]

"ioan" wrote:
I don't use roUrlTransfer at all im my code because of this problem. I use "roStreamSocket" and I handles the basic authentication similar with what is in the post you quoted. The basic authentication with realm is a little different though. The server provides a challenge using the realm and you have to create the response accordingly. ...

Yeah... but no. You are doing it wrong! 🙂
You are talking here about http digest authentication and this is something that roUrlTranfer already does well via .setUserAndPassword(). So there is no point of reinventing a socket wheel there, esp. given you can do async transfers with roUrlTransfer already.

Now, the issue is with http basic authentication - since some IP cameras (Dlink i saw, Sony i read about etc) only support basic auth and nothing else. Funny story, the cURL library that Roku uses supports basic-auth just fine but seems in the early days of Roku Inc (before there was even a Roku streaming player but only BrightSign signage), somebody decided to make a "principled stand" and intentionally disable that in roUrlTransfer. But forgot to notify the internet appliance makers 🙂 and so now, almost 10 years later we still suffer that somebody's principles. But, as i pointed out, there is fairly easy workaround by adding the right header.

[EnTerr]

"ioan" wrote:

"EnTerr" wrote:
On a stylistic note, seems to me better would be if in the edit screen there are no separate "* Edit blah" buttons next to the fields but instead the cursor walks the fields directly and pressing OK atop one goes into entry edit screen.

... You got me confused 🙂 You said "get rid of the buttons" and then "you can focus on buttons". How do I get rid of the buttons if I have to focus on the buttons? 

I said '''no separate "* Edit blah" buttons next to the fields'''. You can use the buttons as text fields. There is no need to have 2 different entities side to side. Buttons already have a label inside.

[ioan]

"EnTerr" wrote:

"ioan" wrote:
I don't use roUrlTransfer at all im my code because of this problem. I use "roStreamSocket" and I handles the basic authentication similar with what is in the post you quoted. The basic authentication with realm is a little different though. The server provides a challenge using the realm and you have to create the response accordingly. ...

Yeah... but no. You are doing it wrong! 🙂
You are talking here about http digest authentication and this is something that roUrlTranfer already does well via .setUserAndPassword(). So there is no point of reinventing a socket wheel there, esp. given you can do async transfers with roUrlTransfer already.

Now, the issue is with http basic authentication - since some IP cameras (Dlink i saw, Sony i read about etc) only support basic auth and nothing else. Funny story, the cURL library that Roku uses supports basic-auth just fine but seems in the early days of Roku Inc (before there was even a Roku streaming player but only BrightSign signage), somebody decided to make a "principled stand" and intentionally disable that in roUrlTransfer. But forgot to notify the internet appliance makers 🙂 and so now, almost 10 years later we still suffer that somebody's principles. But, as i pointed out, there is fairly easy workaround by adding the right header.

I'm sure you are right and everything could be done with roUrlTransfer, but for me it was easier to use roStreamSocket. I'm not sure how would m-jpeg or rtsp be implemented with roUrlTransfer, but I know how to do it with roStreamSocket. How do you continuously read packets into a roByteArray from the socket using roUrlTransfer?

[EnTerr]

"ioan" wrote:
Man, this makes it SO MUCH easier... Few times I wanted to start a thread how bad is that Roku doesn't auto scale for whatever resolution. I don't know how I ended up with ui_resolutions=hd, fhd in the manifest so I had to take care of scaling all elements by hand.

You are not the only one - i was in the same boat until very recently. I don't think even inside RokuCo there exist an understanding about the auto-scaling ability which was added last year. There was never an announcement, it was never drummed up or explained in a blog post - rather it was quietly tucked under a RSG topic (wrongly so because it applies to SDK1 too)

I was designing the UI in HD but then it didn't look well when FHD was in the manifest (which I thought it was necessary to support FHD)... Well, I guess I'll have to delete some of my code and make everything simpler. BTW, which screen size should I make the UI for (aka "what value should I have in ui_resolutions)? Majority of TVs now are FHD, right?

For my money, 720 (HD) is the way to go over the next few years. Which flies against the official party line but hear me out: the only Roku players that can display 1080 (FHD) images/UI are the 4k ones (that's Roku 4, the Premieres and 4k RokuTVs). All other players display your assets in 720, even when the HDMI output signal is 1080p and video plays in 1080p. Because Roku works in mysterious ways :). And how many 4k players are there as %? Not particularly high. Hopefully the Co will publish some model breakdown numbers - but i am ready to bet that a year from now, when speaking about Roku UI, the native-HD players would still be beating the native-FHD ones 10:1 or more. It will take additional 2 years for the 4k-capable players to overtake the pre-4k ones - at which point it would make sense to convert to 1080 (FHD) assets by pushing a new version.

In addition, FHD UI and assets would burden both the memory and performance of the low-end and older boxes (24xx, 25xx, 27xx, 3xxx), leading to "kaboom!" experiences.

Supporting both resolutions in parallel is a royal PITA and feels to me like the "worst of both worlds" for a small shop. But if one is a big TV network with the money and labor to blow - go ahead, knock yourself out.