Archives For ria

Silverlight Browser…Favorites

June 18, 2009

(If you’re new to this series I recommend catching up on the first set ofposts here)

In my last post I built out the navigation and history management pieces of the Silverlight browser. In this post I’ll build out the favorites management piece of the browser.

I started off by adding the Silverlight.Navigation.Favorites project to our solution. Here’s waht the project looks like:

slbfavorites001projectstructure

All of this is pretty straightforward, and fairly similar to to the Silverlight.Navigation.History project.

FavoriteItem. This represents a single page in the appp that you want to mark as a favorite. It has two properties, a uri (where the thing is) and a name (whatever you decided to name the favorite).

FavoriteItemCollection. A simple ObservableCollection of FavoriteItems. Seriously, that’s it. Nothing more to see here. Move on.

FavoritesManager. This is an abstract class that is responsible for managing an application’s favorites. This class provides mechanisms for adding and removing favorites as well as setting a custom home page within the application. This class also defines abstract Save and Load methods which inheritors are responsible for implementing. The intent of these methods is to read and write to the inheritor’s choice of persistent storage.

IsolatedStorageFavoritesManager. This is a concrete implementation of the FavoritesManager class. As with our IsolatedStorageHistoryManager, this class saves and loads favorites information to and from isolated storage. Real simple.

From a UI perspective, there were really only two things that were done. The first was to implement a Favorites control in our Silverlight.Navigation.Controls project. This is simply a ChildWindow that contains a ListBox which binds to a FavoritesManager FavoriteItems property. I then added a Favorites button to the NavigationToolbar to launch the window.

I also added several buttons to the NavigationToolbar for home page functionality:

  1. Set as Home Page – this will replace the home page specified by the application map with the current page.
  2. Use Default Home Page – this will replace the user specified home page with the home page specified the application map.

(In writing this I realized I should have added a Home button, I’ll add it to the features list, which I haven’t created yet.)

The implementation is a snap. I just added a FavoritesManager parameter to the constructor of our Browser control:

slbfavorites002implementation

I’ve issued a new release on the CodePlex site for this project that contains the functionality discussed above. You can download the release here. I’ve also put this app up on my website here. Per Tim Heuer’s post on Silverlight 3 beta install guidance, I customized the install experience to let folks know if they need Silverlight 3 and what it means to install the beta version of Silverlight 3 at this point in time.

What’s next? Good question, I’m glad you asked. Quite honestly I’m not sure just yet. This entire effort was an experiment to see if it would be possible to provide a consistent UX to both in and out of browser scenarios for Silverlight 3 navigation applications. I think we can call the experiment a success. The next step is to wait until July 10th, when Silverlight 3 goes RTW. At that point in time I’ll update the project to Silverlight 3 RTW runtime and start looking at making these controls into something more “real”, whatever that means.

In silverlight , , ,
permalink

Silverlight Browser…History

May 30, 2009

FINALLY!!!! I’ve had the code for the post ready to go for quite some time, I just haven’t had time to write it up properly due to a number of external commitments.

(If you’re new to this series I recommend catching up on the first set of posts here.)

In my last post I built out the mapping portion of the Silverlight browser. In this post I’ll build out the Navigation and History management pieces of the browser. This post is the entire reason I started this little experiment. Let me give you a little background in case you haven’t been following the series.

There are two features in Silverlight 3 that I’m excited about. The first is the Out of the Browser experience (don’t you dare call it SLOOB, seriously just don’t). This allows you to install* Silverlight apps onto a client machine that can run outside of the browser* in a disconnected mode.

*install – It doesn’t install in the typical sense, you won’t see anything in add/remove programs. It places a shortcut on your desktop and/or your programs menu. This shortcut then calls a launcher to get things up and running.

*outside of the browser – While the app isn’t technically running in Firefox, IE, etc. it is still operating in a browser sandbox, which means no direct access to the local system.

The second feature I’m excited about is the navigation framework. This framework allows you build structured apps that can levergate the browsers history and navigation functionality to make moving around your app more intuitive for your users. Additionally, this framework allows you to leverage things like deep linking and SEO for your Silverlight apps. Pretty dang cool if you ask me!

The problem is when you marry these two features, that is build a navigation app that can run out of the browser. Once you take the app out of the browser, your user no longer has access to things like the forward and back buttons, the address bar, history, favorites, etc. Since Silverlight is all about great and consistent user experience (UX), this is problem is a major shortcoming. This project attempts to bridge the gap.

OK, enough rambling, let’s get to the code. I started off by adding the Silverlight.Navigation.History project to our solution. Here’s what the project looks like:

slbhistory001silverlightnavigationhistory

There’s nothing too complex, but here’s a brief description of each class:

HistoryItem. This represents a page/control/whatever you’ve navigated to within the application. There are only two properties, a uri (where the thing is) and a timestamp (when you went there).

HistoryItemCollection. Yup, you guessed it, this simply a collection of HistoryItem objects. There are a handful of methods in here that return items based on date (i.e. today, this week, last week, etc.), but that’s really it.

HistoryItemComparer. This is a helper class used by HistoryItemCollection. It implements IEqualityComparer<T> to compare HistoryItems. I implemented this class because I wanted the methods in HistoryItemCollection to only return distinct HistoryItem objects by uri. So the Equals method of this class simply inspects the uri’s of two objects to determine equality.

HistoryManager. This is an abstract class that is responsible for managing an application’s history. This class provides mechanisms for adding and removing items for history as well as getting all items for the application’s current session. This class also defines abstract Save and OnLoad methods which inheritors are responsbile for implementing. The intent of these methods is to read and write to the inheritors choice of peristent storage.

IsolatedStorageHistoryManager. This is a concrete implementation of the HistoryManager class. This class saves and loads history to and from isolated storage. Nothing tricky about it.

Now that we have our objects in place, let’s take a look at the controls. The first thing I did was to start playing around with the NavigationToolbar control. Here’s how it looks now:

slbhistory002navigationtoolbar

The first thing you’ll see is a Back and Forward button. These are akin to the same buttons you’re used to using in the Internet browser of your choice. As you start to move around the Silverlight application these buttons will become enabled/disabled appropriately. To make this happen I simply hook into the Browser control’s NavigationFrame Navigated event set the properties based on the NavigationFrame CanGoBack and CanGoForward properties.

Next you’ll see a ComboBox that contains a list of all uri’s the user has visited during the current session, with the current uri selected. This data comes from the HistoryManager class discussed above. (As I write this I realize I intended this to be a smart combobox, allowing users to type in uri’s, but I only implemented a simple combobox. I’ll need to address this in a future release.)

Finally we have the History button. This will pop-up a window that display all the uri’s a user has visit during their multiple uses of the application. Once again, this data is provided by the HistoryManager class. This control also allows the user to clear history. Notice, I didn’t implement a confirmation when you clear history? This was intentional. Read the book Why Software Sucks and What You Can Do About It <<INSERT LINK>> to find out why.

To make all this work is pretty simple:

 slbhistory003implementation

In my demo project’s Application_Startup event handler, I just instantiate a new HistoryManager object (in the case of the demo we’re using the IsolatedStorageHistoryManager object) and provide that to the constructor of the Browser object along with ApplicationMap. Here’s what we get when running out of the browser:

slbhistory004outofbrowser

(Notice the Back and Forward buttons are enabled. Also we have a list of uri’s we’ve visited during the app’s current session.)

slbhistory005outofbrowser

(Here we see the app’s history.)

I’ve issued a new release on the CodePlex site for this project that contains the functionality discussed above. You can download the release here.

I’ve also updated the app up on my website here. Per Tim Heuer’s post on Silverlight 3 beta install guidance, I customized the install experience to let folks know if they need Silverlight 3 and what it means to install the beta version of Silverlight 3 at this point in time.

Next up I’ll build out a way to manage favorites.

In Uncategorized , , ,
permalink

Silverlight Browser…Mapping

April 30, 2009

(Note: if you’ve just stumbled upon this post, please be sure to read the first three posts in the series here, here, and here to get an understanding of what we’re trying to achieve and where we’re at.)

In my last post I built out the shell we are going to need for our browser. After I did so I realized there was a key mistake. In that version of the code I had placed the menu and application path components within the navigation toolbar. The problem with this approach is that if I choose to configure the navigation toolbar either to always be hidden or only display when running out of the browser, I’ll lose the functionality of these components when running in the browser as they will be hidden. To correct this issue I moved the menu and application path components to the browser itself. I also added display properties to the browser to allow a more granular control of when these components should be displayed. Now that we’ve gotten this issue squared away let’s start moving forward.

Our next task is to built out the menu and application path components our browser will consume. My initial thought was to follow the pattern ASP.NET uses with it sitemap, sitemappath, and menu components. I went so far as to download the .NET Framework source code from here to take a look at how Microsoft does it. While I was fairly impressed with what I saw, I felt that it was just a bit too much for the task at hand, so I decided to only use the pieces that I thought were appropriate for our task.

After I had a general design direction I decided to get to work. The first think I did was to add a new project entitled Silverlight.Navigation.Mapping to our solution. Here’s what the current version of the solutions looks like:

silverlightnavigationmapping

In the Silverlight.Navigation.Mapping project it all starts with the MenuItem class. This is an abstract class that only contains a three properties the following three properties:

Description- a long description of the menu item (for tool-tips).
ImageUri - the uri of an image to use to represent the menu item (optional).
Title – the title of the menu item to use in visual display.

There are three classes that then inherit from the MenuItem class:

HomeMenuItem – this represents the “home page” of the application and simply contains a ContentUri property that points to the page.

MainMenuItem – this represents a top level menu item of the application. This class has one property SubMenus, which is a collection of SubMenuItems. A MainMenuItem itself doesn’t point to a page, it just serves as a way to logically group pages together.

SubMenuItem – this represents a page within the application. The ContentUri property points to the page, and the Parentproperty serves as a reference to the MainMenuItem containing the submenu.

You’ll note here that I’ve essentially limited the depth of the application to two nodes (Main Menu and Submenu). This was an intentional decision. Often times I come across apps with really deep menuing structures where it’s very easy to get lost and I’d like to avoid that, at least for the time being. I probably shouldn’t force this decision and allow implementers to make an app as confusing as they want, but this can be addressed at a later date.

Next up is the ApplicationMapclass. This is an abstract class that represents the map of an application. The properties and methods of the class are pretty self-explanatory. The key properties are the abstract HomeMenuItem and MainMenuItems properties. Inheritors of this class are responsibly for defining the implementation for this properties.

Lastly we have the XmlApplicationMapclass. This class inherits the ApplicationMap class and implements the HomeMenuItem and MainMenuItems properties by loading their values from an xml document. Pretty simple, and fairly consistent with the ASP.NET model

The UI implementation is pretty simple at this point. As you’ll see in the picture below, I’ve added several new controls to the project.

silverlightnavigationcontrols0120

ApplicationMapPath- similar to ASP.NET’s SiteMapPath, this just keeps track of where the user is in the application.

MainMenu – this simply display the main menu items defined for the application.

SubMenu- this is used to display the submenu options for a given main menu.

The Browser control has an ApplicationMapPath control and a MainMenu control. When the user clicks a main menu item the SubMenu control is displayed for the main menu. When a submenu item is clicked the app navigates to the page defined by the submenu item and the ApplicationMapPath control is updated to show the path to the current page.

The actual implementation is a snap. If you look at the demo project you’ll see I created an ApplicationMap.xml file that contains the definition of our application. I also created some pages under the Views folder. These views aren’t much of anything to look at right now, but they help to illustrate the point.

If you look in Application_Startup method of App.xaml.cs you’ll see the following code:

0120codesnipper001

Here’s what’s going on:

1. I create a new instance of the XmlApplicationMap class using the ApplicationMap.xml file I created in the project.

2. I create a new instance of the Browser control from Silverlight.Navigation.Controls, passing in the XmlApplicationMap class as the constructor’s parameter.

3. I set couple of UI preferences (DisplayNavigationToolbar and IsNavigationToolbarExpanded) on the browser.

4. Finally, I set the root visual of the app to the instance of the browser, and voila, my menus and application map are up and running. Both in and out of the browser!

In Browser:

0120inbrowser1

Out of Browser:

0120outofbrowser

I’ve issued a new release on the CodePlex site for this project that contains the functionality discussed above. You can download the release here.

I’ve also put this app up on my website here. Per Tim Heuer’s post on Silverlight 3 beta install guidance, I customized the install experience to let folks know if they need Silverlight 3 and what it means to install the beta version of Silverlight 3 at this point in time.

In silverlight , , , ,
permalink

Silverlight Browser…Building the Foundation

April 15, 2009

So, in my first and second posts in this series I laid out the justification and high level requirements for a Silverlight browser. In this post I’ll walk through building the basic shell for our browser. This isn’t anything overly cool or sexy, but it has to be done as it’s the foundation for the rest of the project.

First a little housekeeping. I created a Visual Studio solution named Silverlight.Navigation to house the source code for this endeavor. The solution, as you can see below contains three projects.

Soluction Structure

Silverlight.Navigation.Controls – This is where most of the work will be taking place. This project will contain the necessary controls and infrastructure for the Silverlight browser.

Silverlight.Navigation.Demo – This is a small Silverlight demo application we will use to consume the controls created in Silverlight.Navigation.Controls.

Silverlight.Navigation.Demo.Web – This is the website used to host the Silverlight.Navigation.Demo application.

Also, the UI for this initial portion of the project is intended to look the way it does. This is just an experiment after all and I don’t want anything looking too finalized or polished as it might distract us from what we’re trying to accomplish.

Now that that’s out of the way let’s get to the task at hand. The first thing we need to do is define what exactly it is I’m building in this phase of the project.

  1. A navigation container (or toolbar) that can be used to hold all the navigation features (i.e. menus, breadcrumbs, address bar, etc.) that we want to build into the browser. This container should be expandable and it should have some options around when it’s displayed.
  2. The browser shell. This will contain our navigation (above) as well as a way to display navigated content.

Ok, easy enough, let’s move on to the implementation. Here’s the structure of the Silverlight.Navigation.Controls project

Silverlight.Navigation.Controls

The first thing I did was to create the navigation toolbar (NavigationToolbar.xaml). The UI is simple enough at the moment. It’s nothing more than an Expander (new to Silverlight 3), with three TextBlock placeholders for where our future features will go. I added an IsExpanded property to the control to allow consumers to control the IsExpanded state of the control’s Expander control

Next up I wanted to create an enumeration that defined the values for when the navigation toolbar was to be displayed. I created an enumeration named DisplayNavigationToolbar (I know, really original) in the Enums.cs file. I gave the enumeration the following values: Always, InBrowser, None, OutOfBrowser.

The last step was to create the browser (Browser.xaml). This is nothing more than a StackPanel with our NavigationToolbar and a TextBlock placeholder for our navigable content. Since we don’t have any content yet, I choose to use the TextBlock placeholder here so you could see where the content will reside when running the app. Once we starting adding some content we’ll replace this TextBlock with a NavigationFrame.I added a couple of dependency properties to the browser. The DisplayNavigationToolbar property allows consumers of the browser to control when the toolbar is display by setting it to one of the values of the corresponding enumeration. The IsNavigationToolbarExpanded property allows consumers to control whether or not hte toolbar is expanded by default.When the browser loads we simply set the NavigationToolbar’s IsExpanded property to the value of the browser’s IsNavigationToolbarExpanded property. We then check whether or not the app is running offline (via App.Current.RunningOffline) and set the visiblity of the NavigationToolbar appropriately. No black magic, pretty straightforward.

That’s it. Seriously. Oh, wait you want to see it work? Ok, let’s wire it up in the demo project. Here’s the structure for the demo project:

Silverlight.Navigation.Demo

Pretty basic at this point. It will start to grow as we add navigable content.

(While not shown here, I did modify the AppManifest.xml to suppor the out of browser experience.)

Main.xaml is the control that contains our browser. As you might expect, I had to add a namespace declaration for Silverlight.Navigation.Controls in the markup in order to get access to our newly created browser control. I thought that was all I would need to do, however, the browser would never render. This was because I also needed to add namespaces for the System.Windows.Controls in the System.windows and System.Windows.Controls.Navigation assemblies, as show below:

mainxaml

Once I did this the browser rendered no problem. As you can see above, I set the navigation toolbar to only display when running out of the browser and to expanded by default.

In Browser Experience:

In Browser

Out of Browser Experience:

out_of_browser

I’ve decided to house the source code for the project on codeplex. The code associated with this post is available here.

I’d say we’ve successfully delivered on phase 1. Next up creating the application map. This will allow us to define the structure of our applications and create controls (i.e. menus) that can consume the map. Stay tuned…

In silverlight , , , , ,
permalink

Silverlight Browser…Requirements

April 9, 2009
So before I just go off and starting coding this thing, I thought it’d be a good idea to flush some high level requirements. There are two main reasons I’m doing this:
  1. To set expectations for anyone reading this post or interested in the code.
  2. To define success for myself. It’s very easy when start endeavors such as this to get so lost in the details that you lose site of what you were trying to accomplish. Eventually you just give up.

These aren’t going to be anything formal, just some notes about what to expect, and to get this thing rolling.

Here we go…

The first thing I though I’d do is come up with a really rough wireframe of what the heck I’m talking about. So, here it is:

silverlight browser wireframe

silverlight browser wireframe

 Let’s run through the features at a high level:

  • Navigation Manager -This will be the hub of navigation. Think [insert your favorite browser here]‘s nav bar. This will enable users to navigate back and forth in the app, see their current location in the app, type in uri within the app for navigation, view history, set favorites, etc.
  • Application Path - Think breadcrumbs. This will show the user the path that was taken to get to the current location within the app.
  • Menu - Just like it sounds.
  • Navigation Container - The thought here is that while these navigation controls are nice to have, and required in SLOOB scenarios, you probably don’t want to have them visible all the time. We may want to hide it altogether when running in the browser and then display it in a SLOOB situation. Furthermore, when it is visible you may want it to be collapsible in some sense, allowing the user to easily get to it and even pin it without taking up real estate your application could be using.
  • Navigation Frame - This is the Silverlight 3 control, no need to elaborate.

Obviously these are some pretty high level descriptions. Before diving into each feature we’ll need to examine them in more detail to flush out the exact functionality we’re looking for. But, hey, at least this gets us going.

Where to go from here? I’m all about low hanging fruit and quick iterations, so I think the best place to start will be to frame out the browser and build out the Navigation Container. In my next post I’ll lay out the requirements for the container and either build it as a part of that post or the following post, we’ll see what happens.

In silverlight , , , , ,
permalink

Do we need a Silverlight Browser?

April 8, 2009

Stop. Don’t say it. I know what you’re thinking. Adam has been taking the crazy pills. Well, if I have, I’m not telling you, but that in no way relates to this topic.

As you’re hopefully aware there are countless cool and useful features in Silverlight 3. Just check out Tim Heuer’s post for a full run down of all the Silverlighty goodness that’s coming your way. Two of the features I’m most excited about are Silverlight Out of Browser experiences, or SLOOB, and the Navigation Framework.

(A quick sidenote to the SLOOB haters out there, and I know there are some, and I know some of them personally. Yes, I’m aware SLOOB is still operating in the browser sandbox, which means your app can’t access the file system directly. Yes, I’m aware that you can’t print in SLOOB. Yes, I’m aware you can’t style the chrome of a SLOOB app. And, yes, I’m aware Adobe AIR doesn’t have these limitations. The fact is it’s only a matter of time until Silverlight addresses these issues, so I’m not too worried about it. ‘Nuf said.)

So, when Silverlight 3 was announced I did what any self respecting developer would do, I downloaded the beta bits and started playing right away. During the first pass through of the features I was pretty impressed. I coded up some demos for work  and for the local user group and that was that. Then while I was presenting the demos at an internal meeting I noticed something that I didn’t call out at the time because I didn’t know what to make of it.

My demo consisted of a four or five page Silverlight 3 Navigation Application that can run out of the browser. While running in the browser it was great. I had the Uri in the address bar, I had full history, I had easy navigation with the browser’s back and forward buttons, I could bookmark, etc., etc. However, when I ran the app out of the browser I realized all of this functionality was missing. Luckily no one caught it at the meeting and called me out on it because I had no answer for it.

My first thought was that maybe I didn’t enable something in app.xaml or maybe I missed some new control, but then Tim Heuer posted this entry about the navigation framework. Note he goes in and manually adds back and forward to his control, toggling visibility based upon whether or not the app is running in or out of the browser. From a UX perspective this is a bit problematic for me. If I create a SLOOB app that utilizes the navigation framework, my users are going to be in for a rude awakening when they take the app offline. They’ll have no way to navigate the app unless I take the time to to add the code just like Tim did. Granted, it’s easy enough to do, but to me it’s almost so easy that it shoud be part of the framework.

So, in my opinion, yes, we do need some type of browser control in the Silverlight 3 navigation framework to accomodate SLOOB scenarios. As I started thinking about a bit more, I also realized there’s also no way to really define the structure of your Navigation Application. It’d be nice if Silverlight 3 stole a page (no pun intended) from ASP.NET and provided features similar to Web.sitemap, Menu, and SiteMapPath. This would allow developers to define the structure of their apps, and then bind these navigation controls to the application map. These sure would be some nice features in my opinion.

I could just leave at that and say, “Hey Silverlight team, I’m not moving to Silverlight 3 unless these issues are addressed.” However, I’m not that kind of guy, and if you’re reading this you’re probably not either. I think Silverlight 3 is a great product, and I’m going to step up and see if I can’t make at least an attempt to address these missing features. In following posts I’ll start by laying out the basic requirements for each feature and then walk through the features as I start to build them out.

Stay tuned…

FYI – I originally hadn’t planned to have my first post be on this topic. I was planning to start a throwdown series between different presentationi patterns (i.e. MVC, MVP, MVVM, MVVMP, etc.) I still plan on doing the series over the next couple of weeks, but this topic was too compelling to stay at the bottom queue.

In silverlight , , , , ,
permalink