The Media Center Sandbox

So if an Add-In is marked background, the property:

AddInHost.Current.ApplicationContext.IsForegroundApplication

always returns false? If the Add-In is not background, it will always return true?

If this is the case, what is a foreground app that is no longer the foreground app since someone pressed the big green button?

If I have 8 copies of my add-in running and I am currently running yet another add-in, what status can be checked to know that my 8 copies should just keep quiet and do nothing until they have control of the screen?

Zakspeed

I believe 'IsForegroundApplication' checks to ensure you are the MCML page that the user is currenly viewing is your app.

So if you have a dozen copies in the background, those should reply with false.

Can you use a named pipe to try and stop all of those instances running? Or do you really want a half-dozen versions of your app running at the same time?

---

100 downloads a day for Yougle Vista - goin' allright!

Check out http://www.thedigitallifestyle.com/cs/Blogs/developer/default.aspx and http://www.push-a-button.com.au/products/mce

I tested it and if IsForegroundApplication returns true, it will always return true. Even if the app is pushed into the background.

No, I don't want 8 copies of my app running, but there does not appear to be anyway to avoid this.

I have yet to hear about a good reason for MCE stacking applications.

Please, why is this feature useful?

Zakspeed

Here is what I found out in my investigations tonight...

1) A true background application (an application which has its registration XML category set to "Background" as outlined in http://msdn2.microsoft.com/en-us/library/aa468319.aspx) will always return false for ApplicationContext.IsForegroundApplication Property.

2) For any other type of application, the ApplicationContext.IsForegroundApplication Property will return true for all instances of that app even though some instances are technically on the back stack and not truly in the foreground. This is probably due to how the extensibility host is architected to load assemblies -- as far as it is concerned, the assembly is in the foreground.

3) I've only been able to get 7 instances of an application running. Based on your comments this is probably 6 copies too many for you Zakspeed.

4) I doubt 7 instances will happen very often due to the fact we unload applications as Windows Media Center pages or other apps get added to the backstack. For seven to appear I have to add the application launch tile to the Windows Media Center Start Menu and cycle through Launch > Green Button > Launch. If I don't add the application tile to the Windows Media Center Start Menu and the user goes through Program Library the max number of instances you can get is three.

5) Chances are if the user launches your app and navigates elsewhere in Windows Media Center (including launching of other apps) you will only have a single instance, and it will be a new instance. We have a maximum number of eight (8) Windows Media Center pages + app instances. Once the eighth page or app is added, we truncate the end of the stack. If that item is an app we call the apps IAddInModule.Uninitialize method and give the app a small window of time to tidy up before terminating the application. For more information see http://msdn2.microsoft.com/en-us/library/bb189705.aspx. Launching an app, then drilling down a few pages into another single feature (Music, Pictures, Videos) then returning to launch the app in Program Library almost always meant I got a single app.

6) I cannot stress enough that applications should expect and anticipate to be interrupted at any time. For example, if needed, you should be saving state to a common location so any new application instances can pick up that state if launched. The SDK hyperlink in #5 outlines this in some more detail. We architected the Z sample app in the area of its download manager to mitigate this problem. The download manager runs outside of Windows Media Center and does the 'heavy lifting' of long running tasks so the app instance can unload at any time.

7) We are aware of the shortcomings of the multiple instance approach and are planning to change this in a future version of the platform (while maintaining backward compatbility). As to your next question: Sorry, no ETA on when that might be available. Even when you get a single instance model, you will still need to architect the app as outlined in #6.

Hope this helps...

---

Charlie Owen (Microsoft)

Oh, and I would agree that having multiple instances of the application isn't a particularly useful feature when it comes to Windows Media Center apps. :-)

---

Charlie Owen (Microsoft)

Have you tried using a named pipe (or similar method) to STOP multiple instances? Of course, then you have the problem of having to find the currently-running instance and bringing it back to the top...

When you are debugging your app, do you have to manually stop the debugging? If you have threads running, have you tried killing them off in Uninitialise?

It sounds like you must be leaving something open, and your program doesn't officially 'end' until this is complete. I'd see what you can do to kill everything off - or even call 'Application.Halt' if you have to (assuming that's even POSSIBLE from a Media Center app?)

---

100 downloads a day for Yougle Vista - goin' allright!

Check out http://www.thedigitallifestyle.com/cs/Blogs/developer/default.aspx and http://www.push-a-button.com.au/products/mce

I would really like to kill off my app when it gets pushed back.

The problem is knowing when to do it.

Uninitialize does not get called when the user hits the big green button from my app.

Having running threads does not seem to stop my application from exiting when the user presses the back button.

In fact, since it is a seperate app, media center sees fit to just kill it and not allow any normal shutdown processing to continue. I found this out when I had a lengthy shutdown process (not really length, just 40 ms or so), and the process was getting killed anyway.

Zakspeed

Can you share the feature details which warrants shutting down the application when it gets pushed into the background?

---

Charlie Owen (Microsoft)

We have some timers that are used to collect data. Ideally, these timers stop when the application is pushed into the background.

Zakspeed

Yeah, I am running across the same heartache. I am doing a home automation system that connects up with a server via TCP/IP to control lights, heating, etc. Most of the time, the user uses the media PC for doing just the home automation, so they DO hit green button, go to the app to launch, and I end up with 8 (maybe 7) instances hammering the crap out of the server. Add into the mix that they are doing this same thing on an aditional up to 5x XBox's, each doing 7 or 8 concurrent sessions, and it's giving the server a pretty fucking ahrd time. It's a polling mechanism (Hey, I didn't design the server), so we have to poll continuously, and fairly fast to get status updates when lights change. It really sucks that we can't go back to a previously running instance or that the IsForeground doesn't work. We have found that the "Please try and find your application by hitting the back button" went down pretty badly with users, and was pretty suckful. It's easy enuff to tell if you are already running via Mutex's, but you can't do *** about it except pop up the wanky message....

Wow, this forum censors out bad words like ***. Does it do crap and *** as well?

Wow, it's almost the same thrill you get when you're 5 years old, looking up bad words in the dictionary.....

Actually, I've also noticed when I call is Foreground on a thread, it seems to hang indefinately..... Haven't pursued why this is, since the call doesn't seem to do what I wanted (or thought it should do)

You can get around this issue as follows:

Create an IPC mechanism - you choose (mutex, remoting,etc), and have your client listen to it.

When you start up a new instance of your app, ping the IPC mechanism to communicate that a new instance has started.

When the first client receives that message, have it close down gracefully.

You now have only one instance of your app running, giving you what you were after.

If you really want to get clever, have your app save state periodically and then start the new instance with the loaded state from the old instance, so you continue where you left off.

Cheers,
Andrew

Ok, obviously I can tell if I'm on the main PC versus an xbox for this to work, but how can I stop 1 xbox session from shutting down another xbox session? i.e. I need some way of identifying 1 xbox session from another, cause I might start up a new instance on xbox 3, send the shutdown message, and xbox 1 (that only has 1 copy of my app open, and it happens to be up on the screen at the time) gets shutdown. Also, when I am running a remote desktop session "console" returns false, so it sorta looks a bit like an xbox session.

In summary, I'd like to be able to identify separate xbox sessions, vs remote desktop vs 'normal' session. Any ideas?

As an aside, do the XBox's connect using a specific culture? I seem to be getting some wierd Date Parsing errors that are specific to xbox sessions???


TIA,

Matt