Do we really need that many controls in Silverlight?

/

I was digesting Scott Gutherie's blog on Silverlight 2 Beta 2

We ultimately expect to ship over a 100 controls for Silverlight.

It really made me wonder, do we really need that many different types of controls built-in with the default Silverlight installation?

Beta 2 now has around about 30+ controls, and the only one that I've noticed is missing, is the combo-drop down list control.

I'm guessing if they really plan to end up with so many controls, then perhaps they'll start by porting across all the various controls that currently WPF have and Silverlight doesn't.

Edit:

Oh and some sort of Menu control

Lack of statistics for Windows spaces.live.com

/

The statistics capabilities for Windows Live wetted my appetite for better statistics reporting.  Why on earth:

  • Record only up to the last 3 days
  • No user detail breakdown - where from?  Unique visitors?  Returning visitor?
  • How are people finding my blog?  Word of mouth or blog reader or searching for keywords in Google where my blog showed up?

Anyway, the lack of statistics really is beginning to be a pain in the neck, makes me feel that no matter what I do, Windows Live spaces just doesn't support me to grow my blog, unlike other service providers like Blogger or WordPress.  (Both of them easily integrates with Google Analytics).

Which drives people back to use AdWords.

Sure we hate all things Google ;-)
But where's MS's offering?

Silverlight 2 Beta 2 coming really soon

/

All signs points to Silverlight 2 beta 2 coming within the week:

http://blogs.msdn.com/swiss_dpe_team/archive/2008/06/03/silverlight-2-beta-2-available-later-this-week.aspx

http://msdn.technetweb3.orcsweb.com/maximelamure/archive/2008/06/03/new-features-annonced-in-silverlight-2-beta-2.aspx

The biggest news I can find:

  • "Pushing" data from Server to Silverlight:
    • this is a new duplex channel which implements a smart-pull, the client sends a request to the server but the server does not respond unless there's something to say, and the client will just happily wait on that request (Silverlight does have multi-threading). 
    • If this was implemented in AJAX we'd see the browser seems to be waiting for something (a waiting connection progress bar).
    • I guess when the client receives a response, it fires a new request to the server immediately and keep waiting for new messages.
    • Various people have chipped in that they feel this may be cleaner than working with sockets - may be they just didn't like the way sockets sound, perhaps too low level and not abstracted enough ;-)
  • A tab control!
    • Still no combo drop down?
    • Or trees
  • Commercial go-live license
  • Controls are in the runtime now, instead of being packed with your app
    • Bigger initial plugin download but smaller file?
    • I wonder why they don't allow the missing components to be downloaded from a signed-MS redistribution package when you need it, and have Silverlight install that on-demand.  (instead of putting it in isolated storage where it can't be shared with other apps).
    • Flex solutions pack controls into the swf file and no one seems to be complaining

Edit:

  • Sockets goes cross-domain

Doing a simple timeout page with WebClientApplication

/ 
<%@ Application Language="C#" Inherits="Microsoft.Practices.CompositeWeb.WebClientApplication" %>
<script Language="C#" RunAt="Server">

protected override void PrePageExecute(Page page)
{
// True when the current session was recreated with the current request
if (Session.IsNewSession)
{
// redirect if the requested page is not Default or the Timeout page
// or if the request method isn't GET
if ((!(page is Retail.Web._Default) &&
!(page is Retail.Web.Errors.Timeout)) ||
Request.HttpMethod != "GET")
{
Response.Redirect("~/Errors/Timeout.aspx");
return;
}
}
base.PrePageExecute(page);
}
 



This approach relies on the Session.IsNewSession property to tell us if the current session was created with the current request, with a bit of convenience support for the timeout/default pages.


Nikhil has a more detailed solution: Detecting Session Timeout in ASP.NET 2.0 Web Applications if you want to differentiate between



  • new session object and user was really new, (aka no ASP.NET_SessionId)

vs



  • new session object and the user really timed out (aka sorry I was surfing the web and the app timed out)