SageTV Community  

Go Back   SageTV Community > SageTV Development and Customizations > SageTV Studio
Forum Rules FAQs Community Downloads Today's Posts Search


SageTV Studio Discussion related to the SageTV Studio application produced by SageTV. Questions, issues, problems, suggestions, etc. relating to the Studio software application should be posted here.

Thread Tools Search this Thread Display Modes
Old 12-16-2009, 05:30 PM
razrsharpe razrsharpe is offline
Sage Icon
Join Date: Sep 2008
Location: Boston, MA
Posts: 2,111
Getting a valid UIContext from 3rd party apis

As some of you know jphipps and i have been trying to get the ortus api to reliably figure out the UIContext from within the api without having to pass down the UIContext from the STV every single time. I talked with Sage support and they pointed us in the right direction to create a work around until they update their api to support GetUIContextName() for third party apis. They said that they plan to make the UIContext() work for third party api's the way it should in the next version so this is only a temporary solution.

Method A:
This works in an automated fashion in that you do not need to pass anything from the STV to your api. Basically you need to parse the UIContext from the thread name, store that in a ThreadLocal variable and use that variable whenever you need a UIContext().

There are a couple of places when the thread name does not include the UIContext and you need to do something different... Method B... (there may be others but we haven't run into them yet... ):
  • ApplicationStartup hook
  • BeforeMenuLoad hook of the Main Menu the 1st time the Main Menu is loaded (near as i can tell the UIContext does not get set until the end of the hook)
  • Forked() threads
Method B

In cases where you need a UIContext but the thread name does not contain a valid UIContext you need to pass the UIContext from the STV to a method that stores the passed UIContext for that thread (in the same ThreadLocal variable from method A).

Hopefully this is useful to some of you. If you have any questions just ask... I'm not a UIContext expert but learned a fair amount about it with this exercise...

An excerpt of our code to help the explanation

  • UIC.StoreUIContextFromThread() - Parses the thread name and stores the UIC in the UIC ThreadLocal variable
  • UIC.StoreUIContextName( String UIC_Str ) - Stores UIC_Str in the UIC ThreadLocal variable
  • UIC.GetUIContextName() - returns the String representation of the current thread's UIContext.
  • UIC.GetUIContext ()- returns the UIContext representation for the current thread's UIContext... for sagex so you do not need to create a new UIContext(UIC_Str) all the time

import sagex.UIContext;

public class UIC
    private static ThreadLocal UIContext = new ThreadLocal();

    public static String GetUIContextName() {
        return (String) UIContext.get();

    public static void StoreUIContextName(String UIC_Str) {

    public static UIContext GetUIContext() {
        return new UIContext(GetUIContextName());

    public static void StoreUIContextFromThread() {

        if (UIContext.get() == null) {

            Thread t = Thread.currentThread();
            String tname = t.getName();
            String uiname = tname.substring(tname.lastIndexOf("-") + 1);
            //Some Error Checking to make sure we found a valid UIContext

Server 2003 r2 32bit, SageTV9 (finally!)
2x Dual HDHR (OTA), 1x HD-PVR (Comcast), 1x HDHR-3CC via SageDCT (Comcast)
2x HD300, 1x SageClient (Win10 Test/Development)
Check out TVExplorer
Reply With Quote
Old 12-16-2009, 06:13 PM
stuckless's Avatar
stuckless stuckless is offline
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,713
Good job Razrsharpe. I spoke with sage support about this as well (many months ago), and they suggusted the same path.

I didn't implement it into the sagex.apis because I wasn't convinced that it would be reliable. So, i'm interested in your testing to see how it works out. The issue that I saw with using the ThreadLocal is that once a thread local variable is set, then the assumption is that sage will ONLY ever use that thread for that given UI context. I'm not sure this is the case. ie, if Sage uses thread pools, then you could get some contamination.

The approach that I started, but never finished, was to ALWAYS figure out the UIContext each time it was needed (using the thread naming hack). It was be slightly more overhead, but it would be more reliable as well.

If you continue to use the ThreadLocal approach (if it proves sucessful) then you might consider changing it to an InheritableThreadLocal, since that would allow all child threads created from the current thread to automatically inherit the ui context variable.

Keep me posted on how this works out. This is important for phoenix as well.

thanks for the info.
Reply With Quote
Old 12-16-2009, 07:44 PM
jphipps jphipps is offline
Sage Expert
Join Date: Aug 2006
Location: Maryland
Posts: 512

That InheritableThreadLocal seems to work pretty well from my preliminary testing... I tested it from a Fork() in the STV ( which doesn't have the context name in the thread name) and a spawned thread from java, and it seem to carry the UIContext through to both...

Thanks for the tip...

Reply With Quote
Old 12-16-2009, 10:05 PM
razrsharpe razrsharpe is offline
Sage Icon
Join Date: Sep 2008
Location: Boston, MA
Posts: 2,111
Sean, like Jeff said thanks for the tip on the InheritableThreadLocal. As we find issues / successes with this method we'll post the info here so we all know whats going on.

By looking through the log and paying attention to the thread names it appears that a given thread is only used for a single UIContext. Only further testing will confirm this but so far it looks promising.

Hopefully, any of these methods are only temporary fixes until Sage releases their next code base. Jeff from sage (narflex) was initially concerned about the amount of overhead keeping track of the UIContext for all methods would add to the core api but then after thinking about it some more he realized/determined that they only need to keep track of it for reflected (ie third party) methods and says that will only be a minimal amount of overhead. So in the next api release they will fix GetUIContextName to work like its supposed to ... who know when that will be though, hence the time spent on the work around...

Server 2003 r2 32bit, SageTV9 (finally!)
2x Dual HDHR (OTA), 1x HD-PVR (Comcast), 1x HDHR-3CC via SageDCT (Comcast)
2x HD300, 1x SageClient (Win10 Test/Development)
Check out TVExplorer
Reply With Quote

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Do I need 3rd party security? cupp SageTV Placeshifter 3 04-14-2009 07:08 AM
Where are all the 3rd party developed themes? LehighBri SageTV Beta Test Software 1 08-15-2007 10:33 PM
3rd party upnp applications mortenwe SageTV Studio 4 03-26-2007 12:54 PM
launch 3rd party apps? carlumich SageTV Customizations 12 06-06-2004 04:56 PM
UIRT to control 3rd party components m0ng00se30 Hardware Support 8 05-20-2004 05:12 PM

All times are GMT -6. The time now is 06:04 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, vBulletin Solutions Inc.
Copyright 2003-2005 SageTV, LLC. All rights reserved.