In wrapping up the Roku project; there are just two more things to talk about. First is that the screen stack isn’t as sacrosanct as the documentation would leave you to believe, and the other is Flight Rising’s disappointing response.
Screen Stack
The Screen is the basic tool that Roku uses to draw something to the TV. Screens are used to do everything from stream video, draw dragons, and present UI elements. If you’ve seen it on a Roku, it was presented using some sort of Screen. Not, this is not just the roScreen object, but a class of objects whose only defining factor appears to be the use of Screen or Dialog in the name. According to the documentation, Screens are maintained in a stack with the newest Screen on top and being shown, and older screens being maintained but not visible. Think of it as a stack of pancakes, where your user can only pour syrup on and eat the top pancake, but you can finish cooking or even add extra butter to other pancakes. In theory this means you can leave old screens up as your user delves deeper into the screen tree.
Unfortunately, in practice this doesn’t appear to be the case. What I found was that there were a number of screens that would crash the hardware if presented when other screens were already being shown. I can understand potential design reasons for not having certain screens stack. If you’re at a keyboard screen entering a movie name… why do you need a PIN screen to pop up. It is a bit heavy handed to break paradigm in order to force design constraints and if that was the intent then the program should simply crash. However, some of the screens that cause the crash are screens I would expect to be able to display at any time, like the roOneLineDialog screen which is used as a “Waiting” indicator. And the crash of the hardware is generally considered a dire failure. For these two reasons I believe this to simply be a bug in BrightScript.
Regardless, the solution is the same. Instead of using a stack of screens, I wrote a simple handler that uses roImageCanvas to keep the application, and then opens and closes a single screen on demand and passes information between them. Because of how simple my interface was this was very easy, a more complex interface would be more difficult to write this way. But this a Roku being controlled with a TV remote, complex UI should be avoided anyways.
Flight Rising’s Response
Whenever you play with someone else’s toys, you have to respect their rules. Which is why one of the first things I did when starting this project was review Flight Rising’s “Terms of Use” and “Rules and Guidelines“. A few things leaped out at me
- Flight Rising condones selling art and “tangible merchandise” based on their IP for Real World Money. There are some limitations, but they have to do with scale.
- Flight Rising supports displaying Flight Rising dragons on personal websites provided credit is attributed to Flight Rising
- Flight Rising prohibits 3rd party tools that modify the game state in any way.
- Flight Rising prohibits 3rd party tools that “generate an excessive amount of concurrent connections or potentially damage site stability”
My take away from this was “We love ppl to do things with our stuff, just make sure we get credit and don’t break the game”. This was perfect. I had no intention of selling this, no intention of changing the game state, and minimizing connections was a great goal to work towards. Just to make sure everything was above board, I send Flight Rising a service ticket that outlined what I was doing, my expected connections, and asked for any guidance they might have.
I received no reply.
Once the project was completed I posted about it on the Flight Rising Forums. My post was deleted and I got the following message from the Flight Rising Team
As the program pulls information directly from the Flight Rising website, we must ask that you stop using the program and do not advertise or distribute it.
This was a bit of a shock. I had expected, at most, a stern warning to abide by their Terms of Use, give them credit, not hit the servers too often, etc. etc. After I didn’t get a response for a couple of weeks, I wasn’t expecting anything.
I’m not content with the reasoning given. Their Terms of Use give several examples of them being ok with information being pulled directly from their website, and no examples of where that would be prohibited. The dragon images I use are the same images that Flight Rising provides tools for you to link to from Twitter, forums, and random website of your choice. Additionally, this attitude is opposed to their embracement of community work seen elsewhere.
Ultimately, I decided not to pursue the issue. My original goal with this project was something from my SO and goal has been met. While I am disappointed that no one else will be able to use this, the potential audience for this is ridiculously small and I believe it will be a better use of my time to move onto the next project.
2 Comments