Windows 8 Syncing: Cool or Creepy?

I'm the first to admit that I have not had a good time with Windows 8. Probably part of the reason is that I've been using it on a non-touch laptop only. I like many of the features (such as the awesome Task Manager), but I've mostly been fighting with the Modern App side. It seems like the Pictures app comes up when all I want is the desktop Preview application. And the Video app does not recognize the files on my Mac partition, but Media Player on the desktop works fine.

This laptop was the only Windows 8 device that I've had in my collection of devices.

A Little Creepy
It was the only device until recently, that is. A few week ago, I got a Surface 2 tablet, and I must admit that Modern Apps are much better with touch. I've spent much more time learning the apps that I had previously ignored on my laptop. (Disclaimer: I got the Surface 2 at a very steep discount.)

But my first experience was just a little bit creepy. When I was setting up the Surface 2, I logged in with my Microsoft account (which is the same account I use on my laptop). That's when I found that the lock screen on my Surface was the same as the lock screen on my laptop (a picture of my cat, Toby).

That was unexpected (and a little bit creepy). I would not be surprised if settings were stored in the cloud with my Microsoft account, but I didn't expect that a lock screen photo would be automatically uploaded and associated with my account.

But I got over that pretty quickly. My next experience was this last week.

Cool or Creepy?
This past week, I finished up my next Pluralsight course which is about localization. In my demos, I changed the language on my OS so that I could show how that impacted the languages that were used by Internet Explorer.

I ended up leaving the language set to French. This really didn't impact the laptop that I was working on because you need to logout/login for the setting to take effect at the OS level. I didn't really think much more about it.

When I went back to my Surface later in the day, I went to type in a web address and found this:

This is the French AZERTY keyboard (as opposed to the QWERTY keyboard). Changing the language on one machine affected the keyboard layout on a completely different machine. When I took a closer look, the language on some of the icons had changed on my Start screen as well:

Mail

Calendar

I'm not sure I like this too much. I know that these sync settings can be changed, but I like to use the default settings for a while before I make any customization. This default behavior seemed just a little bit creepy -- like a bit of my local computer had leaked into the cloud.

(And to emphasize this: while I was writing this post, I changed the keyboard layout on the Surface to French so that I could take a screenshot, and my laptop keyboard changed to the same layout as I was typing.)

So I could see how this could be really cool or really creepy. If I had multiple PCs, it would be nice that they all had the same settings, layout, experience, etc. But with the PC and tablet, I find that I want different settings on each device.

A Good Upgrade Experience
Since I just finished a Pluralsight course, I figured it was a good time to upgrade to Windows 8.1 (before I start my next course). The upgrade experience was painless, just a bit slow. Fortunately, I set this to install when I didn't need my computer.

As a side note: The language and region settings screen is completely different from Windows 8; I'm glad that I finished up my course with the old "dialog" screens as opposed to the new "Modern" screens. It was much easier to show the dialogs on the video.

I've been fighting with parts of Windows 8 for a while. Having the Surface as a touch device has helped me get used to the Modern app paradigm, but it's still not a great experience on a non-touch device. I'm sure that I'll find the balance somewhere.

Happy Coding!

Prism for Windows Runtime (formerly Kona)

Kona, the guidance package from Microsoft Patterns & Practices for writing Windows App Store LOB apps (previously mentioned here: Application Guidance Update: Kona and Prism), has a new name: Prism for Windows Runtime.

Here are some relevant links.

Download from CodePlex:
http://prismwindowsruntime.codeplex.com/

A "Getting Started" article from Brian Noyes:
http://www.silverlightshow.net/items/Windows-Store-LOB-Apps-with-Kona-Getting-Started.aspx

As a reminder, Prism for Windows Runtime and Prism 4 (for WPF and Silverlight) are different packages with different capabilities. As mentioned in previous article, this is primarily due to the differences in the underlying platforms and what makes sense in each environment.

If you build Line of Business applications, and you're moving into the Windows App Store world, it's worth checking out.

Happy Coding!

Book Review: Building Windows 8 Apps with C# and XAML

I recently finished reading Building Windows 8 Apps with C# and XAML by Jeremy Likness (Amazon link).  Unfortunately, I am unable to recommend this book.

Publisher Gambling
I'm going to chalk the primary issues up to publisher gambling.  The technology industry moves quickly (as we all know).  Technical books that are based on a new/updated technology have a very short shelf life -- especially when we have new versions of tools coming out every 9 months.  This means that technical books are written with pre-release versions, and sometimes things change in the final release.

Building Windows 8 Apps with C# and XAML was released in October 2012, which means that it was written with pre-release versions of Windows 8 as well as Visual Studio 2012.  Since I haven't worked with the pre-release tools, I'm not sure how much has changed, but knowing that Jeremy Likness is a good speaker, author, and consultant, I have to give him the benefit of the doubt.

This was a gamble that the publisher lost.

What Turned Me Off
That last thing I want to do is to rip a book apart.  There is a lot of work that goes into working with the technology, writing it down in a way that makes sense, going through the editing process, and releasing it into the wild.  So, I'll just give one thing I had difficulty with.

The first difficulty was with the example in Chapter 2.  This was a "follow along at home" sample.  The scenario was to create a Windows 8 Store Application that did 3 things:

1. Use the webcam to take photos
2. Save photos to the Pictures Library (or SkyDrive, or wherever else)
3. Act as a Share Target for pictures

If you've been following my blog, you know that one of the things I'm most excited about in Windows 8 is the Sharing system (see Steal My Windows 8 Idea: Share with Grandma from last December).  So, I was very glad to get "straight to the point" with a sample I was interested in.

I followed along step by step.  The application would build and deploy successfully.  I could take photos with the webcam.  But I couldn't save, and the app wasn't showing up as a Share Target.  I did what you're supposed to do in this situation: I double-checked the steps to see if I missed anything.  I took a second look at the configuration screens to see if there was anything different or obviously wrong.

I finally figured out what was wrong with the Share Target: In the application manifest on the "Declarations" page, I needed to indicate the "Supported file types" (which is empty by default).  I immediately went back to book to see if I had missed something.  The section that talked about adding the Share Target on the Declarations page did not mention needing to change supported file types.  There was a screenshot of the Declarations page, but unfortunately, this value was not shown (it was hidden under the Output window).

I checked the "Supports any file type" box, and the Share Target functionality started to work.

For the Save functionality, things were a bit trickier.  I was getting a buffer overflow exception at a runtime.  Again, I checked the code against the code in the book and everything matched.  I knew that this was not something I would be able to debug myself (since I'm not familiar with the WinRT libraries), so I went to the code download.

On the download site, there was a note that the ImageHelper application (the one I was working with) had a buffer overflow problem that had been updated.  So, I downloaded the code and things worked from there.

First Impressions are Important
I'll have to admit that this experience put me off for the rest of the book.  As I read through the other examples, I had doubts about whether they were accurate.  (I know logically that they were okay; only 1 other project was mentioned on the code download site as needing updates -- but this doesn't change the "gut feeling" based on experience.)

I have a few other concerns with the book regarding how deeply (or not) specific topics were covered, but I'd rather not focus on any more negatives.

Wrap Up
Unfortunately, I'm not able to recommend Building Windows 8 Apps with C# and XAML.  I'm still looking for a good reference on the topic.  If you have any book recommendations, feel free to leave them in the comments.  Now, I'm off to the next book in the stack.

Happy Coding!

Application Guidance Update: Kona and Prism

Back in December, I mentioned that there were updates coming for application guidance on WPF/Silverlight (Prism) and for Windows Store Apps (Kona).  Well, here's a few more interesting things to look at.

Kona: Guidance for Building Windows Store LOB Apps
The biggest news is that the Kona guidance for building Windows Store Apps is moving forward.  Brian Noyes was on .NET Rocks last week (http://www.dotnetrocks.com/default.aspx?showNum=847) talking about the work that Microsoft Patterns & Practices is putting into their latest guidance package.  If you're interested in carrying over a Prism-like development style to Windows Store Apps, then this episode is definitely worth the listen.

Kona isn't released quite yet; it's still in beta.  But Brian mentioned that they are doing (near) weekly drops on the Codeplex pages; check out the latest here: http://konaguidance.codeplex.com/.  At the time of this writing, the latest version is from February 22, 2013.  It looks like the release will happen sometime in March, but keep your eyes on the site.

Why Not Prism for Windows Store Apps?
One question that came up during the .NET Rocks episode is why Kona is a separate guidance package rather than an extension of the current Prism framework.  There are a couple of primary reasons.

First, Windows Store Apps are different enough from WPF and Silverlight apps that the approaches to development may not translate well.  So, rather than trying to fit a square peg into a round hole, the team decided to start from scratch.  The approach was to first build a Line of Business application (the type that a corporate developer might build) and then work backwards to see what common items can be made easier by extracting them into the Kona framework.

Next, there are certain things in Prism that just don't make sense in the Windows Store App world.  For example, Prism includes extensive support for Regions -- a way to put different views into different parts of the shell.  In the full-screen world of Windows Store Apps (it's killing me not to just say "Metro" here...), the idea of regions just doesn't fit.

Additionally, Prism has good support for dynamically loading modules.  This gives you the ability to drop assemblies into a folder that can then get loaded into the application at runtime.  In the Windows Store App world, all of the assemblies need to be included in the package that is submitted to the store.  So, there's no way to just "drop in a new assembly".  All of the functionality needs to be included up front.

So, it makes sense that the Kona guidance is separate from Prism.  I haven't taken a close look at Kona yet (I still haven't jumped into the Windows Store App world), so I don't have any opinions at this point.  But, if I do need to build line of business applications for Windows Store Apps, I'll definitely start here.

Prism 4.5
One other interesting thing that Brian mentioned is that Prism is basically "done".  That doesn't mean that it has hit end-of-life or anything like that (so don't panic).  It just means that the framework has gone as far as it needs to, so we shouldn't expect new features at this point.

Prism has been compiled to work against the .NET 4.5 framework (you can get the latest from Codeplex: http://compositewpf.codeplex.com/releases/view/95815).  But the features and functionality are the same as Prism 4.1.  Brian did mention that we can expect an updated version when Patterns & Practices releases the next version of Unity, but there won't be any new functionality.

Wrap Up
I'm not necessarily an advocate of using either Prism or Kona.  As with any framework, you need to take a close look at the problems that the framework addresses.  If you don't have those problems, then it's probably not the right framework for you.

As mentioned previously (Five Months In: Working with Prism and WPF), Prism worked very well on the last major project I was involved with.  But we also had many of the concerns that the framework set out to solve (such as Regions, Navigation, Modularity, and MVVM helpers).  Your mileage may vary.

It's always good to know what's available.  Then we are more likely to pick the right tool for the job when it's time to build a particular type of application.  Keep expanding the toolbox.

Happy Coding!

Update on Windows 8 Guidance

Last week (Five Months In: Working with Prism in WPF), I mentioned that application guidance for Windows 8 is still pending.  As an update, Blaine Wastell published an article a few days ago with the roadmap for Windows 8 guidance: Prism on .NET 4.5 and the road to Windows 8 apps.  So, it looks like we have something to look forward to from the Patterns & Practices team in the next few months.

Happy Coding!

Steal My Windows 8 Idea: Share With Grandma

A couple weeks ago, I attended a user group where Danny Warren from InterKnowlogy presented on Windows 8 (Danny is @dannydwarren on Twitter and blogs here).  He showed some really cool Windows 8 contracts including Search and Sharing.  (For more info on Sharing, Danny points to a blog article about sharing here: Windows 8 and the future of XAML: Part 5: More contracts in WinRT/Windows 8.)

My brain puts things together slowly sometimes.  I could tell during the presentation that Sharing was a very important feature.  And over the last week or so, the idea has really settled in, and I'm really looking forward to having that feature available in my day-to-day activities.

Before Windows 8 Sharing
We love to get data from one application to another: in a photo album, we can send a photo to Facebook; in a browser, we can email a story to a friend.  And historically, it has been up to each application to support the sharing. This meant that we were locked into whatever systems the application supported.  I don't know about you, but after I find an application I like, I tend to hang onto it for a while.  And even though it's really cool that my photo album supports sending to MySpace, it's not very relevant anymore.

This leaves me with a hard decision: do I look for another photo album and learn a new interface?  Or do I settle for doing manual uploads to my favorite sharing site?  Neither option is very appealing.  Wouldn't it be cool if I could keep my photo album application and add whatever sharing I want?

Share Target: I Love This Idea
In Windows 8, Microsoft has separated the responsibilities of this process.  The sharing application (a "Share Source") just has to expose some piece of data (whether it's text, an image, a URL, or something else).  Then any application that knows how to consume that data (a "Share Target") can get access to it -- with the user's permission, of course.

I think of this as the "Send To" menu that we had in Windows XP.  You could open up the "Send To" folder (under the user profile) and add shortcuts to applications.  I would always add "Notepad" to my Send To options.  That way, I could always right-click on a file, and, regardless of type, I could "Send To" Notepad.  This was great for bypassing the default editor for a particular file.  (As a side note: I've been weaned off of this functionality in Windows 7.  I'm sure there's a way of customizing the Send To menu, but it's not as obvious as it was in XP).

The Share Target takes this a step further.  Now, I can have any number of applications that are designated as Share Targets for photos.  From inside my photo album, I just have to "Share" a photo, and then I get to select from all of the applications that can accept that photo.  This means that 2 years from now when everyone is using a new photo sharing site / social network, I just need to get the latest Share Target application, and my original photo album gets to stay exactly the same.

To me, this is a brilliant idea.  Several of the phone OSes have integrated Facebook, Twitter, or G+ to make it easy to post photos or send updates.  But those are still bound to the OS.  With Windows 8, we can share with whatever we want (assuming someone has written an application for it), and we're not locked down to whatever was popular at the time a particular piece of software was written.

Steal My Idea: Share With Grandma
So, I thought of a good idea for this feature: Share With Grandma.  This would be a Share Target application where you could configure how tech-savvy Grandma is -- from Pony Express to Gadget Granny.  The application would decide how to get the shared information to Grandma based on these settings.

For example, let's say that I want to share a picture with Grandma.  If she has limited technical skills, then the application could send an email attachment.  If she is a little bit more comfortable, then maybe it sends her a link to a Facebook update.  If she's a Gadget Granny, then maybe it posts to a shared photo stream that automatically shows up on her tablet.  The same type of thing could be done for text or URLs.

In all honesty, I probably won't get around to programming this.  So, feel free to steal my idea (but at least give me a mention in the credits).

I see Windows 8 Sharing as a huge opportunity to come up with some really creative and useful ways of using the data that we've already got.  It's time to start busting out some code.

Happy Coding!