Why are the ApplicationBar objects not FrameworkElements?

Also phrased as "Why can't I databind to the AppBar" or "Why are my named AppBar objects always null in the code-behind?" and so on. (This may also be incorrectly phrased as "Why isn't the AppBar a DependencyObject?" but being a DependencyObject doesn't really buy you anything other than an easy way to check if you're on the UI thread... the magic comes from FrameworkElement ).

There are two basic reasons for this.

Firstly, the ApplicationBar is not a Silverlight element and thus not all Silverlight concepts apply to it. For example, you would expect that the Background could be set to any kind of brush - SolidColorBrush, LinearGradientBrush, and so on - but because the AppBar is actually rendered by the Windows Phone shell, it only supports a solid colour. You might also expect to be able to put arbitrary Content inside the buttons, or to apply RenderTransforms to the menu items, and so on. And you should be able to put it anywhere on the screen with HorizontalAlignment / VerticalAlignment, right? Again, none of these things are supported by the underlying shell UX, so they would all have to throw exceptions or no-op when called. And where's the fun in that?

Secondly, the content models in Silverlight 3 do not support controls with multiple collections of items. Some of the built-in elements have multiple collections - for example, Grid has the Children collection in addition to the RowDefinitions and ColumnDefinitions collections - but these are not actually usable outside of the "core" (they rely on PresentationFrameworkCollection, which is an internal class, and in order to maintain portability across platforms we are not adding anything phone-specific to the "core"). For the AppBar, we want both a Buttons collection and a MenuItems collection, and that's just not doable in a clean, strongly-typed API (there are hacks, such as making the AppBar a generic container and then hoping that developers only put buttons and menu items into it, but they're not good design). Silverlight 4 has addressed this limitation with the DependencyObjectCollection<T> class, but Windows Phone is based on version 3, not 4.

That said, it is possible to make some FrameworkElement-derived wrappers for the AppBar if you're willing to do a bunch of work and be diligent about not relying on all the unsupported features or violating rules about what things can go in what collection. It's not something we'd like to ship in the core product though due to all the caveats.