Category Archives: Notes On the Revolution

No Phone App Left Behind on Win8: A Proposal

winrt

As the Windows 8 tablet comes closer to reality, its success will depend on the amount of content it can provide out of the gate.  The Windows Phone Marketplace has tens of thousands of apps that should be leveraged to provide this content.  The main barrier to this is that the development stacks for Windows Phone and Windows 8 are significantly different.  A simple solution to bridge this gap is to enable Metro Tiles for Silverlight apps running in “classic” mode – something not currently easy to do on the Windows 8 platform.  Here is the background.

There has recently been a revival of chatter about the death of Silverlight revolving around the notion that Silverlight 5 will be the last version of the platform we are likely to see: http://www.zdnet.com/blog/microsoft/will-there-be-a-silverlight-6-and-does-it-matter/11180?tag=search-results-rivers;item2

At the same time, Hal Berenson has lain out an argument for moving the WinNT kernel (MinWin?) into Windows Phone 8, a suggestion backed up by Mary Jo Foley’s reporting that there is a Project Apollo to do something like this. 

The main argument against the claims that Silverlight is dead concern the fact that it is currently still at the heart of Windows Phone development.  If MinWin from the Windows 8 OS for tablets replaces the WinCE kernel on Windows Phones, however, what will be the fate of Silverlight then?

The 40,000 App Bulwark

The most important piece in this complex chess game Microsoft is playing with its various technology platforms — old, new and newer (remember when Silverlight was still bleeding edge just a few months ago?) – is neither at the kernel level nor at the API level nor even at the framework level.  The most important piece is the the app marketplace Microsoft successfully built around the Windows Phone.  In a game in which almost any move seems possible, those apps must be protected at all cost.  30,000 apps, most of them built using Silverlight, cannot be thrown away.

At the same time, Windows Phone is a side-game for Microsoft.  In order to succeed in the smart phone market, Microsoft merely has to place.  The number three spot allows Microsoft to keep playing.

The main event, of course, is the tablet market.  Windows Phone can even be considered just a practice run for the arena where Microsoft really sees its future at stake.  The tablet market is make or break for Microsoft and its flagship product – its cash cow – Windows.

Fragmenting the app market into Silverlight on Windows Phone and WinRT’s three development platforms on Windows 8 seems nothing short of disastrous.  Microsoft needs those 40,000 apps as they launch their new tablet platform.  Without apps, all the innovations that are going into Windows 8 are practically meaningless.

My colleague at Razorfish, Wells Caughey, has recently written about his efforts to create live tiles for “classic” apps on the Windows 8 Developer Preview: http://emergingexperiences.com/2011/11/leveraging-the-windows-8-start-screen/ .  It’s hacky but works and allows several dozen of our apps written in WPF, Silverlight and even Flash to run inside the Metro environment on Win8.

What we learned from the exercise is that Microsoft has the ability to allow live tiles for classic apps if it wants to.  It currently does this for the classic windows desktop which runs as an app from the Metro desktop. 

Were Microsoft to do this, they could easily gain 40,000 apps at the Windows 8 launch.  Silverlight for Phone apps are relatively easy to turn into regular Silverlight apps.  It could be made even easier. 

On top of that, developers already know how to write Metro style apps using WPF, Silverlight and other tools.  Even since the introduction of true multitouch capability in WPF 4 and multitouch controls for Silverlight WP7 development, this is what we have all been working on.

For the moment, however, Microsoft is still apparently pushing for people to learn their new development tools in order to program for Windows 8 Metro and Windows Phone developers are being advised to learn WinJS and the currently somewhat anemic WinRT Xaml platform in order to port their apps.

This is all well and good but why does Microsoft want to leave its greatest asset in the tablet market – its 40K phone apps – on the sideline when enabling live tiles for these apps immediately puts them back in the game?

[note: Microsoft just broke the 40K milestone, so references to “the 30K app bulwark” have been edited to reflect this.]

 

Why ReMIX?

Logo-72dpi-Color

On August 6th, the Atlanta developer community will be hosting ReMIX South, a conference for designers and developers.  This is the second year the conference has been held in Atlanta.  Early Bird tickets can be purchased at http://remixsouth.eventbrite.com .  The official website is at www.remixsouth.com .  Tickets are only $30 through June 28th.

There are lots of great conferences throughout the year such as MIX, An Event Apart and TechEd.  These all tend to be extremely expensive, however.  At the other end of the spectrum are community events such as MadExpo, CodeStock, the various code camps and DevLink.  These are great, inexpensive grassroots level events.  Anyone can speak and the agendas tend to be more or less random.

ReMIX is an attempt to create something in between these two extremes.  We created an event that has the level of speakers you would typically see at all the former two to three thousand dollar events but at the price of a community event.

We do this by spending much of our time throughout the year at all of these other conferences trying to recruit speakers for ReMIX South.  We spend half the year discussing who is a top speaker, who is a rising speaker, and what topics have become important in 2011.  In other words, we spend the majority of our effort simply planning out our speakers the way a painter mixes colors or a chef blends flavors.

We do this in order to provide what is, to our minds, a unique and satisfying experience for our attendees.  Of all the speakers we reached out to, only two of our must haves couldn’t make it: Bill Buxton and Robby Ingebretsen – both had prior engagements.

We keep prices low through very generous sponsorship as well as being very frugal with your money – though controversial, we don’t provide lunch or t-shirts.  While these are standard for most conferences, we found that we can cut the price in half simply by leaving them out.  We also keep your bottom line low by choosing a central location, The Marriott at Perimeter Center, which has free parking.

(As an aside, when I was at An Event Apart, I paid the same amount for my parking as the price of one early bird ticket to ReMIX: $30.)

The other thing we try to do at ReMIX is to provide a designer event that is friendly toward developers, as well as a developer event that is friendly toward designers.

It is also an event that we try to make welcoming for both Microsoft stack as well as non-Microsoft stack developers.  We understand that, depending on where you come from, our agenda will always seem to lean too much in one direction or the other.  To our thinking, this is a good thing.  We want to bring the different communities together. 

Non-Microsoft developers will get a bit of exposure to a world they tend to stay away from, while Microsoft stack developers will have their minds expanded to a world they are not familiar with.  At the end of the day, we all leave knowing a little more about our craft than we did when we came and have a broader understanding of what our craft entails.  Everyone moves out of their comfort zone and becomes stronger for it.

And if you don’t want to have your mind expanded, that’s cool, too.  We have enough sessions to keep anyone inside their comfort zone, if that’s what they want.

Here is what we are offering this year:

The Keynote

Albert Shum is one of the most fascinating people currently working at Microsoft.  He is part of the revolution within Microsoft that transformed their mobile strategy and placed, for once, design at the center of a new technology offering.  Albert led the design team that created the much discussed “Metro” language used originally on Windows Phone and now, according to well-placed rumors, on the Surface 2 and Windows 8.  If you are still confused about what “Metro” actually is, this is your best opportunity to find out – he’ll be at the conference all day and is very approachable.

The Web Track

This is the track we are perhaps proudest of.  If you are a Microsoft stack developer, then you might think of HTML5 as a zombie-like infestation that is taking over and displacing all the technologies you are used to working with.

On the other hand, if you aren’t part of the Microsoft world, you probably are perplexed when people make a big deal about HTML5 and wonder if they are talking about CSS3 + JQuery. 

So what we are offering in the Web track at ReMIX is a bunch of non-Microsoft stack web developers explaining HTML5 to both Microsoft and non-Microsoft developers.  Brilliant, right?

J. Cornelius of CoffeeCup Software will start by presenting “HTML5: Yes Really.”  The title is a joke and if you don’t get it, then you really need to attend.   He will provide the opening overview of HTML5

John Agan, who builds amazing web experiences for Epic Labs, will teach us about JQuery

Josh Netherton of MailChimp will school us on CSS3 in “More Than Just Rounded Corners.” 

Finally, we’ve invited August de los Reyes of Artefact to speak.  If you aren’t familiar with August, he happens to have given the most impressive talk at MIX11 this year – and it was only ten minutes long!You can find a video of his MIX presentation here .  At ReMIX South, August will be presenting an expanded version of his talk 21st Century Design.

Mobile \ Tablet Track

The past year has been spent pursuing the code-once dream for mobile development using tools like Mono, PhoneGap, the Adaptive Web and, most recently, HTML5.  If you’ve been following the trends in iPhone, Android and Windows Phone, you’ll know that this has been a rocky and occasionally treacherous path.  Not only do the different tools not always work … ahem … perfectly, but the rise of tablets is also making it clear that designing and developing for non-desktop computers is a lot more complex than just working with different form-factors.  We’ve invited several Microsoft as well as non-Microsoft stack people to walk us through the variegated world of mobile and tablet development.

Douglas Knudson, Technical Architect for Universal Mind and organizer of the Atlanta Flex User Group, will show us how to use Adobe Air to target multiple mobile and tablet platforms.

Luke Hamilton, Creative Director at Razorfish, will speak on “The Interface Revolution” and cover how to work with all the new devices we are being confronted with as technology keeps progressing.

Shawn Wildermuth, a well known trainer and expert in Windows Phone development, will walk us through the new features being introduced in Windows Phone Mango.

Jeremy Likness will talk about his experience working with Silverlight for tablets.  He will also discuss what we currently know about Windows 8, which is being promoted as a tablet platform that uses both HTML5 as well as a XAML-based language for development.

Rob Cameron, who was also with us last year, is a Microsoft Architect Evangelist.  He will talk, among other things, about developing games for Windows Phone using XNA.

Windows Phone Garage

No pretense of non-Microsoft material here.  Starting in mid- to late-August, the Windows Phone Marketplace will start accepting Mango apps.  This full day dev garage will get you ready for that.  Just bring a laptop and we’ll take care of the rest – by the end of the day you will have an application ready to start making you money. 

mixheadshot_reasonably_small

Unlike other phone garages, this one will be surrounded by top talent in development and design as well as several Windows Phone development MVPs.  If you would like their help, we’ll setup a sign-up sheet so you can arrange to get one-on-one advice about your app.

UX Track

The UX Track has always made the ReMIX conference stand apart from other conference.  This is really the place where we invite speakers to talk broadly about a variety of topics which we place, loosely, under the UX rubric.

Let me point out, first of all, that all of our speakers are amazing.  These are our rock stars. Rick Barraza has become an institution helping developers understand UX and design as well as trying to help devs and designers to work together.  He spoke at MIX this year.  Jenn Downs is simply cool and MailChimp, her company, is widely lauded for breaking new ground in connecting with customers by being hip, playful, cheeky and, of course, extremely useful.  MailChimp has pretty much been invited to speak at every major conference this year.  Zach Pousman and James Chittenden were both extremely popular speakers at last year’s ReMIX.  Zach is an expert in both academic and practical UX, while James is a UX Architect for Microsoft Consulting – you probably didn’t even know there was such a thing.  We are very lucky to have them back.  Designers think Matthias Shapiro is a designer while developers assume he is a developer since he has been so effective in bridging both worlds.  His talk on Motion is a must see.

If you have spent your careers as developers and have never been exposed to the world of UX and design, then the best favor I can do for you is to recommend that you spend your whole Saturday in this track.  You’ll thank me for it.  Really, you will.

Kinect Track

This is very exciting for us.  The Kinect Track is our opportunity to take a new technology, bring together some of the leading experts on developing for the Kinect and hold the first conference event about the Kinect.  Other conferences are beginning to have one or two Kinect talks a piece, if they have any.  At ReMIX, we provide a full day of Kinect content.

All of our Kinect speakers come for the most part from the pages of the KinectHacks website. 

Jarrett Webb is the creator of KinectShop, an application that has given us the best picture so far of how the Kinect and related technologies will one day be used in retail.  He is generously providing the introductory talk on developing for the Kinect.

Zahoor Zafrulla is a Phd candidate at Georgia Tech.  He is making breakthroughs in using the Kinect sensor for education.  His particular interest is in using the Kinect to teach American Sign Language.

Steve Dawson and Alex Nichols wrote the DaVinci Kinect application in November of 2010 – shortly after drivers for building Kinect applications for the PC became available.  It was one of the first apps recognized for successfully pulling off  ‘The Minority Report’ effect and Microsoft later asked them to present it at the E3 conference to demonstrate what Kinect hacking is all about.

Josh Blake is the best known figure in the Kinect world.  Besides being widely recognized as an authority on Natural User Interface concepts, he is also the founder of the OpenKinect community.  There are few people who know more about the growth and future potential of the Kinect technology than Josh.

The final Kinect session of the day will be a panel discussion moderated by Josh Blake with panelists Albert Shum, Rick Barraza, Luke Hamilton and Zahoor Zafrulla.  They will be discussing the influence of TV shows and movies on how we envision the future of technology as well as what the future of technology will actually look like.

Daydreaming about Kinect Fun Labs

cruise-minority-report

While at the CodeStock conference in Knoxville, I had the pleasure of talking with several indie XNA developers about the potential of the Kinect.  They were discouraged, though, at the lack of opportunities for indie developers to create games for the Kinect.  All I knew how to do was create XNA games and put them on a PC with a Kinect hooked up to it – which wasn’t quite what they were looking for.

Then last week at E3 Microsoft announced Kinect Fun Labs.  Currently Fun Labs is a free download for the XBOX with what are basically a few concept apps.  It includes Kinect Me, which scans the player and turns her image into a 3D model (though not, as has been reported, an XBOX avatar that can be used in the rest of the system).  The Kinect then tracks the player and manipulates the model to follow the player’s movements.

Kinect Googly Eyes does basically the same thing with any rectangular object.

And then there are a few additional one-offs that can be downloaded from within the Kinect Fun Labs app.

What is interesting in all this are hints on the official website that we can upload our own apps at some point.  This may be rumor only, of course, and it probably won’t fully satisfy indie developers who would like to make some money off of their games, but once we get past all the ifs and buts …

It would be very cool to have a way to share our Kinect apps – watching demos on Youtube only get us so far.  If the XBOX also supports Silverlight at some point, we will have additionally have a development platform on which to quickly develop Kinect apps.  It’s the stuff dreams are made of.

Silverlight 5, HTML5 and WPF

Last Thursday, Microsoft Evangelists Glen Gordon and Joe Healy held an all-day Silverlight firestarter in Atlanta.  It was a great event and will be travelling to Tampa, FL on 2/22 and Miami, FL on 2/24.

The real fun for me was what occurred afterwards.  Glen organized an Ask the Silverlight Experts panel in the backroom of a nearby sports bar.  After the ‘Bob Muglia Imbroglio’ – I wonder if that will ever catch on -  it was refreshing to hear people whose careers are deeply tied to the future of Silverlight actually speak candidly about it.  MVPs are typically cautious creatures, anxious not to speak out of turn, contrary to Microsoft strategy, or in violation of their NDAs with MS.  Following the Bob Muglia story, everyone is additionally anxious to not be the next person to torpedo Silverlight.

The panel was made up of Sergey Barskiy (Data MVP), Shawn Wildermuth (Data MVP, Silverlight Trainer), Jeremy Likness (Silverlight MVP, author of Sterling), Joel Ivory Johnson (WP7 Dev MVP) and Rob Schiefer (co-author of an upcoming WP7 book).  I was there representing the local Silverlight User Group which I run with Corey Schuman.   Jim Wooley (VB MVP) and Steve Porter (CAD MVP) were in the audience.

The first question asked, and the one that dominated the rest of the night, was to the effect of “What’s up with Silverlight and HTML5?”

I had originally planned to give a recap of all the arguments and theories but realized after attempting to do this for about an hour that I mostly just remember my own arguments and have, in my memory, distorted everyone else’s.

Then I came across this beautiful photo by Philip-Lorca diCorcia — who currently has an exhibit at the David Swirner gallery in New York City if you get a chance to visit – which summarizes everything that was said that night much better than I can.

lorca-dicorcia-wpf

In case it isn’t clear, the two dudes high-fiving each other on the right are Silverlight 5 and HTML5.

Windows Phone 7 Side Loading

Side loading is a topic familiar to Windows Phone developers but not so familiar to those who might need to work with these developers and require an understanding of the functionality in order to be more effective.

Side loading refers to deploying applications directly to a device without going through the official Microsoft Marketplace. You may want to side load an application for prototyping, demos and reviews. 

In an enterprise environment, you may additionally want to side load applications that are intended only for internal consumption. Unfortunately, an enterprise solution is not available for the first iteration of Windows Phone. It may be included in a future release.

The side loading capabilities of Windows Phone 7 are somewhat restrictive. You may side load applications either to a software emulator running on a PC or to a physical device. Side loading to the WP7 software emulator requires the installation of the Windows Phone Developer Tools. In addition to various products (Visual Studio Express, Blend for WP7), the Windows Phone Developer Tools includes the Application Deployment utility which you will use for side loading. You must be running Windows Vista or Windows 7 in order to install the Developer Tools.

The Windows Phone Developer Tools may be downloaded here.

Side loading to a Windows Phone device additionally requires installation of the latest Zune software.

The Zune software may be downloaded here.

Deploying to a WP7 device is similar to deploying to the WP7 emulator. Besides the requirement that Zune software be running in order to deploy to a device, there is an additional restriction that you can only deploy to an “unlocked” developer device. A Marketplace account is required to unlock a WP7 device, and only five three developer devices can be unlocked for each marketplace account. A Marketplace account requires an annual membership fee of $99. A full membership, allowing for the publication of applications to the marketplace, can be purchased here and generally requires a two to three week verification period. Finally, only ten applications may be side loaded onto any device.

Deploying to the Emulator

Once the Windows Phone Developer Tools have been successfully installed, you may side load to the emulator by using the Application Deployment utility. You can find the Application Deployment utility by going to your Start Menu on the taskbar.

taskbar

Select “All Programs” from the Start Menu. Find and open the menu folder named Windows Phone Developer Tools.

admenu

This will open the Application Deployment utility.

ad

The Target dropdown has two entries. From the Application Deployment utility, apps can be deployed either to the emulator or to a device. To deploy to the emulator, select “Windows Phone 7 Emulator” as the target.

You will be deploying a XAP file, which is a file with a “.xap” extension. A XAP file is the basic unit for a phone application, much as an executable is the basic unit for a typical windows application. It includes the code as well as all the images and other assets required to run a specific phone application. Use the browse button to find the XAP file you want to deploy to the emulator.

Once a XAP file has been selected, press the “Deploy” button. If the emulator is not already running, deployment will start the emulator for you.

The emulator is a bare-bones version of the Windows Phone OS. It has most of the functionality found on a Windows Phone device but is lacking many of the applications you will typically find on a standard WP7 device. In fact, the Start screen on the emulator only contains Internet Explorer.

wp7startscreen

Select the right facing arrow at the top right corner to bring up all applications. You will find your newly loaded app on the applications screen.

Deploying to a Windows Phone

Once the WP7 Dev Tools and the Zune software have been successfully installed, you must run the Zune software before attempting to side load. You do not need to be logged into your Zune account in order to side load an app.

zune

While the Zune software is running, open the Application Deployment utility by following the steps enumerated above for side loading to the software emulator.

As pointed out above, the device must be “unlocked” as a developer device in order for deployment to occur.  The device does not have to be unlocked by you.  Hypothetically, you can simply ask someone with an annual Marketplace subscription to unlock the device for you.

Connect your device to your PC using a micro-USB cable (typically included with the device). The lock screen must be slid out of the way for deployment to occur.

In order to deploy to your device, you will select “Windows Phone 7 Device” as the deployment target in the Application Deployment utility rather than “Windows Phone 7 Emulator”.

To finish deploying to an unlocked device, follow the steps outlined above for deploying to the emulator.

* Special thanks to WP7 MVP Joel Johnson for reviewing this document and making necessary corrections to my understanding of how side loading works.

WP7 Tip: disabling the Pivot Control swipe gesture

don't try this at home

A common question on WP7 message boards and mailing lists concerns how to cancel a pivot control’s built-in page swiping when you have another control in the pivot that takes swipe gestures: for instance, a Slider!

The standard Microsoft response to these queries is that you shouldn’t do it.  It creates UX confusion and is a “bad practice.”  The assumption is that users don’t think contextually, and will expect swiping to always do the same thing on a page.  This is one of those “sounds good enough” answers, and seems eminently reasonable with respect to a slider control inside a pivot panel.  Besides, you can always just orient your slider vertically, so there is even an out. 

On the other hand, WP7 textboxes use hold-and-swipe to manipulate the cursor in a textbox.  Is it poor UX or a bad practice to use textboxes inside of a pivot control?  Should I try to find a way to orient my textboxes vertically?  What about the Toggle Switch control?

Consider also that swiping is the quintessential phone gesture.  Every new WP7 control in 2011 will attempt to take advantage of it.  It would be a shame if we couldn’t use any of them with the pivot.

This post will address how to do the unspeakable: add a working, horizontally oriented slider to a pivot control.  If you understand how to add a slider to a pivot, you will be able to add any sort of control to a pivot.  For additional takes on this “Don’t Try This At Home” topic you should read Derik Whittaker’s post as well as Miloud B’s post.

In a nutshell, the keys to making this work are to use the IsHitTestVisible property of the pivot control in order to disable swiping.  Then use the static Touch class’s FrameReported event to determine when to re-enable it.

Create a new project in Visual Studio.  If the Pivot control is not available in your toolbox, right click on the toolbox and select “Choose Items…”  Scroll until you find the Pivot and select it.  Open MainPage.xaml in design view.  Drag the Pivot control into the Content grid.  Grab the sizing handles for the Pivot and drag them around until the Pivot fills the Content grid (everything under the Application Title and Page Title textblocks).

Two pivot panels are initially stubbed in for the Pivot control.  Drag a Slider control into the first panel (“item1”).  If you run the application now, you will encounter strange behavior in which the slider bar is successfully moved when you swipe it, but at the same time the pivot panel also attempts to page to a new panel.

swipeme

To fix this, handle your slider control’s ManipulationStarted event and set the pivot’s IsHitTestVisible property to false in order to disable it while the swipe for the Slider is being handled. 

When the swipe is completed, you will need to re-enable the pivot.  You cannot do this on the MouseLeftButtonUp event since this gets disabled on all child controls when you set IsHitTestVisible to false on a container.  Putting it in the ManipulationCompleted event is possible, but results in inconsistent behavior.

Instead, take advantage of the lower level touch API.  Check to see when an up touch gesture occurs over your slider  and set the pivot’s IsHitTestVisible property to true when it does.  This can be hooked up in the page constructor like so:

Touch.FrameReported += (s, e) =>
{
    if (e.GetPrimaryTouchPoint(slider1).Action == TouchAction.Up)
    { 
        pivot1.IsHitTestVisible = true; 
    }
};

Here is the relevant XAML:

<!--ContentPanel - place additional content here-->
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
    <controls:Pivot  HorizontalAlignment="Stretch" Margin="6,6,0,0" 
                        Name="pivot1" Title="pivot" 
                        VerticalAlignment="Top" Height="595">
        <controls:PivotItem Header="item1">
            <Grid>
                <Slider  Height="107" HorizontalAlignment="Left" 
                            Margin="-4,109,0,0" Name="slider1" 
                            VerticalAlignment="Top" Width="460" 
                            SmallChange="1" 
                            Maximum="100" 
                            Value="30" 
            ManipulationStarted="slider1_ManipulationStarted" />
            </Grid>
        </controls:PivotItem>
        <controls:PivotItem Header="item2">
            <Grid />
        </controls:PivotItem>
    </controls:Pivot>
</Grid>

And here is the code-behind:

public MainPage()
{
    InitializeComponent();
    Touch.FrameReported += (s, e) =>
    {
        if (e.GetPrimaryTouchPoint(slider1).Action == TouchAction.Up)
        { 
            pivot1.IsHitTestVisible = true; 
        }
    };
}

private void slider1_ManipulationStarted(object sender
    , ManipulationStartedEventArgs e)
{
    pivot1.IsHitTestVisible = false;
}

Re-examining WP7 Launchers and Choosers

One of the questions every developer must face when a new technology like WP7 comes on the scene is whether to jump onboard early (in the CTP and Beta stages) or wait until a platform RTMs.  The advantage of the former is that one has a longer lead time to learn the technology and establish oneself as an authority on the technology inside one’s company or on the web.  The advantage of the latter is that one doesn’t waste time learning things about the technology that are in flux and may go away; instead one can wait for the experts to say what they have to say and learn from that.

A possible advantage to deferring the groking of a new technology is that one also has less to unlearn.  Early adopters often make the mistake of assuming that they do not have to re-examine what they already know when the technology RTMs.  The problem for those who defer learning new technologies is that, if they are not careful, they may inherit the bad information disseminated by those early adopters and insiders, and suddenly we are all stuck in a situation where what counts as common knowledge is simply wrong.

Probably the worst case of this for Windows Phone developers occurred with launchers and choosers.  The original metaphor seemed clear enough: launchers are fire-and-forget components, choosers return information.  This turns out not to be completely true, however.  Save operations, which are considered launchers, must return information about whether each save was successful.  They aren’t really fire-and-forget. 

Another early lesson WP7 developers learned was that all launchers and choosers cause an application to tombstone – and thus was created one of the most obscure and difficult aspects of Windows Phone development.  As WP7 went from Beta to RTM, however, it was decided that this didn’t always make sense.  Recovering from tombstoning is time-consuming.  Why force an app to tombstone for something like the CameraCaptureTask when the user will most likely return to the application immediately after the task is completed?  To find out more about deferred tombstoning, see Why Deactivated is Not the Same as Tombstoning.

Just to make things a little more complicated, it isn’t just the four choosers which turn out to not force tombstoning.  MediaPlayerLauncher, one of the eleven launchers, also implements deferred tombstoning.  The PhoneCallTask also does not throw an application into tombstoning mode (additionally, it also never seems to trigger the Deactivated event).  Incoming phone calls, outgoing phone calls, the five choosers and MediaPlayerLauncher all merely suspend (or pause) the application, keeping all the pages along with their state in memory.

If you are confused, welcome to the club.  The original metaphor of having launchers and choosers broke down bit by bit through subsequent iterations of the Windows Phone platform.  Experts quote each other based on these different iterations.  After a while, no one is sure anymore exactly how launchers and choosers work.

The solution, naturally, is to trust but verify everything you read.  You can find out whether an application is actually tombstoned when a task (the generic name for both launchers and choosers) is initiated by placing a simple debug message in the constructor of the page that launches the task.  If the constructor is called when you press back from the task, then your application was tombstoned.  If the constructor is not called, then you know the page has been retained in memory and tombstoning did not occur.

Once you have verified something like this, always write it down somewhere.  Here’s the chart I keep for myself to help remember the behavior of various launchers and choosers.  It is for the RTM version of Windows Phone only.  Please take it with a grain of salt.

Task

Launcher

Chooser

Returns Data

Defers Tombstoning

Suspends Application

CameraCaptureTask

 

X

X

X

X

EmailAddressChooserTask

 

X

X

X

X

EmailComposeTask

X

       

MarketplaceDetailTask

X

       

MarketplaceHubTask

X

       

MarketplaceReviewTask

X

       

MarketplaceSearchTask

X

       

MediaPlayerLauncher

X

   

X

X

PhoneCallTask

X

     

X

PhoneNumberChooserTask

 

X

X

X

X

PhotoChooserTask

 

X

X

X

X

SaveEmailAddressTask

X

 

X

   

SavePhoneNumberTask

   

X

   

SearchTask

X

       

SmsComposeTask

X

       

WebBrowserTask

X

       

Telerik RadControls for Windows Phone: First Look

Telerik has been quick to fill in some of the gaps in Windows Phone development with the new RadControls for Windows Phone.  They made a similar move previously with their support for ASP.NET MVC and, going back even further, jumped in earlier than most control suite developers when Silverlight first came out.  Jumping onto new technologies in this is always a risky proposition – and I am grateful to Telerik for repeatedly doing this.  I truly hope it pays off for them.

While the Windows Phone platform was still in CTP and Beta, the main course for extending the control library was to incorporate open and proprietary projects such as the Silverlight 3 Toolkit, Silverlight 3 SDK, and Silverlight Contrib.  This usually worked but there were always issues with making everything play smoothly. 

As the marketplace rules were released, it also became evident that all controls would have to be compiled against the WP7 runtime, which made things just slightly hairier.  Eventually Microsoft released its own official Silverlight Toolkit for Windows Phone, which provides the most requested UI components: a Pivot Control, Panorama Control and Date and Time Pickers which are consistent with the other native apps built for the phone.

The RadControls for Windows Phone has some overlap with the Silverlight Toolkit for WP7 – no doubt due to fluctuating expectations about what actually would be provided in the Microsoft Toolkit and what would be most useful in a suite.  Duplications include the Date and Time Pickers, Picker, and the Wrap Panel.

The UniformGrid, DockPanel, and Window controls are found in RadControls but not in the Toolkit.  Window is probably one of the most useful of these controls.  It has functionality similar to the ChildWindow control from the Silverlight 3 SDK and allows us to build modal windows – very useful when a MessageBox will not suffice and especially when a phone application requires an initial login – the tales of woe surrounding building an initial login that complies with the Marketplace rules are legendary.  Telerik also continues a tradition of porting nice-to-have WPF functionality to Silverlight.  The standout in their phone suite is the LayoutTransform control which allows us to use Layout Transforms instead of just Render Transforms (for an illustrative example of the difference, see Charles Petzold’s blog entry).

For those having trouble with page transitions, Telerik provides assistance with their implementation of the PhoneApplicationFrame.  There has been a technique going around the internet involving cannibalizing the Silverlight 3 Toolkit and customizing the default PhoneApplicationFrame in order to set all page transitions from one location.  Telerik has simplified the process by providing their own implementation.

The RadControls are still in Beta and I know better than to judge the final work by any issues I find in the preview.  That said, the RadControls for Windows Phone examples seem remarkably and pleasantly performant – especially the page transitions. 

Telerik’s RadControls for Windows Phone are a great addition to the Windows Phone ecosystem.  Telerik is definitely on the right track and their controls provide what any Phone developer would want – an easier way to build interesting and attractive WP7 applications with tools to make development go faster.

Why Deactivated is not the same as Tombstoned

With the transition from the Beta WP7 Dev tools to the RTM, an important and subtle change was introduced to the way launchers and choosers work.  In the beta, it was a given that every time we launched a launcher or chooser from Silverlight, the current application would be tombstoned and the Deactivated event would be thrown on the current PhoneApplicationService object.

With the RTM tools, this is no longer always the case.  Five tasks break this rule: CameraCaptureTask, EmailAddressChooserTask, MediaPlayerLauncher, PhoneNumberChooserTask and PhotoChooserTask.  In each case, while the application may be tombstoned, it also may not be.  In fact, most of the time, it will simply be paused and no tombstoning will occur – the application will not be terminated.  

We can assume that the typical workflow for a chooser task is the following (the images below demonstrate the PhoneChooserTask in action):

phonechooserback

A user performs an action that initiates a task.  The task window opens. The user either completes the task (in this case by selecting a contact) or presses the Back button to cancel the action.  The user is returned to the previous page.  In this case, it makes sense that no termination occurs.  Instead, the app is left in a Paused state much as an app is paused during incoming and outgoing calls – timers are suspended, no events are handled.

[Note: in the RTM, no event is fired when an application goes into a paused state.  At best, you can handle RootFrame.Obscured and RootFrame.Unobscured for incoming and outgoing calls.]

However, the user may also decide to press the Start button at the third step.   At that point it makes sense for termination to occur as it is less likely that the user will backpress back to the app.phonenumberchooser

So when should we handle the deactivated event for the second case where the user moves on and doesn’t complete a chooser task?  We actually can’t handle it when tombstoning occurs because our app is paused and will not respond to any events.

Instead, the PhoneNavigationService.Deactivated event is fired when chooser task (or MediaPlayerTask) is initiated.  This despite the fact that we don’t know (and can’t know) at this point whether the app will actually be tombstoned.

So far so good.  We may unnecessarily be writing objects to storage if the app isn’t ever tombstoned, but it’s better to be safe than sorry.

What is peculiar is that when we return to the app – either through the first scenario above or through the second deviant scenario – PhoneNavigationService.Activated is always thrown.  There’s a symmetry to this.  If the Deactivated event is called and we back into the application, then the Activated event will be called. 

The somewhat annoying thing is that the PhoneApplicationService should have enough information to avoid firing false Activated events unnecessarily.

No matter.  There is a simple trick for finding out whether an Activated event is real or fake – whether it truly follows a tombstoning of the application or is simply thrown because Deactivated was previously called.

Use a flag to find out if the App class was newed up.  It only gets newed up in two situations – when the application is first launched and when it is recovering from tombstoning.  Set the flag to false after the App class has finished loading.  If a chooser is launched and the application is paused but not tombstoned, the flag will still be false.  If tombstoning occurs, the flag will be reset to true.

private bool _isNewApp = true;

private void Application_Launching(object sender
    , LaunchingEventArgs e)
{
    _isNewApp = false;
}

private void Application_Activated(object sender
    , ActivatedEventArgs e)
{
    if (_isNewApp == true)
    {
        // a real tombstone event occurred
        // restore state
    }
    _isNewApp = false;
}

If you are handling tombstoning at the page level, you can similarly use a flag to determine whether the page was re-newed or not.

bool _isNewPage = true;

public MainPage()
{
    InitializeComponent();
}

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    if (_isNewPage)
    {
        //restore state
    }
    _isNewPage = false;
}

The important thing to remember, though, is that the Deactivated / Activated events are not synonymous with tombstoning.  They simply occur alongside of tombstoning – and in the special cases described above occur when no tombstoning happens at all.

Back-Chaining in WP7

Customizing App.xaml.cs

The Windows Phone 7 navigation system has certain limitations from a development perspective.  Chief among these are an inability to inspect the navigation backstack, an inability to remove items from the backstack, and an inability to navigate multiple pages on the backstack.

Because we are only able to programmatically back-navigate one page at a time, a technique has been devised in the developer community called back-chaining.  Back-chaining simply involves setting certain flags in your pages so that, if anyone ever backs into the page, it will continue to navigate backwards.  In this way, we can chain several back navigations together until we arrive at the page we want to stop at.

Here is a basic implementation that forces any back-navigation to always return to the first page in an application when this code is placed in every PhoneApplicationPage:

bool done;

protected override void OnNavigatedTo(
        NavigationEventArgs e)
{
    if (done && NavigationService.CanGoBack)
        NavigationService.GoBack();
}

protected override void OnNavigatedFrom(
    System.Windows.Navigation.NavigationEventArgs e)
{
    done = true;
}

Instead of repeating this code in every page, however, we can centralize it in the App class.  Additionally, we can provide extra methods for more complex navigation such as going back a certain number of pages or going back to a particular page wherever it is on the backstack.

We can do all of this from the App class because of an event on the PhoneApplicationFrame called Navigated that allows us to centrally hook into every navigation event in our applications.

In the default Windows Phone Application template, the PhoneApplicationFrame is instantiated in the App.InitializePhoneApplication method in the App.xaml.cs file.  We can declare our new handler for the event somewhere in there:

//boilerplate code
RootFrame.Navigated += CompleteInitializePhoneApplication;
//new code
RootFrame.Navigated += RootFrame_Navigated;

Next, we need to create some infrastructure code.  For convenience, we want to use static methods and properties in order to make our methods accessible off of the App class.  App.Current, which can be called from anywhere in your application, will return an Application type, which is the base class for App.  Consequently, to access the App class’s RootFrame property (which is boilerplate if you use one of the default project templates), you have to write code like this:

var rootFrame = ((App)App.Current).RootFrame;

A static member of the App class, on the other hand, can conveniently be called like this:

App.DoSomething();

Because we are spreading logic between several page navigations and consequently several calls to RootFrame_Navigated, our infrastructure will need to keep track of what we are trying to accomplish between all of these navigations.

The current implementation will include five methods for back navigation, a simple GoBack, GoBack for a number of pages, GoBack to a named page, GoBack to the first page, and GoBack past the first page.  The last is equivalent to exiting the application (it also doesn’t work, by the way, and I’ll talk more about that later).

Here is the implementation for the first back navigation — which is simply a standard one page back navigation placed in a more convenient place – as well as a property to expose CanGoBack:

public static void GoBack(string pageName)
{
    CurrentMode = GoBackMode.BackToPage;
    BackPageStop = pageName;
    GoBack();
}

private static bool CanGoBack
{
    get
    {
        var navFrame = App.Current.RootVisual
            as PhoneApplicationFrame;
        return navFrame.CanGoBack;
    }
}

GoBack can now be called from anywhere in a Silverlight application like this:

App.GoBack();

Our infrastructure code also requires an enum to keep track of these navigation types:

private enum GoBackMode
{
    Default = 0,
    BackNumberOfPages,
    BackToPage,
    Home,
    Quit
}

private static GoBackMode CurrentMode 
{ get; set; }

To implement going back a given number of pages, we will create a static property to track how many pages we need to go back and expose a method to start the GoBack chain:

private static int GoBackPageCount
{ get; set;}

public static void GoBack(int numberOfPages)
{
    CurrentMode = GoBackMode.BackNumberOfPages;
    GoBackPageCount = numberOfPages;
    GoBack();
}

The magic is what happens in the RootFrame_Navigated method, which is triggered every time we arrive at a new page in the application.  We check to see how many pages we have traversed through the backstack.  If we have gone far enough, we stop.  If not, we call App.GoBack():

static void RootFrame_Navigated(object sender
    , NavigationEventArgs e)
{
    switch (CurrentMode)
    {
        case GoBackMode.BackNumberOfPages:
            if (CanGoBack && --GoBackPageCount > 0)
            {
                GoBack();
            }
            else
                CurrentMode = GoBackMode.Default;
            break;

The setup code for going back to a named page tracks the targeted page name rather than the number of pages traversed:

private static string BackPageStop
{ get; set;}
public static void GoBack(string pageName)
{
    CurrentMode = GoBackMode.BackToPage;
    BackPageStop = pageName;
    GoBack();
}

The code fragment in the switch statement in RootFrame_Navigated parses the name of the page we have arrived at (e.Content returns the full class name along with its namespace but does not return the “.xaml” extension) and then compares it against the page we are trying to reach:

case GoBackMode.BackToPage:
    var pageName = e.Content.ToString();
    var periodPosition = pageName.LastIndexOf(".");
    if (periodPosition > -1)
        pageName = pageName.Substring(periodPosition + 1);
    if (CanGoBack && pageName != BackPageStop)
        GoBack();
    else
        CurrentMode = GoBackMode.Default;
    break;

The syntax for returning to MyPhoneApplication.Page1.xaml looks like this:

    App.GoBack("Page1");

If there are multiple instances of Page1 on the backstack, this implementation will stop at the last one.  If Page1 does not exist on the backstack, the routine will not stop until it finds the first page of the application.

GoHome is fairly straightforward.  It continues stepping backwards until the CanGoBack property returns false.  CanGoBack returns false on the first page of the application but returns true for every other page:

public static void GoHome()
{
    CurrentMode = GoBackMode.Home;
    GoBack();
}
    case GoBackMode.Home:
        if (CanGoBack)
            GoBack();
        else
            CurrentMode = GoBackMode.Default;
        break;

Finally, it would be really nice to be able to implement a Quit method.  Hypothetically, we could just navigate past the first page of an application to exit.  Taking advantage of the infrastructure we have written, the code would look like this:

public static void Quit()
{
    CurrentMode = GoBackMode.Quit;
    GoBack();
}
    case GoBackMode.Quit:
        GoBack();
        break;

Sadly, however, this doesn’t work. We cannot programmatically back navigate past the first page of an application.  When we try, the navigation is automatically cancelled and a NavigationFailed error is thrown. 

Since back-chaining as an exit strategy does not work, an alternative way to exit a Silverlight application is outlined here: How to Quit a WP7 Silverlight Application .  Unfortunately, the marketplace guidelines say that an application cannot have unhandled exceptions.  I’m not currently clear on whether this would apply to throwing an exception that is understood an controlled (hence handled) but at the same time intentional.

A word of caution:  Back-chaining causes flickering, and the more pages you navigate through, the worse the flickering gets.  This is because every page tries to display itself as you navigate past it.   A quick fix for the flickering problem is to set the RootFrame’s Opacity property to zero when you begin and complex back navigation and then set it back to one when you complete the navigation [thanks go to Richard Woo for pointing this out to me.]

For copy/paste convenience, here is the entire back-chaining code base:

RootFrame.Navigated += RootFrame_Navigated;
#region go back methods

private enum GoBackMode
{
    Default = 0,
    BackNumberOfPages,
    BackToPage,
    Home,
    Quit
}

private static GoBackMode CurrentMode 
{ get; set; }

public static void GoBack()
{
    var navFrame = App.Current.RootVisual
        as PhoneApplicationFrame;
    navFrame.GoBack();
}

private static void ShowRootFrame(bool show)
{
    var navFrame = App.Current.RootVisual
        as PhoneApplicationFrame;
    if (show)
        navFrame.Opacity = 1;
    else
        navFrame.Opacity = 0;
}

private static int GoBackPageCount
{ get; set;}

public static void GoBack(int numberOfPages)
{
    CurrentMode = GoBackMode.BackNumberOfPages;
    GoBackPageCount = numberOfPages;
    ShowRootFrame(false);
    GoBack();
}

private static string BackPageStop
{
    get;
    set;
}
public static void GoBack(string pageName)
{
    CurrentMode = GoBackMode.BackToPage;
    BackPageStop = pageName;
    ShowRootFrame(false);
    GoBack();
}

private static bool CanGoBack
{
    get
    {
        var navFrame = App.Current.RootVisual
            as PhoneApplicationFrame;
        return navFrame.CanGoBack;
    }
}

public static void GoHome()
{
    CurrentMode = GoBackMode.Home;
    ShowRootFrame(false);
    GoBack();
}

public static void Quit()
{
    CurrentMode = GoBackMode.Quit;
    ShowRootFrame(false);
    GoBack();
}

static void RootFrame_Navigated(object sender
    , NavigationEventArgs e)
{
switch (CurrentMode)
{
    case GoBackMode.BackNumberOfPages:
        if (--GoBackPageCount > 0 && CanGoBack)
        {
            GoBack();
        }
        else
        {
            ShowRootFrame(true);
            CurrentMode = GoBackMode.Default;
        }
        break;
    
    case GoBackMode.Home:
        if (CanGoBack)
            GoBack();
        else
        {
            ShowRootFrame(true);
            CurrentMode = GoBackMode.Default;
        }
    break;
    case GoBackMode.BackToPage:
        var pageName = e.Content.ToString();
        var periodPosition = pageName.LastIndexOf(".");
        if (periodPosition > -1)
            pageName = pageName.Substring(periodPosition + 1);
        if (CanGoBack && pageName != BackPageStop)
            GoBack();
        else
        {
            ShowRootFrame(true);
            CurrentMode = GoBackMode.Default;
        }
        break;
    case GoBackMode.Quit:
        GoBack();
        break;

    }
}

#endregion