Setting "this" in Java

[tmiranda]

Next silly question for the night. If I have a Java method that is called from the STV, how do I set the STV variable "this"?

I tried searching but "this" is just too common a word!

[PLUCKYHD]

This is called directly in the stv after doing something but not setting it to a variable ie

GroupByMethod(mycoolfiles,mycoolmethod)
Sortlexical(this,false,mycoolsorting)

Basically this is refering to whatever you just did above it.

[tmiranda]

Originally Posted by PLUCKYHD

This is called directly in the stv after doing something but not setting it to a variable ie

GroupByMethod(mycoolfiles,mycoolmethod)
Sortlexical(this,false,mycoolsorting)

Basically this is refering to whatever you just did above it.

Yes, I know that part. How do I set "this" in Java so that I can do:

myclass_myMethod()
SortLexical(this, false, 'AnotherMethod")

How do I set "this" in myMethod() so it's accessible in the STV?

[GKusnick]

Just return it as the return value of the method. As Plucky said, "this" is just the final result of evaluating the previous expression. If that expression happens to consist of a Java method call that returns a value, that returned value becomes "this".

Or to say it a different way, it's like every Action widget has an invisible "this = " in front of it. So if your widget says

myclass_myMethod()

that's exactly equivalent to

this = myclass_myMethod()

That's the only way "this" ever gets set. There is no other way to do it.

[tmiranda]

Something is not right with this. In my MultiUser Plugin I created methods that replace the core methods but I could not do thie with Watch() because "this" was not getting set properly. My Java code looks like this:

public static Object watch(Object content) {

   .... do some things ...

   return MediaPlayerAPI.Watch(content);
}

This did not work and I assumed it was because "this" was not getting set properly (the STV checks "this" right after Watch()) but maybe something else funky is going on?

I fixed the problem but I am not 100% satisfied with what I had to do to correct it.

Tom

[stuckless]

Originally Posted by tmiranda

Something is not right with this. In my MultiUser Plugin I created methods that replace the core methods but I could not do thie with Watch() because "this" was not getting set properly. My Java code looks like this:

public static Object watch(Object content) {

   .... do some things ...

   return MediaPlayerAPI.Watch(content);
}

This did not work and I assumed it was because "this" was not getting set properly (the STV checks "this" right after Watch()) but maybe something else funky is going on?

I fixed the problem but I am not 100% satisfied with what I had to do to correct it.

Tom

if you call Watch... you will need to set the UIContext... otherwise, sagetv will not know which UI to play it on... I do this in phoenix... To be really sure, my Watch method requires that the ui context be passed from the stv, so there's no guess work.

[PLUCKYHD]

Originally Posted by stuckless

if you call Watch... you will need to set the UIContext... otherwise, sagetv will not know which UI to play it on... I do this in phoenix... To be really sure, my Watch method requires that the ui context be passed from the stv, so there's no guess work.

I get the UIContext and call watch for all SMM direct from Java. But I call onto the widget chain using the widget api directly to the defaults so all the variables get passed correctly as well as I add static context from java for airing and such variables before executing the widget chain. I haven't had any issues relying on the UIContext from sagex doing this.

[stuckless]

Originally Posted by PLUCKYHD

I get the UIContext and call watch for all SMM direct from Java. But I call onto the widget chain using the widget api directly to the defaults so all the variables get passed correctly as well as I add static context from java for airing and such variables before executing the widget chain. I haven't had any issues relying on the UIContext from sagex doing this.

That's good to know I haven't had any issues with the UIcontext stuff myself... but I just wanted to be sure, in phoenix, that when watch is called, then it has the right context from the start

[PLUCKYHD]

Originally Posted by stuckless

That's good to know I haven't had any issues with the UIcontext stuff myself... but I just wanted to be sure, in phoenix, that when watch is called, then it has the right context from the start

Yeah as long as a create a new context like I mentioned in the other thread I have had 0 reports of it not working.

On that subject I am getting some issues with SetProperty Setting the Server property instead of the extender/local desktop property lately but haven't had a chance to track it down. I don't pass a UIContext but am tempted to start

And believe me MyMovies relies on UIContext from top to bottom from reading the custom properties to playing a file and has been spot on so thanks for that

[GKusnick]

Originally Posted by tmiranda

This did not work and I assumed it was because "this" was not getting set properly (the STV checks "this" right after Watch()) but maybe something else funky is going on?

Did you check your logs for errors? If your method throws an exception (and fails to catch it internally), then obviously its return statement won't be executed and "this" will not be set properly.

[tmiranda]

Originally Posted by GKusnick

Did you check your logs for errors? If your method throws an exception (and fails to catch it internally), then obviously its return statement won't be executed and "this" will not be set properly.

No, but I will. I'll also check the UIContext issue that Sean and Skye pointed out to see if that's the problem.

[stuckless]

Originally Posted by GKusnick

Did you check your logs for errors? If your method throws an exception (and fails to catch it internally), then obviously its return statement won't be executed and "this" will not be set properly.

Originally Posted by tmiranda

No, but I will. I'll also check the UIContext issue that Sean and Skye pointed out to see if that's the problem.

you can check the sagex-apis to see if failed badly... but the Watch() api is kind of odd from what I can recall. It's suposed to return True, i think if it succeeded, or a string if it failed. The string should contain the error message. In some of my cases, it actually returns an obfuscated sagetv object, which is also a normal reply. (I spoke to Jeff to about this behaviour and he did explain it to me, but I sort of forget why.)

[tmiranda]

Originally Posted by stuckless

you can check the sagex-apis to see if failed badly... but the Watch() api is kind of odd from what I can recall. It's suposed to return True, i think if it succeeded, or a string if it failed. The string should contain the error message. In some of my cases, it actually returns an obfuscated sagetv object, which is also a normal reply. (I spoke to Jeff to about this behaviour and he did explain it to me, but I sort of forget why.)

Thanks. OT, but something I always wanted to ask. What's an "obfuscated" Object, why are they used, and where can I read more about them?

Thanks

[stuckless]

Originally Posted by tmiranda

Thanks. OT, but something I always wanted to ask. What's an "obfuscated" Object, why are they used, and where can I read more about them?

Thanks

There are many reasons to obfuscate... but I suspect that sagetv does it to prevent people from de-compiling their code and potentially stealing code or ideas. The process of obfuscating basically rewrites all the bytecode so that the classname, methods, etc, are all very short (like one or two characters) names.

The other reasons run an obfuscator on your code is to simple reduce the physical size of the jar file. Since java has to load all the classes into memory which includes things like classname, method name, etc, then by obfuscating the code, you end up with slightly smaller jar files that consume less memory when loaded.

The other reason to use an obfuscator is to run post processing actions against the code to do optimizations like remove private methods that are never used. Or, remove public methods that are never called (can be dangerous). You can alog create rules that will entirely strip logging from a jar file.

I don't know what sage uses, but I suspect it is either ProGuard or something similar.

Keep in mind, when you obfuscate the code, it will give you a set of files that you can be used to "decipher" stack traces. So, when you see an obfuscated strack trace in the code that is a sage error... when you send it to them... they know exactly where in the code it died... even though you don't