The Media Center Sandbox

I am in the midst of refactoring media browser and a real biggy for me is making sure everything is testable and tested.

At the moment most of our UI model objects are inheriting off ModelItem. The problem is that ModelItem has checks built in to ensure its instantiated from a UI thread. Test Unit/Nunit is not ever going to be on the UI thread. So I have to write reflection hacks in my unit tests, something that makes me cringe and cry.

I was wondering if there are any downsides to implementing IModelItem over inheriting off the built-in ModelItem?

---

- Sam
samsaffron.com

Moving to IModelItem has made an enormous performance improvement.

I would love to hear for Charlie if implementing IModelItem ourselves is a recommended practice

---

- Sam
samsaffron.com

Nice find, can you elaborate on the perf boost you are seeing?

Well we do a background scan of our entire library on startup. But all of our model items have this archaic requirement that they need to be instantiated from the ui thread. So we defined a factory that just pumps a stack full of these puppies so whenever we need a "ready" modelitem then we ask the stack for one.

This is ugly as all hell and once I got rid of that requirement I am able to take up less UI time doing this useless bit of work. It feels so much more stable

---

- Sam
samsaffron.com

jeez these ModelItems are like an application cancer, I finally decouple all of my object so I can run unit tests on them ... and lo and behold my base objects are using things like Choice which is also a ModelItem

so frustrating.

I can't wait for Charlie's reply.

"We never really intended you to test any of the models you create. If you want to test stuff you will need to create shadow objects for all the model items, and keep your model items nice and thin"

---

- Sam
samsaffron.com

Sam,

The UI thread approach is standard amongst all client-side Microsoft development platforms (WinForms, WPF, and MCML, and possibly even Silverlight) - I don't know the technical ins-and-outs, but I imagine it's something to do with accessing memory cross-thread.

btw, could you not just post your question without the sarcasm? 

Cheers,
Andrew

Sounds to me like testing was an after thought or perhaps even a non-starter in mcml development. I understand some of the internal calls are still based off of .Net 1.1 code - unless this has changed in win7. I would like to know what code coverage the folks at eHome are running. And how are they doing it, because as already mentioned earlier this is very important for us 3rd party devs who need this in place.

 

---

blog.manghera.com

Andy,

Firstly my initial post was without the sarcasm, the sarcasm was just added after hours of bashing my head against the wall. I apologize for getting frustrated.

BTW, where are the Unit tests in the Z application?

I'm afraid you are wrong on this one. WPF has thread checking built in, but is very testable. You always have a dispatcher and it does not dictate a Model that you need to use, implementing interfaces for model is in fact a best practice. I can instantiate an ObservableCollection collection just fine from my WPF unit tests. Same goes for WinForms write your models however you want to as long as you implement interfaces for binding.

Now I can run this in my unit tests:

typeof(Microsoft.MediaCenter.UI.Application).GetMethod("RegisterUIThread", BindingFlags.NonPublic | BindingFlags.Static).Invoke(null, null);

But this is wrong on multiple levels

Cheers
Sam

---

- Sam
samsaffron.com

Hmmm... interesting. What happens in a WPF app if you create an ObservableCollection on a worker thread, and then bind it to a XAML element?  Does it still work?

Cheers,
Andrew

As a general rule, other ModelItems should refer to IModelItem instead of ModelItem whenever possible.

Why do you need to refer to Choice instead of IValueRange?

---

This posting is provided "AS IS" with no warranties, and confers no rights.

David Teo
SDET
Microsoft Corporation

"What happens in a WPF app if you create an ObservableCollection on a worker thread, and then bind it to a XAML element? Does it still work?"

It works fine, ObservableCollection is safe for multi threaded use, the only thing the constructor does is initialize a synchronization object.

---

- Sam
samsaffron.com

Charlie says: See what David said. As a tester of our platform he is way more qualified to provide an opinion.

---

Charlie Owen (Microsoft)

Charlie:)

David,

So reading in to this. Having our model items implement IModelItem instead of inheriting off ModelItem is a good practice. (eg. an entity that represents a movie or a folder)

Internally the framework deals with the interfaces and does not expect stuff to be ModelItems, it does not depend on any of the additional methods that ModelItem exposes.

Its good point about IValueRange, the thing is that both Choice and BooleanChoice expose some extra functionality that goes beyond the interface. I will not have too much of a problem implementing this myself.

Thanks for your response
Sam

---

- Sam
samsaffron.com

Charlie: Thanks for passing the buck! :)

sambo99,

I would talk to Charlie about including such information into the SDK in the future.

Thanks!

---

This posting is provided "AS IS" with no warranties, and confers no rights.

David Teo
SDET
Microsoft Corporation

Additional information from one of our Windows Media Center developers...

It depends on what you’re going to do, but 90% of the time it’s easier to derive from ModelItem, simply because you don’t have to implement things like FirePropertyChange.

Either one is fine, the difference is mainly in how much work you have to do to fill out the interfaces. Deriving from ModelItem requires a constructor, plus whatever properties you want, and that’s it. IModelItem requires you to implement the entire interface.

When deriving from ModelItem, though, it must be at the root of your tree. Since ModelItem is not a MarshalByRefObject, it cannot be remoted. Also, it’s sometimes better to do the extra work if you want to control your class hierarchy tightly.

---

Charlie Owen (Microsoft)