WPF-Blogger.com [Language: en]

Programming Windows 6th Edition Preview Ebook Is Here!

Charles Petzold — 2012-05-17T15:53:34

The long-awaited 6th edition of Programming Windows is scheduled to be published by Microsoft Press in November 2012, but you can purchase the ebook direct from the O'Reilly website today:

... more ...

Listbox, Why Art Thou Blanking?

Windows Phone Dev Blog — 2012-05-17T02:53:58

One of the biggest performance changes for developers using Silverlight in Mango (WP 7.5) is off-thread input for ListBox. In a nutshell this basically means that all any flick or pan a user makes on a ListBox is handled by a dedicated thread, the Direct Manipulation (DM) thread, instead of the UI thread. By connecting the DM thread to the Compositor thread (that’s the one that does all the drawing to the screen independent of the UI thread) we have a ListBox that moves smoothly even when the UI thread is completely blocked.

Unfortunately this also comes with a price – the ListBox is now so responsive and moves so fast that the Listbox can run out of content to display to the user as the user is flicking, and blank – basically drawing nothing except for an updated ScrollBar (so the user knows he’s still moving in the ListBox, but it doesn’t help much) and the background while the UI thread scrambles to bring in new items to fill up the holes.

My ListBox isn’t blanking, why do I care about this blog post?

You care because you care about your users. You’re the kind of dev who knows that even though he’s got a great, powerful phone, not everyone does. You care because you are proud to call yourself a developer. You care because… ok, back to reality.

With the release of Tango, Windows Phone is now supported on lower powered machines which often have slower hardware and less memory, so even though your device shows no blanking, others may see blanking, especially if they’re rocking a new, lower powered, Tango phone. This post will help give you the tools that let your app run smooth, with hardly any blanks, even on those phones.

My ListBox is not blanking, but it’s really jerky during scroll

Holy Smokes Batman! Jerky scrolling is all but eliminated in the new ListBox, even for WP7 apps – are you sure you’re using it? There’s a good chance you’re using the original LongListSelector (LLS) from the toolkit, which doesn’t auto-update when you move your project to Mango. To take full advantage of the new ListBox improvements you need to download the latest toolkit from http://silverlight.codeplex.com and update to the new LLS which is based on the platform’s ListBox.

Why does blanking occur: the nitty gritty

There are a couple of common code / design reasons that cause a ListBox to blank, but in general it all boils down to the amount of time it takes to bring in a new item. The ListBox maintains a one screen buffer of items in each direction which moves with the user’s viewport as they scroll around. If the ListBox can’t fill that buffer in the direction of the scroll fast enough, you get blanking.

Diagram 1: In a stationary world, when there is no scrolling going on, the user will be looking at the center screen and there will be buffered items waiting to be shown in both directions

Filling the buffer takes a few steps, namely creating an Item Container (if a suitable one from the excess buffer in the other direction doesn’t already exist) and Data Binding the new item’s content (which kicks off the Measure pass). All of these updates occur on the UI thread and they all happen at once (not item by item) so if a flick is fast and the ListBox realizes that it needs to draw a full screen worth’s of items it will block the UI thread while it does just that.

Diagram 2: As the user moves downwards we balance the buffers by transferring the excess buffer from the top buffer (red) to the bottom buffer and re-databind it to the new data, maintaining 1 screen of buffer in each direction.

But if the user flicks again while the UI thread is blocked bringing in buffer items, we’ll get even more out of sync and move completely out of our buffer space – since there is nothing in the Control to draw (remember, the ListBox is still scrambling on the UI thread to bring the new items in, it’s just too slow) you just get the background, i.e blankness.

If there’s nothing to draw, why is the ListBox still moving? Or, look at it from another angle:

As we mentioned earlier, scrolling is now off-thread, so from the Compositor’s point of view it’s moving the ListBox and everything in it, the problem is that the UI thread hasn’t stuck anything in it (at that position) yet, so we blank.

Diagram 3: Fast flicking a few times get you into this situation, where we have excess buffer above which we are trying to move downwards, but because there is so much of it and the UI thread is blocked trying to bring these items in we don’t finish in time and the user sees blankness (black) until the items are ready, at which time they simply appear.

So why is *my* ListBox blanking? And how do I fix it?

Let’s run through a couple of common reasons why ListBoxes blank, with some proposed solutions to each one.

1. Using ValueConverters in your template

ValueConverters are great – they allow you to transform your data on the fly as they are being DataBound into your items. Unfortunately they incur a UI thread cost – we need to transition from Silverlight into User Code, run your converter and then return. If your converter is heavy or you’re using lots of them in your template, then this will introduce blanking.

Question to ask yourself: does this code look like it can run in a trivial amount of time across all of the elements being brought in for a given frame? If not, you probably should explore a different way of doing the DataBinding. For example,you can have the object translate the values on population / property get time instead of using a converter - even though this may break your Data Model this can significantly reduce the DataBinding cost (and you could always wrap your object in a ViewModel).

2. Complex DataTemplates

When an item is moved from one buffer to another during a scroll, ListBox is usually smart enough to determine that this is the same kind of item and just update the data in the item. While this might sound cheap this dirties the item causing it to be remeasured. If your template is complex you will find that a lot of your time is wasted in Measure – remeasuring the layout of the control now that the data has been updated.

Fixing this is very per-scenario. Some general guidelines are to make sure to only use a container if you really need the options it provides – do you have a Grid within a Grid? Could you replace all of your Grids with a simple Canvas or maybe a StackPanel?

3. Decoding images on the UI thread

By default all images are decoded synchronously on the UI thread, so if you have something like this:

you're going to block the UI thread for however long it takes to decode your image. Luckily there’s an easy fix for this, change your template to read as follows:

Note that this does come with some caveats – older images will still show up until the new ones are loaded and the user may see a visual pop-in of the image when it is done loading, but these can all be worked around and massaged into a nice user experience that is not harmed by excessive image decode.

For further details see this blog post.

4. Using PrepareItemForContainerOverride to dynamically select a template

A simple list item is often times just not good enough – your app has an image item, a text item, a video item, a link item etc. etc. and you have a different template for each one of them. A common pattern is to use the ListBox’s PrepareItemForContainerOverride callback to dynamically change the container’s template based on what item is being databound.

Unfortunately, doing this can completely throw off the ListBox’s buffering technique – the ListBox sees that the container that it had in its buffer is not the type that you need and junks it, wasting even more time on the march to blankness.

So how do I solve this? Surprisingly enough, it is often cheaper to have all of your template parts in one large template (yes, yes, I know about point 2 above – keep reading!) with each mini-template collapsed if it does not apply. Since collapsed template items incur next to no cost during layout, they have next to no impact on run time (though there is a slightly larger memory cost).

And how do I get my different items to display on the different templates? Simple – databind to a new property on your classes which either has a type enumeration that runs through a value converter (ItemTypeToVisibility), these kinds of converters are often cheap, or wrap your class in a UI view model so that it has a property that returns the Visibility type directly.

5. Pulling data from [favorite heavy source] as part of your binding

The properties you bind to should have simple getters (setters is a different story) – always. If you have logic like this:

public int Rating
{
get
{
    <read from database>
    - or -
    <read from IsoStore>
    - or -
    <parse out some XML>
    - etc -
}
}

then you’re doing something wrong. This kind of logic is fine for a property that you know is only read very rarely, if at all, but if it’s in a ListBox then it most likely is going to be seen and you should be initializing the data up front.

Don’t get me wrong – you don’t need to load everything as you are pulling in 1000 items to your list, but you can certainly do it on a background thread as a deferred task kicked off in the constructor of your object. If your objects are really heavy and memory is becoming an issue then you have a few possible routes:

Implement a completely delayed load by hooking into the ListBox’s scroll amount or compression states and only loading more items when you get to the end of the list
Implement a DoubleLinkedObservableCollection, where each item in the collection knows about the next node (in each direction) and when it gets databound (based on one of the properties) it notifies X number of nodes on each side to make sure they all have their data ready to go. This should be done on a background thread, just don’t forget to Dispatch back to update any properties that raise a PropertyChanged event.

6. Cut down background work

With only one core any background thread can interfere with the smoothness of the UI thread. Although background threads get a much smaller time slice compared to the UI thread, enough of them vying for time will effectively starve the UI thread.

Diagram 4: Fictional time slice showing the effects of more background threads (not to scale)

Across any given slice of time, the UI thread will be allowed to run longer than any other thread, but is effectively running at the same priority, hence it is forced to yield to the background threads when its time is up. The more background threads, the longer it is before you get back to the UI thread so that it can complete its task.

Moral of the story? Be wise about the number of active background, especially in high stress scenarios. Stick to using a thread pool so that you can queue up your work without it all trying to run at the same time.

I’ve tried all the above, it’s still blanking and I only have a couple of screens of data – help!

If you find yourself blanking on a relative small set of data (approximately 3-5 screens), then it might be time for drastic measures. As mentioned above the cause for blanking is the amount of time it takes to bring in new items with new data as the user is scrolling, i.e. the virtualization overhead is the culprit. If you disable virtualization on your list, you’ll generate of all your items up front and scrolling will be blankless. To do this, add the following to your XAML:

<ListBox.ItemsPanel>
  <ItemsPanelTemplate>
    <StackPanel>
    </StackPanel>
  </ItemsPanelTemplate>
</ListBox.ItemsPanel>

While making this change is relatively simple, the impact can be drastic – no more blanking, but it comes at a cost:

Startup time for the Page increases – we now have to realize more items, so it’s going to take longer
Memory – same as above, more items hanging around, larger memory cost

If you give it a try on a low end device and startup and memory look acceptable – then this is your magic bullet!

So what are we left with?

Hopefully at this point you have a non to minimally blanking list, which scrolls smoothly and generally delights your users! Have you run into any other pitfalls that you think others should be warned of? Let us know below!

Running into other, unrelated performance issues? Drop us a line and we'll see if we can focus on them in a future blog post (stay tuned for a "memory" series coming soon).

MSDN Webcast series on building Metro style apps

Jaime Rodriguez [MS] — 2012-05-11T08:50:11

A few colleague evangelists are doing a series on MSDN Webcasts on building Windows 8 Metro style apps..
Catch the whole series and get a very concise, yet comprehensive introduction to building Metro style apps..
See below for abstracts and presenter for each session, click on the title for each session to visit the registration page for that session
Each session is one hour.

Monday May 14th, 2012 8:30 AM PST
Introduction to the Windows 8 platform and the Windows store
Jennifer Marsman
Windows 8 is Windows re-imagined! Join this session to learn about the new platform for building Metro-style applications. Get an understanding of the platform design tenets, the programming language choices, and the integration points with the operating system and across Metro-style apps. We will also discuss the enormous opportunity for developers to make crazy money with the Windows Store. You will walk away with the resources to begin writing Metro applications for Windows 8.

Wednesday, May 16th, 2012 8:30 AM PST
Designing apps with Metro style principles and the Windows personality
Chris Bernard
Metro style design has a set of five guiding principles to help you make the best choices when designing your app. These principles are the foundation for building great Metro style apps. Consider these principles as you plan your app, and always ensure your design and development choices live up to these principles.

Monday, May 21, 2012    8:30 AM PSTJohn WieseMonday, May 21, 2012    8:30 AM PST
Monday, May 21, 2012    8:30 AM PST
Building Metro style apps with XAML: What .NET developers need to know
John Wiese

If you are experienced with .NET or Silverlight and are already familiar with XAML, this session will teach you everything you need to know to create a Metro style app for Windows 8. This session will cover updates to familiar features and explore concepts that are new for Windows 8. We’ll talk about building reusable Windows Runtime Components in C#, Async programming in Windows 8 and both the Visual Studio and Expression designers. This session will show you how to turn your XAML skills into money-making Metro style apps.

Wednesday May 23, 2012 8:30 AM PST
What HTML developers need to know about coding Windows 8 Metro style apps
Michael Palermo
This session is perfect for any web developer wanting to leverage his/her skillset to develop Windows 8 Metro style apps. The session begins by proving how much web developers already know about building apps for Windows 8. The focus then turns to how to write JavaScript code with WinJS. Key points for Metro style app development will be highlighted by implementing popular feature requests using HTML5, CSS3, and JavaScript.

Thursday, May 31, 2012 8:30 AM PST
Win as One: How Contracts in Windows 8 Help You Build a Killer Metro App
G. Andrew Duthie
Contracts are agreements between Windows and your Metro style app that allow you to integrate Windows 8 features into your app. For example, Windows 8 lets users share content from one application to another by using the Share contract.

In this session, you'll learn how contracts work and how to implement the built-in contracts such as Search, Share, Settings, and More. With Contracts, you can help users get more out of your app, and in a way that is consistent and intuitive, and they will reward you by coming back to your app again and again.

Monday, June 4th, 2012 8:30 AM PST
Bring Your Windows 8 Metro Style Apps to Life with Tiles and Notifications
Chris Bowen

Tiles and Notifications are important ways to draw attention to your app and improve your users' experiences. Tiles can draw users back into your app when your tile comes to life on Start screen. They can also let users personalize their Start screen by creating deep links to specific places within your app. Notifications, delivered through the Windows Push Notification Service, can inform and draw your users back into your app even when it's not running.
In this session, you will learn how to effectively implement Tiles and Notifications to help your apps shine.

Wednesday, June 6th, 2012 8:30:00 AM PST
Building Windows 8 Metro style casual games using HTML 5
David Isbitski

The intent of this session is to help HTML5/JavaScript developers with writing their first Metro Style App in a fun, immersive way. We will cover the basics of HTML5 Canvas gaming and how we can easily bring it to Windows 8. We will then add additional game functionality as we introduce HTML5 Audio, CSS3 styling and web fonts, implementing a game loop with JavaScript, 3rd party frameworks, touch, camera, accelerometer, and WInJS controls.

I will be watching. I hope you join us.

Happy WIndows 8 coding!

Programming Windows 6th Edition Preview Ebook Coming!

Charles Petzold — 2012-05-10T18:40:13

If all goes according to plan, in one week, on May 17, 2012, you will be able to purchase a preview ebook of Programming Windows, 6th edition, for just $10. For that one-time payment of $10, you will also get the second preview ebook a couple months from now, and the final ebook later this fall.

... more ...

Memory Profiling - The Heap Summary View

Windows Phone Dev Blog — 2012-05-10T18:24:11

In an earlier post we looked at how we can gain broad insight into an application scenario’s memory characteristics and how the graph and markers drew our attention to ranges of execution for further analyses. Recall that in the memory leak diagnosis case we chose to analyze only the time range over which we observed the increase in memory usage. Indeed, that is a key first step to the analysis: filtering the memory activity data by a time range. The Heap Summary view is the result of such filtering, and represents the population of the heap during the chosen time range.

Heap Summary View

The Heap Summary view presents, in tabular form, a demographic analysis of the population of the heap.

In human population demographics, data collection happens through a census as well as through a continuous update to registries that track births, deaths, migration of place of residence and the like. The data collection in the case of heap population demographics is no different. “Births” map to allocations, “deaths” map to objects’ memory collected by the GC, and “migration of place of residence” maps to the migration of objects between the Gen0 region of the heap and the Gen1 region. A census of the heap at the start of time range identifies all incumbent objects (i.e. that were in existence). Births, deaths, and migrations are updated continuously, and a final census at the end of the time range identifies all the objects that were retained. In order to have a consistent terminology, we refer to the incumbent objects at the start as objects that were “retained” at the start.

Managed Silverlight Visual elements (i.e. objects that go into the Silverlight visual tree) are not just plain old managed objects. These might be facades with backing native-implementations holding native memory and during the course of execution might create and hold on to texture memory. Casual use of such elements in code can even lead to subtle leaks. From this perspective, subsequent analysis can be made easier if Silverlight Visual elements were tracked and reported separately from plain old managed objects. And this is precisely how they are tracked and reported through the Heap Summary view. Continuing with the demographic analogy, such classification has precedent in social demographics where human populations have been classified on ethnicity.

Armed with this context, let us study the following Heap Summary view from the memory leak diagnosis case:

The shaded region across the graph and markers indicates the time range used as the filer.

The census at the start reports 5576 instances of managed type objects accounting for about 283 KB and 26 instances of Silverlight Visual elements accounting for about 13 KB. In terms of incumbency the plain old managed objects dominate.

The churn happening within the selected time range is reported as 10615 instances allocated (births) and 11590 instances collected (deaths), accounting for about 23 MB each. The counts and sizes are somewhat balanced and cancel each other out to an extent. And this is borne out by the census at the end for the managed objects; the census at the end reports 4601 instances of managed type objects accounting for about 223 KB, which is just a little lower than what we had at the start. However, it also reports 69 instances of Silverlight Visual elements accounting for about 4 MB now (up from 13KB at the start).

When we correlate this table with the graph, our suspicion is drawn towards the Silverlight visuals. Why did their count go up, and why are they accounting for so much more memory? Within the filtered time range, memory usage has been steadily increasing too. Could we be leaking memory? Could we be leaking some part of visual tree itself? And there even seem to be images being loaded along the way; might we be leaking their texture memory too? We wonder.

Clearly, the next lead to follow is to get more visibility into what are those “Retained Silverlight Visuals at End”.

Summary

The Heap Summary view presents, in tabular form, a demographic analysis of the population of the heap. Interpreting the data in the table and correlating it with the graph and markers by itself can be used to make educated guesses at what could potentially be the problem, but equally importantly it serves to inform the next step in the performance investigation, as we shall see.

Silverlight 5.1.10411.0 Released Today

Pete Brown — 2012-05-09T21:54:33

Today we released a minor update to Silverlight 5. The 32 and 64 bit update version number is 5.1.10411.0. (The documentation said 5.2 at first, but this has been fixed.)

This will be rolled out to everyone. We throttle large updates of products at the start, so for some folks it was not automatically downloaded this morning.

This is primarily an important security update addressing an TrueType security issue that was reported across a large number of products. Some folks (like me) have reported issues seeing the TechNet page which has the information about the security issue, so I've repeated it here:

Executive Summary

This security update resolves three publicly disclosed vulnerabilities and seven privately reported vulnerabilities in Microsoft Office, Microsoft Windows, the Microsoft .NET Framework, and Microsoft Silverlight. The most severe of these vulnerabilities could allow remote code execution if a user opens a specially crafted document or visits a malicious webpage that embeds TrueType font files. An attacker would have no way to force users to visit a malicious website. Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that takes them to the attacker's website.

This security update is rated Critical for all supported releases of Microsoft Windows; for Microsoft .NET Framework 4, except when installed on Itanium-based editions of Microsoft Windows; and for Microsoft Silverlight 4 and Microsoft Silverlight 5. This security update is rated Important for Microsoft Office 2003, Microsoft Office 2007, and Microsoft Office 2010. For more information, see the subsection, Affected and Non-Affected Software, in this section.

The security update addresses the most severe of these vulnerabilities by correcting the manner in which affected components handle specially crafted TrueType font files and by correcting the manner in which GDI+ validates specially crafted EMF record types and specially crafted EMF images embedded within Microsoft Office files. For more information about the vulnerabilities, see the Frequently Asked Questions (FAQ) subsection for the specific vulnerability entry under the next section, Vulnerability Information.

Recommendation. The majority of customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using the Microsoft Update service.

See also the section, Detection and Deployment Tools and Guidance, later in this bulletin.

This is more of a GDR level release, but we needed to follow a new version number scheme. The version number doesn't indicate major functionality change or enhancement, but is actually a product of the build process. I'm reading the pages of discussion in our bug database covering this versioning numbering and the reasons why it went to 5.1. It really only makes sense if you're using our internal build tools :)

Note also, that as was the case in the Silverlight 4.0 to 4.1 updates, we reset the build number. This shouldn't be a problem unless you have code that is checking a build number without looking at the version number as a whole.

Release history from http://www.microsoft.com/getsilverlight/locale/en-us/html/Microsoft%20Silverlight%20Release%20History.htm

Silverlight 5 Build 5.1.10411.0 Released May 8, 2012

All updates to Microsoft Silverlight include functional, performance, reliability and security improvements and are backward compatible with web applications built using previous versions of Silverlight.

Fixes Security issue described in the following Microsoft Knowledge Base article: 2636927 MS12-034: Description of the security update for Microsoft Silverlight: May 8, 2012

Fixes an issue where "Best Effort" Silverlight Digital Rights Management Output Protection levels failed on some machines.

Fixed a failure to update OOB applications that are configured to use elevated trust when in browser.

Fixes an issue where persistent license acquisition would fail when a customer upgrades from Silverlight 4 to Silverlight 5.

Fixes an issue where certain character combinations can cause Silverlight application to crash.

Fixes an Access Violation described in the following Connect issue https://connect.microsoft.com/VisualStudio/feedback/details/719572

Fixes an issue where the SL5 plugin displays blank window after installing a font with a font name that starts with "&".

Fixes an issue where moving a focus to TextBox or RichTextBox after moving a focus to ItemsControl causes IME to be disabled.

Fixes an issue where Silverlight would not play content which required Output Protection.

Fixes a Silverlight DRM issue where some customers encounter hardware ID mismatch errors which can only be resolved by re-individualization.

Be sure to let us know if you run into any issues with this release.

Building Metro style apps with C++ event is now a live webcast

Jaime Rodriguez [MS] — 2012-05-07T11:09:00

Two weeks ago, we announced an all day training for those Building metro style apps with C++..

Event sold out within a few days, and we got a lot of requests for it to be recorded (or broadcasted live)..

I am happy to announce that the event will now be live. Please pencil us in in your calendar. Event will be live on Friday May 18th, from 9 AM PST to 5 PM PST.

We will share details (the link) and the agenda later this week.
We will aim to have two live Q&As (one around noon PST) and one around 4 PM PST, we will take your questions via twitter.. Just follow the #win8C++Camp (Updated on 5/10) #ch9live hash on the day of the event..

Please help us spread the word!! Hope you can join us on the 18th.

Happy Windows 8 coding!!

Teaching kids electronics, electricity, and logic using littleBits

Pete Brown — 2012-05-06T02:57:39

We homeschool our two children. Ben, is kindergarten age, Abby is pre-school age. My wife does, by far, most of the work there, including trucking them to specialized classes (art, music, gymnastics, karate, our homeschool group single day school, etc.) plus all the playdates with the other kids, and special events. Melissa even teaches several of the classes at the home school group. I generally deal with reading, since I'm in charge of story time with my son. Lately, we've split our time between him reading stories to me (I'm proud to say he's at about a 2nd grade level - you have to love personal tutoring) and me reading The Hobbit to him in preparation for the movie this Christmas. (JRR Tolkien is far wordier than I remember.)

Melissa and I also split science duties. I've brought Ben to the Banneker planetarium for a customized class arranged for our homeschool group in concert with one of the astronomy professors. I often bring Ben to SERC (Smithsonian Environmental Research Center) for their bi-weekly homeschool science class. It's nice to leave close to centers like that. Even in the 5-7 year old group, they do serious science. They worked with Microscopes to analyze feathers to explain what holds them together, learned about the scientific method, dissected something (unfortunately we missed that one), searched through oysters shells on the bay looking for shrimp, jellies, and fish, and much more.

There are certain things that I allow the kids pretty much as much as I can afford (within reason): decent books and LEGO. The educational value of them both is apparent the minute the child starts interacting with them. Unlike TV, the computer (the kids share my old netbook), or Leapster (or Nintendo DS in the case of Ben), we don't limit the children's time on either of these. In addition, we keep a cabinet full of paper, markers, glue, paints, stickers, and other craft supplies which the kids can play with pretty much whenever they want. We like to keep things around that encourage creativity. We're not perfect by any means, but we've found that making this stuff easily accessible encourages experimentation (and large paint and glue stains on our kitchen table, and random things stuck together that you may not actually want stuck together).

I tell you all this just to give you an idea of where we are with education in my family, and how important I consider it.

Of course, none of these things are exclusive to homeschooling or to us. I'm proud of what we've done so far, but we just happen to be fortunate enough to live in an area with lots of free museums and programs geared towards home school students. Many others take advantage of these museums and programs as well, they just have to do it on the crowded weekends :).

Note also that we generally teach both children the same things, although they follow their own interests. I tend to focus on Ben in this article not because we're teaching only him electronics and science, but because his age makes these things more appropriate right now.

Electronics and programming

One thing I've been trying to find a good way to teach is electrical/electronics basics and boolean logic. Not only is this an area of interest for me, but boolean logic forms the foundation of everything you do on a computer. I want my kids to have an understanding of this to complement their ability to use the computer (yes, both kids can use a mouse or track pad, Ben can type, albeit not quickly, as well). I've also found boolean logic just about the simplest math/logic you can get. I have no idea why I wasn't exposed to it formally until college (the only math class I've ever aced, besides 10th grade Geometry).

Programming is great, but I know from my own experience, that making something happen *outside* a computer is far more impactful and memorable.

One day, I had Ben in my home office and together we stuck a resistor and an LED in a little breadboard. Ben then touched the wire leads to a 3v battery pack I had around. He thought it was awesome that he could make an LED blink (again with the blinking LED, the gateway drug of electronics <g>). I thought this was great too. However, this type of approach won't go far with a 6yo or 3yo, as it's too easy to let out the magic blue smoke. It doesn't encourage experimentation at their level.

For my two kids, I found the snap circuits kits a little too fine grained in what they do. It's much easier to connect the components compared to discrete leaded components and a breadboard, but you can still connect them incorrectly. The snaps are also bit difficult for the kids to work with, and you're really working with just an easier form factor for discrete components. Getting from empty to blinking LED is just as much work as it is with discrete components. There's still lots of value to these, however, so the set Santa brought for Christmas will simply stay around for a few years until the kids grow into it.

As much as the kids like LEGO, the engineering and programming involved in the Mindstorms kits is also well above them right now. It's marked "10+" as a recall, so we still have time :)

I'm not trying to turn my kids into computer programmers, although I think basic programming is as necessary a skill as any other for their generation. Recently, I ran across a project that started on Kickstarter, and then became its own company.

littleBits

littleBits is a company and a collection of kid-friendly hardware modules ("bits", do a mental substitution ever time I say "modules") that can be connected together to form simple electrical circuits. The starter kit comes with a number of bits including a power module, button, potentiometer, LED bar graph, and more. Shown below is the little bits kit along with seven additional modules I purchased. I ordered the kit from makershed, and the additional bits directly from littleBits.

The overall design is Open Source Hardware, with the schematics available on github.

The connectors are custom fabricated modules which each contain three pins (or three pads) and a set of magnets. The pins are the typical Ground, Voltage, and Signal trio, with +5V as the standard high level. The polarization of the magnets prevents the modules from being connected incorrectly. Modules can be easily pulled apart, but the magnets are generally strong enough to stay connected during use (more on the connectors after I describe a few more things).

Each module is classified as either Input, Output, Power or Wire, and color-coded by its type (input: pink, output: green, power: blue, wire (and logic gates/routing): orange). Each is also supplied with Ground, +5V and the signal through the pins on those colored connectors. Three wires may not seem like much in the way of control, but there's a thriving community doing cool things with this simple standard.

With perhaps the exception of the buzzing motor module (which has the vibrating motor attached with a few thin wires), everything is extremely robust and able to stand up to the use of kids of various ages. Both my son and daughter enjoyed playing with them.

(the photos aren't instagrammed, they just have poor lighting)

Obviously the children each got something a little different from the process. Both enjoyed connecting them up and making something happen. Ben was able to understand the basic flow of electricity, and even a little about "AND" and "OR" logic gates. Abby enjoyed connecting all the pieces in a long chain, but also liked when she was able to test her strength against the pressure sensor (power + pressure sensor + LED bar graph == strength tester).

Ben also liked trying to connect every possible module to make something giant. However, after playing with it a third time, he started to understand a very important aspect of software and hardware design: build in small steps and test after each step. I can think of a number of professional developers who could benefit from this :)

My son's attention span is about the same as mine: 20 minutes. After that, he tends to get pretty antsy. (This is why you generally don't find me attending sessions by other speakers, or you see me sitting in the back and bailing when the session is half over. Nothing personal!) The littleBits did keep him engaged that entire time. More importantly, in the two days I've had these, he has played with them three times. Over time, they will likely only hold his attention if we add on newer modules that do different things. Kids are all about doing, not learning. The way to get them to learn is to get them to do, and the way to get them to do, is to find something that makes it dead simple to do something right off the bat. The littleBits definitely fit the bill here.

During the third time playing with the bits, Ben really started to grasp the concept of the flow of electricity. He wanted to know what exactly it was. I found the water analogy good enough for our discussion here, especially since it helps explain the potentiometer and buttons very well. He even figured out, on his own, how the pressure sensor conceptually works.

Logic

Once you have the basics of electricity down, you can start messing with logic. I had ordered both an AND and an OR module. Each module takes two inputs and has a single output. As you would expect, both inputs must be powered for AND to produce output, and only one in the case of OR.

Here's a simple AND gate made using: Power module, branch module, button and wire modules on top, button and wire modules on the bottom, and then the AND module and an LED module on the other ends of the wires. It demonstrates a logical "AND". That is, the LED will light only if both buttons are pressed.

The other circuits shown have been built by Ben or Abby. In this case, I built this circuit for Ben to show logic. I wouldn't necessarily expect him to come up with it on his own, although he was able to grok the concept of AND very easily from this. This is far more interactive, visual, and intuitive when compared to a truth table.

One issue with littleBits

littleBits isn't without issues, however. There's one design issue which, to me, prevents this from being the perfect learning tool. Their pin design doesn't have much compensation for poorly aligned connectors. Sprung, semi-pointed pins on one side contact flat pads on another. The pins are sprung, but the tolerance for a good connection is still pretty tight, as I found that even a slight amount of deviation from square on multiple modules can lead to connection issues for the circuit.

This very slight deviation from square, as shown here, is enough to cause those connection issues:

Unfortunately, these connectors are rigidly connected to the boards, presumably in some sort of mass manufacturing process. As anyone who has ever developed boards with connectors knows, not all these connectors will be perpendicular to the boards once assembled. In the worst case (which happens to be in the set I have), you end up with a situation that looks like this:

Notice how the boards sit off above the table, arched like a bridge. Right to left, there's the power module, a button module, the RGB LED module, another button module and (off picture) a regular LED module. If you press either of those two button modules, it causes the module to flatten to the table top, and disconnects the connection at the RGB module. Either I got a particularly bad batch, or this is a common issue. Like bank rounding errors famously making a crook rich, the problem compounds based on the alignment of the modules in a given circuit and the number of modules with this problem.

Generally, the impact here is really only with the button modules, and a little with the potentiometer module, and only when you have a few offending modules in a chain. It's the downward pressure required for the button that causes the problem. You can still have lots of fun without the buttons, or perhaps even put a folded bit of paper under the high module. You can also, for smaller circuits, simply pick it up and squeeze the button between your thumb and finger.

With modules this small size, the main issue isn't any warpage on the PCB itself, but the mounting of the plastic connector to the PCB base. The connectors aren't really deep enough to keep square during factory assembly.

If these modules were some inexpensive chinese thing from ebay (they're not. They're designed and assembled in the USA), I'd have expected this. However, at the prices of these modules (I'm in about $230 right now), this is an unexpected and surprising flaw. My RGB module, in particular, is really sensitive to this.

For the ones that are particularly bad, I'm going to request replacements. It may be that some slipped through production in the batch I have. Or it could simply be early production issues from a startup company trying to meet higher than expected demand. I would expect littleBits to make it right for any that are like this; they seem like an upstanding type of company.

Note that the littleBits site seems to show this issue with what I assume is a prototype kit in the slide show on the main page:

If you tried to connect something else downstream from that LED bargraph, you'd run into alignment issues. (In this case, the LED bargraph appears to have a connector incorrectly alignment, but leaning inward instead of outward as mine do).

Caveats of the connectors aside, I still think this is a great kit to get for you and your children, and I do not hesitate to recommend it as a way to teach the things I've mentioned here. My recommendation is to simply check alignment when you get the kit, and ask for replacement of any bits that are particularly out of tolerance. Sometimes you can only tell once you connect them up a few different ways and get the compounded issue of multiple misaligned parts.

Building your own bits

Little bits has been taking ideas on their dreamBits page for some time now. The list sometimes gets overtaken by joke entries (they seem to clean those up regularly), but there are also some good ideas there. But what do you do if you want to just build the bits yourself?

littleBits has been saying for a bit (haha! I crack me up) that they will have their connectors available for sale soon. I have no idea how much they cost, but I'm pretty sure I'll pick up at least a few to try creating my own modules/bits. There are lots of interesting components you could build out, including interfaces to microcontrollers to kick things up to the next level, should you wish.

Once they release the connectors, I'll probably give a few ideas a shot, and not just to show the kids how you can create your own stuff. Why not? The grown-ups can have fun (and learn) too :)

Yet Another Podcast #64–John Papa & Javascript

Jesse Liberty [MS] — 2012-05-03T19:44:03

Delivering Rich Mobile Web Experiences in Windows Phone 7.5 (ESPN.com Case Study)

Windows Phone Dev Blog — 2012-05-02T18:09:42

The Windows Phone Browser team has a goal of delivering the best web browsing experience on a smartphone. This goal has many components within our team: from the UI of the browser, compatibility with a wide array of website layouts, and of course buttery-smooth rendering performance. However, even if we execute flawlessly on our end, we are missing a crucial piece - delivering a great web experience is fundamentally a partnership between our team and web developers. Achieving this goal means working together to ensure that your content and services are delightful for users to consume on Windows Phone.

We understand that web development resources are always limited as you keep up with the increasing traffic from mobile devices, and the elusive "write once, run everywhere" promise of web development has not perfectly materialized. However, with IE9 for Windows Phone 7.5, we took a big step in the direction of this promise. By sharing a codebase with IE9 for the PC, we achieved identical support for new web standards and pushed the envelope on real-world performance with industry-leading hardware acceleration. We wanted to hear about developing for IE9 on WP7.5 from web developers directly, so we decided to collect some feedback and share it on the blog.

ESPN.com recently deployed their premium web experience to Windows Phone, and we thought it would be great to hear what they had to say about developing for IE9 on Windows Phone. As a side note, ESPN started looking into supporting Windows Phone because of a simple request I made on their support page. Lots of folks on my team are sports fans and were asking me about the site's experience on WP7.5, so I just dropped ESPN a note like any user would. The message was quickly routed to the mobile site team; I have immense respect for ESPN’s responsiveness and the system they have place to address user feedback. Here's what Mike Marrone, technical lead, had to say about developing for IE9 on WP7.5:

Overall, it was an easy process. We support only WP7.5 and IE9 thanks to its very good CSS3/HTML5 support. We are in a convenient position of having an existing legacy mobile site that older devices can fallback to. Honestly, development for WP7.5 boiled down to a fairly basic process - IE9 on the PC, being nearly the same browser, was a great dev tool to get most of the way there before final QA on actual devices.

Some other more specific development notes:

The "display: box" CSS style is not supported on WP7.5. We use this in carousel experiences to transition elements left or right 100% of the viewport without having to programmatically determine the viewport size (which means the browser automatically updates the positioning upon device rotation, etc.). On WP7.5, we actually used a better alternative thanks to it being the only browser that currently supports the CSS "vw" unit (VERY useful).
[Amin] See here and here for more information on vw units.

The bulk of our CSS differences between WP7.5 and other supported devices was with gradients. WP7.5 has an easy fallback with filters so it was not a big development issue.
[Amin] See here for information on using Gradient Filters in IE9.

JavaScript touch events would be a nice addition.
[Amin] We hear you, stay tuned!

We look forward to your continued great progress in mobile.

As you can imagine, this was music to our ears! We often use IE on the PC to investigate bugs, and it was great to hear that the tools work well for web development outside of our offices too. We appreciate the feedback (it will inform our plans for future releases) and welcome additional feedback through the comments below.

IE9 on Windows Phone is set up to support rich web experiences with great performance, and often all it takes is updating user-agent logic and using standards based (as opposed to vendor prefixed) HTML & CSS. ESPN invested a reasonable level of resources to do that and delivered a delightful experience to its users. I've definitely started to see the site pinned to Start around here, and I wouldn't be surprised if our senior managers are secretly checking ESPN during meetings.

Here's a before (left) and after (right) screenshot of the ESPN.com experience on Windows Phone 7.5. We want to say thanks to ESPN, and we look forward to seeing more rich experiences light up!

Special thanks to Krys Krycinski, Mike Marrone, and James Ballow at ESPN.

Amin Lakhani
Program Manager, Windows Phone

Symposium Session: Gadgeteering and the .NET Micro Framework

Pete Brown — 2012-05-01T21:12:13

On April 24th I helped run the patterns & practices Symposium 2012 Online on Channel 9. All of the videos are currently up and viewable on-demand.

As part of the event, I gave a talk on the .NET Micro Framework. I had a ton of fun doing it, and got to show off a lot of great gear. Take a look and let me know what you think.

I'll have the demos and presentation pptx uploaded shortly.

Visual Studio Achievements For Windows Azure Buzz

Karsten Januszewski [MS] — 2012-05-01T19:31:37

Here’s some links to posts and stories about the 15 new Windows Azure achievements added to Visual Studio Achievements:

Visual Studio Adds Windows Azure Achievements
Neowin

Azure Gamified - More Badges!
I Programmer

Visual Studio Achievements Brings Gamification to Windows Azure Development
MSFT post

Announcing Windows Azure Achievements For Visual Studio
Windows Azure Post

Cloud Cover Video
Channel9

Announcing Visual Studio Achievements For Windows Azure
Channel9

Four ways we’re improving Marketplace

Windows Phone Dev Blog — 2012-04-30T23:48:45

Today I’ll outline the latest steps we’re taking in our ongoing effort to keep the quality bar high in our rapidly growing Marketplace. I know most of you share our goal of a great shopping experience and already go out of your way to follow our policies and guidance. For others, I hope this insight into a few near-term changes we’re putting in place helps save you time and reduces your risk of having apps pulled from the Marketplace.

Avoiding trademark trouble

When a trademark or copyright owner contacts us about a suspected violation, we investigate and pull apps when the complaint is valid. Lately we’ve been doing more of this, especially for trademark misuse. Sometimes the requests come from the owners of big, well-known brands. Other times they come from new brands. Either way, we often find trademark violations are unintentional: some developers just aren’t clear on what constitutes a violation. But these investigations—and the time and money they can cost—can be avoided by doing a little homework before submitting or updating your app.

If you’re developing an app, please consult our content policy covering trademarks and this related Q&A. (The U.S. Trademark and Patent Office also has helpful background and a trademark search tool.) Our rules boil down to this: Your registered publisher name and everything about your app—name, logo, description, screenshots—must be unique and free of trademarked content unless (1) you own the trademark, (2) you’ve secured permission from the owner to use it, or (3) you’re using a trademarked name (not a logo) to describe your app’s features or functionality without suggesting that the app is actually published by the trademark owner.

For example, using “Microsoft App Co.” as your publisher name would cause problems because “Microsoft” is a trademarked term. By the same logic, you couldn’t call your app “MSN” or “YouTube”. However, you may be able to make an app called “Reader for MSN,” as long as you don’t use the MSN logo or otherwise suggest that the app is published by Microsoft.

Keeping the quality bar high

I’ve posted before about our efforts to help ensure that apps in Marketplace offer clear value. One of those efforts concerns bulk publishing—developers who send us hundreds of similar apps simultaneously. Today I want to mention two related issues on our radar that could affect developers working on app genres that lend themselves to bulk publishing.

First, we’re seeing developers submit the same app to multiple Marketplace categories, a violation of our policies. Instead, you should pick a single category that best reflects the content and function of your app. This not only helps customers find your app but gives all developers an equal opportunity to have their app discovered where people expect. Developers who submit the same app across multiple categories will have it removed from the catalog.

Second, when you create multiple closely-related apps—say, a series of quote apps that vary by theme—the Marketplace tile images must reflect the unique features of each individual app. They cannot be duplicates or near duplicates of each other. Your branding also shouldn’t dominate the tile. Here are a few examples of dos and don’ts:

Creating unique, easily distinguishable app tiles helps customers see at a glance what’s different about the apps you’re publishing, improving the shopping experience and potential for downloads.

Cleaning up keywords

Some developers have been violating Marketplace policy by entering more than the five allowed keywords for an app. A keyword is a word or short phrase that describes your app. Entered during the App Hub submission process, these words or phrases are always separated by commas.

Starting this week, we’re going to start enforcing the five keyword rule for all current and future Marketplace apps. Any app that exceeds this number will have all its keywords deleted. Affected developers will be notified and can then enter five new keywords in App Hub. We’re taking this action to help ensure that customers are able to find the most relevant set of apps for their search—including yours.

We’re also starting to examine app keywords for relevancy. We’ve noticed some developers have been entering keywords that are popular search terms—“Justin Bieber,” “YouTube”—but are totally unrelated to their app and what it does. If we find a keyword that’s not relevant to your app’s function or content, we’ll delete that keyword. Additionally, if you suspect that other developers are using high-impact keywords unrelated to their app— “Skype” for a tic-tac-toe game, for example—email reportapp@microsoft.com with the details and we’ll investigate.

Refining our approach to content policy enforcement

The final issue I want to discuss is one that affects all major app stores today: the treatment of apps that are “racy” or sexual in nature. We’re committed to offering a diverse selection of safe and quality apps that appeal to a wide range of customer interests. Items that some customers view as entertainment, others may consider inappropriate. This is a challenge for any big retailer, whether they operate online or down the street.

We think the right solution is (a) to be transparent about what’s acceptable and (b) to show the right merchandise to the right customer in the right place. Our content policies are clearly spelled out: we don’t allow apps containing “sexually suggestive or provocative” images or content. What we do permit is the kind of content you occasionally see on prime-time TV or the pages of a magazine’s swimsuit issue.

Admittedly, it’s tricky catering to such a wide range of people and markets. But we take this responsibility seriously and evaluate and discuss questionable cases. Recently we decided that we could improve the shopping experience for all our customers by a more stringent interpretation and enforcement of our existing content policy.

Specifically, we will be paying more attention to the icons, titles, and content of these apps and expect them to be more subtle and modest in the imagery and terms used. Apps that don’t fit our standard will need to be updated to remain in the store. This is about presenting the right content to the right customer and ensuring that apps meet our standards. We will also monitor customer reaction to apps and reserve the right to remove ones that our customers find offensive

While this change might require a little extra work on the part of a small number of developers, there are plenty of creative and appropriate ways to comply: showing male or female models in silhouette, for example, is one possible alternative. Here are a few other examples of app tiles that pass muster:

If you’re one of the handful of impacted developers, we will be reaching out to you within the next few days with more specific guidance on changes you need to make. If you don’t hear from us, there is no immediate action you need to take.

I hope this post has provided some useful tips and helpful insight into our policies, and how they’re evolving to reflect both customer and developer feedback and the growing size and reach of the Windows Phone Marketplace. We’re committed to our developer community and appreciate your feedback on how we can make Marketplace better for you and your customers. I look forward to hearing your thoughts.

GridView Control in Windows 8

Jesse Liberty [MS] — 2012-04-26T20:09:26

Two Marketplace changes; An update on 9 new markets

Windows Phone Dev Blog — 2012-04-25T00:49:34

I wanted to make sure you saw the Windows Phone consumer blog today, because my colleague Mazhar highlights two changes to the Marketplace shopping experience that developers should be aware of.

First, we’re removing the option to browse and buy Windows Phone apps from the Zune PC software, a change that started rolling out this afternoon. Second, in the coming weeks we’ll also start requiring that customers have Windows Phone 7.5 installed on their phone to buy, download, update, or review apps in Marketplace.

Mazhar’s post has more details and background. But I want to highlight one important way the removal of the Windows Phone store from Zune impacts developers.

It’s important to make sure you’re using the correct protocol for direct links to your app in Marketplace. This “deep link,” as it’s also called, makes it easy for customers to pull up your app in the phone and web stores. The correct format is:

http://windowsphone.com/s?appId={GUID}

You’ll find more details on deep links here on MSDN. If you use the older zune:// format for links, customers will see an error message. Just something to keep in mind.

One final update for today: We just released the OS software required to bring Marketplace to customers in Bahrain, Israel, Iraq, Kazakhstan, Qatar, Saudi Arabia, Thailand, UAE and Vietnam. These nine markets—which are already open for app submissions—were part of the larger Marketplace expansion I outlined last month. Our hardware partners can now create phones for these markets and begin their final launch preparations.

Mazhar will have more to say about these new storefronts in the weeks ahead.

Respond to User Input

Windows Phone Dev Blog — 2012-04-24T17:53:00

The fourth of the four principles I mentioned in Optimizing Apps for Lower Cost Devices is Respond to User Input.

A responsive UI is a basic expectation that users have of apps. Failing to respond to user input can frustrate users and can ultimately drive them away to other apps that are more responsive.

The basic guidance here is to keep as much activity off of the UI thread as possible until absolutely necessary. The UI thread is what processes user input for you, so any code you execute on that thread will interfere with this processing. Unless you're updating elements of your UI, you generally should not be executing code on the UI thread.

A quick way to check whether a block of code is running on the UI thread is to call Deployment.Current.Dispatcher.CheckAccess() inside that block of code (Intellisense won't show this method but it is there and useful). This will return true if the code is executing on the UI thread, so if this returns true and you're not updating your UI, then you've found code that could be moved to background threads.

An easy way to move code to background threads is to wrap it in a call to ThreadPool.QueueUserWorkItem().

// Running on the UI thread.
...

// Running on a background thread.
ThreadPool.QueueUserWorkItem((o) =>
{
    ...
}

The ThreadPool is (as its name suggests) a pool of background threads that are waiting to execute work items for you. QueueUserWorkItem enables you to register blocks of code that will execute on the next available background thread in the ThreadPool. Note that use of ThreadPools is common and encouraged across many platforms (including Windows 8) so familiarizing yourself with them will serve you well in future projects.

When you are ready to update your UI, you will need to return to the UI thread. You can return to the UI thread at any time from a background thread by wrapping your code in a call to Deployment.Current.Dispatcher.BeginInvoke().

// Running on a background thread.
ThreadPool.QueueUserWorkItem((o) =>
{
    ...

    // Running on the UI thread.
    Deployment.Current.Dispatcher.BeginInvoke(() =>
    {
        ...
    }
}

If you try to update your UI from a background thread, you will receive an UnauthorizedAccessException with the message "Invalid cross-thread access." In these cases, wrap the offending code in a call to Deployment.Current.Dispatcher.BeginInvoke() as shown above to execute it on the UI thread as required.

In addition to being able to control whether your code executes on the UI thread or on background threads, you also have options to do the same with framework code in several places.

Image decoding is an expensive operation that can harm interactivity significantly if executed on the UI thread, particularly if you're loading many images at a time. The framework allows you to specify BitmapCreateOptions to control whether image decoding executes on the UI thread or on background threads. Be sure to use the BackgroundCreation option to move image decoding to background threads.

The built-in ProgressBar control has known performance problems that can harm UI performance as a result of its animations executing on the UI thread. Use the SystemTray ProgressIndicator for the best performance as the ProgressIndicator is a shell component that will not interfere with your UI thread. A bonus to using the ProgressIndicator is that your UX will more closely match the UX of the built-in experiences.

If you're using animations in your app, use Storyboards wherever possible as these run on an important background thread known as the compositor thread and will not interfere with your UI thread. If you're familiar with Expression Blend, it can be particularly useful for generating Storyboards.

With code now running off of the UI thread for a given page, you should also focus on optimizing navigation between pages.

To keep page load times and in-app navigation responsive, defer loading activities until the first frame is rendered. The guidance for optimizing startup time of your MainPage applies to optimizing the startup time of subsequent page loads as well. Enabling the TiltEffect is a great way to acknowledge user input and indicate that navigation is in progress. This will make your app look and feel more like the first party experiences as well.

Many apps add page transition animations to add style to in-app navigations. While this is a great practice to make your apps more dynamic, excessive use of transition animations can delay load times, particularly when the generation/execution of the animations result in spikes in memory/CPU usage. If transition animations are causing performance problems in your app, disabling them completely, or at least on low-memory devices only, can significantly improve in-app navigation performance.

Maintaining a responsive UI is important regardless of the platform you are targeting. By offloading work to background threads and keeping in-app navigation fast, you'll provide the best possible experience to your users.

Insidious ByRef Legacy Code Issue

Karl Shifflett [MS] — 2012-04-24T15:22:30

The ByRef in the title should give you a hint that this is about legacy VB.NET code. One of my duties at my new job is to maintain our legacy VB.NET codebase until we deploy our WPF software. When I use the term legacy it should not be taken in a negative manner. Our legacy [...]

Announcing the Building Windows 8 apps with C++ Windows camp

Jaime Rodriguez [MS] — 2012-04-23T21:13:00

Join the Microsoft Visual C++ and Windows teams in Redmond on May 18, 2012 for a free, all-day event focused on building Windows 8 Metro style apps with C++.

Whether you are a new C++ developer ready to learn about the writing Metro style apps, an intermediate developer who wants to hone your code and skills, or an experienced C++ developer eager to squeeze every ounce of performance out of your Metro style app and/or push the boundaries of Windows 8, then this event is for you. We will have pragmatic advice for every developer writing Metro style apps and games with XAML or DirectX and C++.

Agenda:

C++ for Windows 8, Keynote by Herb Sutter
Building Windows 8 apps with XAML and C++
Building Windows 8 games with DirectX and C++
Introduction to the Windows Runtime Library (WRL)
Writing Connected apps: Writing networking code with C++
Combining XAML & Direct X in a Metro style apps
Writing WinRT components to be consumed from any language
VC11 compiler flags for getting the most out of C++

Registration:
Register for this event here. If is first-come, first-serve, and we are limited in space, so register soon.
If you want to learn more about other Windows 8 camps check the camps site.

Details:
Location: Redmond WA, Microsoft campus, bldg 92.
Date: May 18th, 2012
Time: 9 AM to 5 PM for sessions, Q&A and a small social event afterwards.
Speakers: We will update the list of speakers early next week, we are still negotiating session times & speakers to cram as much as we can into a single day.
Rest assured most of them are from the product team and yes, Herb Sutter will do the opening keynote and the first session.
Meals: We will have some light breakfast, lunch, snacks and appetizers + drinks at the end of the day.

My personal pitch on this event:
Even if you are already coding your Metro style app, you don’t want to miss this event. All the speakers are product team people, and we will have a very strong pragmatic angle during our sessions; we are aiming to answer a lot of the questions and help you avoid the common pit-falls that we have seen our early partners building Metro style apps with C++ have ran into. There will also be ample Q&A time through out the day.

Happy Windows 8 coding. Please help us spread the word on this event we are really excited to connect with C++ community.

2-4-6-8-10

Charles Petzold — 2012-04-23T14:00:00

If you've been following my blog, you know that for the past few months I've been working on the 6th edition of Programming Windows, which focuses on writing Metro style applications for Windows 8 using C# and XAML.

... more ...

Maker Geek Roundup 011 for 4/21/2012

Pete Brown — 2012-04-22T02:55:58

The Maker Geek Roundup aggregates information of interest to makers everywhere. Topics include .NET Micro Framework, Arduino, AVR and other MCUs, CNC, 3d Printing, Robotics, Microsoft Robotics Studio, Electronics, General Maker stuff, and more. If you have something interesting you've done or have run across, or you blog regularly on the topics included here, please send me the URL and brief description via the contact link.

Photography

Sometimes It's Just Easier To Flag Your Camera (DIY Photography)
Vintage Color Cross Processing in Lightroom 4 (Getting the Instagram look using an SLR) (DIY Photography) (DIY Photography)

General Maker

An easy to build cat feeder driven by a DIY linear actuator (Hack a Day)
Dust Deputy Cyclone Shop Vacuum Cart CNC (Maker Masters)

Retro Computing and Commodore!

Happy 35th birthday, Commodore PET! (MOS6502)
Camera Matching (The Starry Expanse - Rebuilding Riven)
This Doctor Who RPG Makes Me Wish it Were Real. (this 8-bit life)
Soulless (Preview) (C64) (RGCD)
C64 16KB Cartridge Game Development Competition! (RGCD)
Site 31 of Lon McDonald's Joust Tour (Jeff's Classic Arcade)
Hooking an iPod to a C64 (MOS6502)
Retro Thing: Kickstart A 3/4 Scale Arcade Machine Project! (Retro Thing)
Knight 'n' Grail (C64) (RGCD)
A small tribute to a great man (MOS6502)

Wanted!! Great Windows 8 Metro style apps

Jaime Rodriguez [MS] — 2012-04-20T07:46:00

Tuesday, the Windows Store blog announced that in the next significant Windows 8 preview release they will be expanding
their global coverage with 33 additional app submission locales for developers.

As Antoine Leblond alluded to in the post, our store services are ramping up as planned--and of course the plan includes ramping up developer registrations to enable app submissions to the Windows store. Today, you need an invite “token” to register. This begs the question - How can YOU get a token?

It’s easy! If your app is ready and you want to be among those developers who get to submit to the store early, simply attend one of the 100s of free Application Excellence Labs that DPE and Windows are holding around the world.

Follow these steps to get invited to an App Excellence lab:

Create a really great Windows 8 Metro style app (or game) immediately. Get it as ready as if you were submitting to the store.
If you know your local DPE evangelists (maybe because you attended a Windows camp training), get in touch with them and ask them to nominate your app for a lab.
If you don’t know your local evangelist, then email the following information to win8aefb@microsoft.com:
1. Your name
2. City & country where you are located
3. Brief description for your app (no binary, screenshot is optional, but only send if the screenshot is public, non-confidential stuff )
4. Your pledge that you’ve spent at least 8 hours devouring all the great UX guidelines we have at the design section in the Windows Dev Center¹
5. Wait for our response letting you know where the closest app excellence lab will be and how to get in touch with the right evangelist to nominate you.

Hopefully, there will be a lab near you. Right now, we have labs in 40+ countries and we may be adding more.

Of course, coming to the lab is not all you have to do. I have to go back to step #1: You need to have a compelling, functional app that follows our UX guidelines, our performance best practices, and our store certification requirements²

The lab is a 4-hour engagement with a trained Microsoft Services Engineer. This person will run your app through a series of tests based on a quality checklist to ensure your app is (or will be) in top-notch shape when you submit. You will also get a chance discuss ways to make your app even better and you will get answers to any questions you might have.
If your app meets the criteria, then booyah! You get a token to register your developer account and (once you have been verified and all that) you will be able to submit your app to the Windows store.
If your app does not meet the criteria, nothing is lost. You will still end up with a much better app³ and you will be able to submit it when registration opens for all developers.

Good luck. We are looking forward to seeing your apps and helping you to make them great!
Happy Windows 8 coding!!

¹ Kidding about the pledge but not kidding about highly recommending you review the guidelines and get your app very polished.
² Note: The lab is not a replacement for certification process; that still happens when you submit to the store.
³ Really, the lab preparation will be worth it, you will have a survey with questions, useful advice, links to guidelines, etc. The survey is (by far) not the only criteria we will use at the labs, but if you follow the preparation from the survey, you will likely have a great app.

Using a Style to Simulate TextTrimming on TextBox

Walt Ritscher — 2012-04-20T01:06:59

Synopsis: The WPF/Silverlight TextBox control lacks the TextTrimming property. Use a control template to add TextTrimming to TextBox. Want more Silverlight tips and tricks? Watch my Silverlight 5 Essential Training course We’ve all encountered the textbox that is too narrow to hold the text contents. Here’s an example from Visual Studio 2010 Figure 01: Visual [...]

Can this be true? MSDN subscribers ignoring $4K of free Azure services

Walt Ritscher — 2012-04-19T22:20:52

This statistic, seemed unbelievable. Only one out of ten MSDN subscribers is using their free Azure benefits. According to Microsoft, MSDN subscribers get a boatload of free services each year (~$3700.00 USD) I’m not talking about the free trial download. This is something different. If you have an MSDN subscription you get a lot [...]

Memory Profiling - Launching, Graphs and Markers

Windows Phone Dev Blog — 2012-04-19T20:25:04

It is said that “A point of view is worth 80 IQ points”; the meaning perhaps being that if we can look at things in different ways then we might understand them better. The Memory Profiler that ships with the Windows Phone SDK 7.1 provides, in its own way, multiple views into the memory usage of your application, and in an earlier post we had seen how specific views helped us understand one particular issue with the application better. But even before we got to the specific views, there was a graph and a couple of rows of markers, remember? Let us discuss them briefly.

Launching the Memory Profiler

How do you even know that you need to run your application scenario through the Memory Profiler, especially since there might not be any obvious visual cue? The answer lies in an Execution Profiler warning message. The expectation is that you would run your application scenario through the Execution Profiler for evaluating visual and code performance, and if it suspects any memory related issues it will raise a warning message suggesting running the scenario through the Memory Profiler!

Users of the Execution Profiler will find the interaction model of the Memory Profiler familiar. It launches from the same page, with the difference being that you select the Memory (managed object allocations and texture usage) option. The Advanced Settings option can be ignored for the purpose of this discussion. The following is the launch page for the Memory Profiler:

A warning message is issued if the deployment target happens to be the Windows Phone Emulator. The emulator runs on the desktop, and the desktop has a different hardware architecture than the device, with different performance characteristics across the board. The warning therefore alerts you to this lack of performance fidelity. If you are doing Execution profiling beware! The emulator is still a suitable target for doing memory profiling since in that case we are dealing with (memory) allocation profiling. Clicking on the Launch Application link deploys the application to the target and commences the profiling session.

Stop Profiling

There are two ways to gracefully end the profiling session:

By hitting the Stop Profiling link on the Profiler page.
By hitting the back button on the target (device or emulator) until you exit the application.

If the connection from Visual Studio to the target is broken for any reason (for example, if the emulator instance is closed, or the device is untethered, or the device shuts down, the connection is broken) the session is aborted.

Once the session is gracefully ended, the data gathered during the run is processed and presented graphically for analyses, starting with a Memory Usage graph plotting memory usage over time, and two rows of markers indicating image loads and GC runs as shown below:

Memory usage graph

The memory usage reported is that of private bytes: exclusive bytes allocated by the process being profiled. Some variance in memory usage is normal and not indicative of a problem. However, memory usage that keeps rising bears examination.

Image load markers

A tooltip on the image load marker indicates the encoding format, the ID of the executing thread on which it got loaded, the point in time when it was loaded, and how long it took to load. A spike in memory usage corresponding to an image load marker might indicate a large sized image being loaded (larger than 2000 x 2000 pixels). Windows Phone imposes this limit, and larger images will be sampled at a lower resolution, and will take longer to load. If you must use large images consider displaying only a portion that meets this limit by loading the image into a System.Windows.Media.Imaging.WriteableBitmap and using the LoadJpeg(WriteableBitmap, Stream) extension method as shown below:

int width = (int) this.image1.Width;
int height = (int) this.image1.Height;
Uri uri = new System.Uri("image.jpg", UriKind.Relative);
StreamResourceInfo sri = Application.GetResourceStream(uri);
WriteableBitmap wb = new WriteableBitmap(width, height);
System.Windows.Media.Imaging.Extensions.LoadJpeg(wb, sri.Stream);
this.image1.Source = wb;

The ID of the executing thread can be used to check if the image load computation is happening on the UI thread (the UI thread’s ID can be got from the CPU Usage analysis from the earlier Execution Profiling session). To keep the UI responsive it is essential to keep the UI thread relatively free, and if you notice that the image load computation is indeed happening on the UI thread, consider moving it to a background thread using the BackgroundCreation option. From XAML, this can be done as shown below:

An exercise to try out at this point it to memory-profile an application that loads in a large image; do you see a spike in memory usage corresponding to the image load marker? What was the duration of the image load? On what thread was it getting loaded? Try using the BackgroundCreation option; now what was the thread on which the image got loaded? Did the duration of the image load change? Let us know your experience.

GC markers

Memory is a limited resource on the phone, and although you are programming in a managed environment where the GC takes care of collecting unused memory you still wield control over allocation and referencing, and must monitor them to trim working set. The GC mediates all allocation requests from your code, and operates on a heap that it has partitioned into 2 regions (generations), with allocations happen in the ephemeral “Gen0” region and objects surviving a GC collection possibly promoted to an older “Gen1” region. The GC markers correspond to collections and a tooltip indicates it’s kind ("ephemeral", "Full"), the point in time when it started, and how long it took to run. An “ephemeral” GC collects only from Gen0 while a “Full” GC collects from both Gen0 and Gen1. Furthermore a “Full” GC can do a “compaction” of the heap if it happens to be significantly fragmented, and even go on to empty the system’s cache of JIT compiled code.

A GC is triggered using several heuristics:

When the amount of managed memory allocated since the last GC is deemed significant (1 MB). This is typically an “ephemeral” GC. However it can turn into a “Full” GC under the following circumstances:

When the managed memory held by objects promoted to Gen1 is deemed significant (5 MB).
When the application’s total memory usage is deemed significant (i.e. close to the maximum allowed by the OS).
When there is significant native-memory pressure - native-memory associated to managed objects (quite common in Silverlight) contributes to total memory usage!

When user code calls System.GC.Collect(). This is always a “Full” GC.
After any resource allocation failure. This is always a “Full” GC.
When the system as whole is running low on free memory. This is always a “Full” GC (that will go all way to emptying the cache of JIT compiled code).

The GC’s decision of deeming a threshold “significant” is based on internal heuristics and mentioned here for informational purposes only. The point to note though is that a “Full” GC is much more performance intensive than an “ephemeral” GC.

Insight

Armed with the graph, the markers and your own intuition, you can now get some insight into your scenario’s appetite for memory:

Does memory usage cross the 90 MB technical certification requirement threshold?
Is memory usage steadily growing?
Do you see a spike in memory usage? Is there a corresponding image load marker? That could be the likely cause (are you using large sized images when a smaller sized image would do?)
Are image loads taking long? (Again, this could be due to using large images).
Are image loads happening on the UI thread (consider moving that to a background thread).
Are there too many GCs? The GC on the Phone is a stop-the-world GC, and therefore the time taken by the GC to run is time taken away from your application! In general strive for little to no GC activity during application startup.
The frequency distribution of the GC markers indicates the rate of memory allocation in the scenario, as well as the time ranges when most GC activity happened. If you are writing a game try to concentrate the GC activity during a level change.
Are there multiple adjacent “ephemeral” GCs? That indicates short lived and/or temporary objects.
Is memory usage not coming down even after one or more “Full” GCs? That is indicative of long lived objects.
Are you explicitly causing “Full” GCs by calling System.GC.Collect()? That is rarely required, and often a bad idea.

An exercise to try out at this point it to profile an application that has various memory allocations patterns; can you correlate the graph and markers with your own intuition? Let us know your experience.

Summary

The graph and markers provide basic information about your application’s memory usage and when combined with your own intuition of the application scenario, be used to infer several characteristics. Further drill down through the various Views can then be used to understand these characteristics better.

Would you like to know more about the Views? Let us know.

Using Parallel.ForEach To Aggregate Results From JSON Files Stored in Windows Azure Blob Storage

Karsten Januszewski [MS] — 2012-04-18T00:24:35

I love NoSQL, except when it comes to reporting. Then I miss those handy SQL aggregation calls. I recently had a situation where I needed to look at a whole bunch of JSON files stored in Windows Azure Blob Storage and aggregate values from within those JSON files. The exact scenario was to get a count of how many people had achieved each achievement as part of the Visual Studio Achievements project.

Turned out to be an ideal use case for using some of the parallel programming features in .NET 4.0. Rather than download and process N JSON blobs linearly, I could throw the loop in a Parallel.ForEach block and gain speed from the multi-core machine I was using. The code was pretty straightforward, especially once I discovered the System.Collections.Concurrent namespace with its handy ConcurrentDictionary.

And, most significantly, it increased performance by 400 percent!

Below is the code in it’s entirety; I’ll walk through it here:

For JSON deserialization, I’m using a library provided by the WCF team up on CodePlex which is now part of the ASP.NET Web API. It provides some nifty features for turning JSON into dynamic objects.

The first thing I do is download a JSON file that has all the achievements, which is publically available (line 25).

I then put all the achievements in a ConcurrentDictionary<string, int> which I’ll use to build my report (line 33).

Then, I get the blobs and start my Parallel.ForEach loop (line 41). Inside the Action(TSource), I walk the list of the user’s earned achievements, incrementing the count in the ConcurrentDictionary of each achievement (line 57).

Finally, once I exit the loop, I turn the dictionary into an Excel spreadsheet (line 69) – folks tend to like that format.

You’ll notice the remmed out code; that’s the old non-parallelized code if you’d like to compare.

 1 using System;
 2 using System.Collections.Concurrent;
 3 using System.IO;
 4 using System.Json;
 5 using System.Net;
 6 using System.Threading.Tasks;
 7 using Microsoft.WindowsAzure;
 8 using Microsoft.WindowsAzure.StorageClient;
 9 
10 namespace AchievementsReporting
11 {
12     class Program
13     {
14 
15         static void Main(string[] args)
16         {
17             var cloudBlobClient = new CloudBlobClient(new Uri("https://---.blob.core.windows.net", UriKind.Absolute),
18                                                       new StorageCredentialsAccountAndKey("---",
19                                                                                           "---"));
20             var container = cloudBlobClient.GetContainerReference("users");
21 
22             string masterJson = string.Empty;
23             using (var webClient = new WebClient())
24             {
25                 masterJson =
26                     webClient.DownloadString(new Uri("http://channel9.msdn.com/achievements/visualstudio?json=true"));
27             }
28             dynamic masterList = JsonValue.Parse(masterJson);
29             var statisticsDictionary = new ConcurrentDictionary<string, int>();
30             //var statisticsDictionary = new Dictionary<string, int>();
31             foreach (var achieve in masterList.Achievements)
32             {
33                 statisticsDictionary.GetOrAdd(achieve.Name.ToString(), 0);
34                 //statisticsDictionary.Add(achieve.Name.ToString(), 0);
35             }
36             BlobRequestOptions options = new BlobRequestOptions();
37             options.UseFlatBlobListing = true;
38             options.BlobListingDetails = BlobListingDetails.Snapshots;
39             Console.WriteLine("Starting...");
40             DateTime start = DateTime.Now;
41             Parallel.ForEach(container.ListBlobs(options), blobListItem =>
42            //foreach (var blobListItem in container.ListBlobs(options))
43                     {
44                         CloudBlob blob =
45                             container.GetBlobReference(
46                                 blobListItem.Uri.AbsoluteUri);
47                         string json = blob.DownloadText();
48                         if (!string.IsNullOrEmpty(json))
49                         {
50                             dynamic achievementsDynamic =
51                                 JsonValue.Parse(json) as dynamic;
52                             foreach (
53                                 var achieve in achievementsDynamic.Achievements)
54                             {
55                                 if (achieve.DateEarned != null)
56                                 {
57                                         statisticsDictionary[achieve.Name.ToString()] =
58                                             statisticsDictionary[achieve.Name.ToString()] + 1;
59                                 }
60                             }
61                         }
62                     }
63                 );
64 
65             using (StreamWriter writer = new StreamWriter("report.xls"))
66             {
67                 foreach (var key in statisticsDictionary.Keys)
68                 {
69                     writer.WriteLine(key + "\t" + statisticsDictionary[key].ToString());
70                 }
71             }
72             TimeSpan diff = DateTime.Now - start;
73             Console.WriteLine("done - took: ");
74             Console.WriteLine(diff.TotalMinutes);
75         }
76     }
77 }
78

Workaround for CA0055 Error with Silverlight Projects in Visual Studio 2010

Pete Brown — 2012-04-17T21:07:46

This connect bug describes an issue with creating certain types of Silverlight projects in Visual Studio. If you're referencing Silverlight 4 DLLs from a Silverlight 5 project, you may run into this code analysis/FXCop issue yourself if code analysis is part of your process. The core of the problem is a versioning decision in Silverlight 5 which results in compile-time violation due to loading two different versions of mscorlib in the same project. It manifests as the following error:

Error 2 CA0055 : Could not unify the platforms (mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, mscorlib, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e) for 'MyProject.Silverlight\obj\Debug\MyProject.dll'.

More information on CA0055 may be found on MSDN.

How to Reproduce the Issue … in theory

In theory, all you need to do to reproduce the issue is reference a SL4-targeted DLL from an SL5 application. However, in practice, there are other factors in play. For example, it may matter which mscorlib version gets loaded first.

These steps won't repro the problem on my installation, but I'm putting them out here in case they help you visualize the issue (and also because I had already written them up when I realized they don't repro here -- I don't want all these bits to go to waste).

Create a Silverlight 4 class library. Make sure you target Silverlight 4. I named mine SL4ClassLibrary. The actual code is unimportant, but I set it to the following:

namespace SL4ClassLibrary

{

    public class Class1

    {

        public string Foo = "Bar";

    }

}

Next, add a Silverlight 5 Application project. Make sure it targets Silverlight 5. Here's what my solution looks like:

Build the solution.

Next, add a File Reference (not a project reference) from the Silverlight 5 client app to the Silverlight 4 DLL.

If you build it now, everything works fine. The key step here is to add code analysis. Many organizations have code analysis as a required part of their build process, using the compiler command-line arguments. If you don't, you can turn it on via the menu:

Then check the "Enable Code Analysis on Build" checkbox.

Now build the solution. In theory, you'll get a CA0055 error, but as I mentioned at the top, that doesn't happen on my install. Most of the people who have reported this issue on the connect bug have mentioned it in the context of the Business Application Template or third party controls.

Remember, this is a code analysis compile/build issue, not a runtime issue, so if you get past compiling your application, you're good.

The Workaround

This is already planned to be fixed in Visual Studio 11 RC. However, we do have a manual workaround for this to help you continue working if you're running into this scenario today. This will unblock using FxCop in Visual Studio 2010.

A high level walkthrough of how this works from the command line is:

We will tell FxCop which version of the runtime it will be using by pointing it to Silverlight 5's installed mscorlib.dll using the /platform argument
Tell FxCop where to find all of the referenced assemblies using /d (short for /directory) arguments: Use as many /d:<folder> arguments as necessary for FxCop to find all of the referenced assemblies.
Use either /console to tell FxCop to output the results to the console window, or /out:<file> to tell FxCop to write the results to an .xml file

To run FxCop from the command line for a default Business Application:

Add the %Visual Studio Install Directory%\Team Tools\Static Analysis\FxCop folder to PATH
Run "fxcopcmd.exe /file:<SL Business Application binary> /platform:<SL5 Reference Assemblies Directory\mscorlib.dll> /d:<SL4 Reference Assemblies Directory> /d:<SL4 SDK Client Libraries Directory>"

An example of what this looks like on an x64 operating system with all of the default install directories is:

SET PATH=%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop
fxcopcmd /file:BusinessApplication1.dll /platform:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\mscorlib.dll" /d:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0" /d:"C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client" /out:results.xml
NOTE: If you receive a CA0001 error: "The following error was encountered while reading module 'XXXX.YYYYY' : Assembly reference cannot be resolved…" this means that you need to find where that assembly is installed to on your machine and add an additional /d:<installed directory> argument pointing FxCop to where those assemblies are installed.

My thanks to the Silverlight Team and to Andrew Hall for the information on this workaround.

Of course, the easiest and best solution, if you can do it, is to use libraries that specifically target Silverlight 5, and make sure all references from your Silverlight 5 project are to libraries targeting Silverlight 5. We know that's not possible in all cases, including the specific reported business application case, which is why we documented this workaround.

Handle Feature Reductions

Windows Phone Dev Blog — 2012-04-17T18:28:00

The third of the four principles I mentioned in Optimizing Apps for Lower Cost Devices is Handle Feature Reductions.

With the Windows Phone 7.5 Refresh, we refactored the OS in several areas to reduce memory usage and free up more RAM for apps. Part of this exercise included assessing the memory usage of features in the developer platform and assessing which, if any, we could afford to live without.

To free up the most RAM while also being as minimally disruptive as possible, we disabled generic background agents (PeriodicTasks/ResourceIntensiveTasks).

On today’s devices, users can disable background agents for an app manually via the Settings control panel, and the system can disable background agents for an app if the maximum number of supported background agents is exceeded. These conditions are surfaced to the app via an InvalidOperationException which the app must handle. On 256MB devices, the app receives the same InvalidOperationException received in the maximum exceeded case above when trying to schedule a background agent (since the maximum number of supported background agents is 0). This means if an app is written today to handle the maximum exceeded case, it will continue to work on 256MB devices unchanged. Make sure your apps handle this exception path and degrade gracefully when these features are unavailable. This will benefit your app experience both on today’s generation of devices as well as on new lower cost devices. The 256MB emulator introduced in the WPSDK 7.1.1 enables you to easily test this code path.

If you're using PeriodicTasks today to power your live tiles, there are a few options available to you. The first option is to switch to push notifications. A second option is to create ShellTileSchedules to update your tiles with remote images. A third option is to leverage the ShellTile API's from your foreground app to update your tiles whenever the app is launched. While technically the tiles wouldn't be live in this last case, the content would be refreshed, which can give the impression of live tiles. If you allow users to flag content, for instance, you could turn your tiles into a permanent reminder space and update them to reflect the most recently flagged content (or toggle through flagged content with every app launch). If these options aren't feasible for you, then you can still always take advantage of secondary tiles to provide convenient access to deeper experiences in your apps.

In addition to PeriodicTasks and ResourceIntensiveTasks being disabled, the lower cost 7x27a chipset itself has reduced media playback capabilities that may impact playback of some of your content. Attempting to playback unsupported content on the device will result in either (1) a "Sorry, we can't play this file on your phone" error, if played via the MediaPlayerLauncher, (2) a MediaFailed event if played via MediaElement, or (3) suboptimal video playback in some cases. While most apps in our testing during the Windows Phone 7.5 Refresh were not impacted by these reduced capabilities, you may be impacted if you do exceed them. Be sure to understand the new baseline and encode your content to work well across all Windows Phone devices. To conditionally offer higher quality vs. lower quality content depending on the device, leverage the MediaCapabilities.IsMultiResolutionVideoSupported flag. This flag will be false on devices with reduced media capabilities, so be sure to fall back to the baseline specs in this case.

While feature reductions are never ideal, these reductions bring with them an opportunity to reach a large new audience with your apps. Be sure to account for these reductions when targeting lower cost devices to provide the best possible experience to your users.

Free Microsoft Azure Trial for your application

Walt Ritscher — 2012-04-17T00:02:00

According to major vendors like Amazon and Microsoft, the cloud is our future. No matter what type of application, it could benefit from cloud storage, cloud DB or cloud services. I believe there is a lot of truth in these ideals. But no technology is perfect for every scenario. That’s why its cool that you [...]

XAML Snippets and Visual Studio

Walt Ritscher — 2012-04-16T22:25:58

Visual Studio has a long history of supporting Code Snippets on the Toolbox. You can drag a code chunk to the toolbox, and instantly have a reusable code resource. So easy. I’ve found that some XAML developers are not aware that this technique works with XAML blocks. It does. Select your XAML in the text [...]

Where to get .NET Gadgeteer and Netduino GO compatible 10 pin IDC sockets, and how to solder them

Pete Brown — 2012-04-16T21:58:12

When creating modules for the .NET Gadgeteer or Netduino GO, one of the harder parts to source is the 10 pin IDC socket. This is the tiny 1.27mm pin pitch socket you see on the boards.

Manufacturers will get those by the reel in most cases, directly from China. There are several places the average hobbyist can get them from:

Digikey Part 609-4054-ND. Quantities as low as 1.
Samtec Part SHF-105-01-L-D-SM (you need to use their part builder tool to specify this number). You can usually get them to ship you a 10pc sample order as well.
Through-hole version if you'd rather use it than the SMD version (large quantities only)
Community-provided parts (including sockets and cables). Valentin ordered by the reel and is selling them cheap.
GHI Electronics is selling them individually.
GHI is also selling them by the reel of 800.

All of these sockets are black. The Netduino blue sockets were a custom run by them, and so are not available to us mere mortals :)

Sockets may come in tape, tube, or loose. In a section of cut tape, it looks like this (purchased from community member Valentin):

Samtec tends to ship in tubes, and most sellers selling individual sockets will ship them in bags or loose. It looks like Digikey ships in tubes as well. It takes a fair bit of effort to unzip these and sell them individually, so expect to pay quite a bit more for small quantities.

A comparison of socket implementations

Although they are completely compatible for our purposes, there are some physical differences between the Samtec sockets and the other widely available sockets. The Samtec parts are more expensive, but for hand-soldering, they're friendlier. Why? Because they have a slight undercut or bottom bevel which makes it easier to get a soldering iron in to heat the pad and pin.

In the pictures below, the generic part is on the left, the Samtec part on the right.

You can clearly see the undercut on the Samtec part on the right. You can also see that the sides of the part extend down further than the body, enabling it to sit on the plastic and not just on the pin headers. This second feature is nice, but probably overkill for most modules. IOW, it's quality, but I'm not sure it's worth the price premium. The extra bump/key on the outside is helpful for positioning during assembly, but doesn't serve any mechanical purpose on an assembled Gadgeteer or Netduino GO board. All you need is the notch. Note that every commercial module and main board I've bought all use the more generic chinese parts.

The undercut is helpful, though. Just look at how much more of the pin it exposes to your iron.

So, if you are new to soldering, I recommend using the more expensive Samtec part. If you have a reasonable amount of soldering experience and/or can make the pad a little longer than the stock footprint (see next section), you can get the inexpensive sockets.

Techniques for designing and soldering the connector

For your own modules, I recommend making the size of the pads a bit longer than the specifications. This will take up a tiny bit more room on the board, but make it easier for you to get your iron. Below are the two profiles: default on left, my current one on the right. Note that I intend to adjust the hand-solder one a bit to make the pads longer so they come into the center a bit better. As they are right now, you can't get a fillet on the heel of the pins. That's hard to do anyway, but I want as strong a connection as possible.

When hand-soldering, first apply flux to all the pads. You may also want to apply flux to the pin bases on the socket -- it certainly won't hurt, especially if the pins look a little dirty/oxidized.

Step 1: Tin one pad

I recommend then tinning one pad in the corner with a little solder. You don't want a giant blob here. As long as you get the whole pad tinned, less is better.

Step 2: Install the socket

Then, holding the socket in place with your fingers (by the plastic), melt the solder to wet the one pin and hold the socket in place while applying downward pressure to make sure it seats flat. I used to tin all the pads, but I've found it much easier to tin a single pad. You're not looking to make an electrically sound connection here, just something to hold the socket flat.

If you need to adjust the position of the socket, make sure you completely melt the solder on that pad. If it's only half-melted, the leverage you have with the socket will rip up the pad. I did this once. Not good!

Look at the board edge-on and make sure the connector is seated flat and the pin is touching the pad, not suspended above it on a blob of solder.

Step 3: Secure the socket at the opposite corner

Then, once the socket is in the correct position and all pins are centered on the pads (or close) and sitting completely flat, solder the opposite pin to firmly hold the connector in place. Don't apply too much pressure, or you'll move the socket and possibly tear up the first pad you soldered. Once you get past this part, all the tricky parts are done.

Step 4: Solder the remaining pins (including the first one)

Then, solder each pin, including the first one you tinned. The pins are a bit chunky for drag soldering, so you really need to do one pin at a time.

I do this by using a relatively fine chisel tip on my iron. I touch the side of the pin along with the pad at the same time and then add enough solder to ensure a strong connection. Make sure you heat both the pad and the pin. You can see here how the larger pads really help with hand-soldering. If you have a larger tip, you will end up heating more than one pin at a time, but it will be more difficult to get the pads. In that case, apply a bit of downward pressure to try and transfer heat between the pin and the pad.

The sockets are pretty robust, but try not to touch the plastic with the iron. It's normal for flux to smoke a little, but you don't want that extra special kind of smoke that comes from burning plastic.

Step 5: Inspect and Check

I tend to use a little too much solder on these joints. You can use a bit less than what I have here. Getting a nice fillet with these sockets is hard, though. Even the commercial modules and main boards tend to have a bit too much solder here, so I wouldn't worry too much about it as long as the connection is sound and the solder isn't adhering to the plastic.

That's it! Visually inspect the board from a number of angles to make sure everything is soldered correctly and that there are no bridges. Using a multimeter, you can check each pin against some other connected part of the board to ensure continuity.

Coding Signing Internal Applications and a Gotcha

Karl Shifflett [MS] — 2012-04-16T21:25:42

This blog post explains one way to code sign your internal applications along with their installers. Code signing your applications and installers provide a UAC friendly user experience during installation, uninstall, and when your legacy applications may need to run with administrative privileges (more about admin privileges below). UAC Friendly Installation Experience The below image [...]

Win 8 Page Navigation

Jesse Liberty [MS] — 2012-04-16T19:27:21

Turning Special Collection types (HttpCookieCollection) to Generic List

Walt Ritscher — 2012-04-14T07:49:32

I’m working on some new course material for ASP.NET MVC 3. I have the need to take some of the ASP.NET special collection properties and turn them into a generic list. For example, the Request.Cookies property is type as HttpCookieCollection which is based on the NameObjectCollectionBase type. This snippet does the trick. var cookieList = [...]

Here comes Windows 8

Jesse Liberty [MS] — 2012-04-13T21:41:21

Adjusting to rapid Marketplace growth—and preparing for the future

Windows Phone Dev Blog — 2012-04-12T22:56:44

Over the last several weeks some of you have reported slowdowns or delays in the app approval and publishing process. You’ve also said App Hub feels slower. We’ve been investigating, and today I want to explain why this is happening and more importantly what we’re doing about it.

This is the first in a series on our evolving Marketplace service that I plan to write in the months ahead.

It turns out App Hub had become less responsive. And our certification turnaround times have increased—by one business day, on average, from January through late March. Why? In short, growing pains. In three months the number of apps in Marketplace has grown by 60 percent, to nearly 80,000. During that period we’ve also nearly doubled the number of customer stores around the world, so there are now 54 markets to sell your apps. The addition of so many new markets and apps so quickly has slowed our backend systems.

So what are we doing about it? There is a long-term and a short-term plan. We’re already in the process of developing a more robust and scalable Marketplace service that will address current problems and pave the way for the even more rapid growth we’re expecting in the years ahead. But engineering work this significant doesn’t happen overnight. Our plan is to have it complete by late summer.

Until that work is done, we’ll be taking short-term measures to shore up the current service and relieve some of the strain on app certification and publishing. Some of these changes started rolling out about 10 days ago and include:

Adding more server capacity to better handle the increased load.
Streamlining our processes to accelerate the rate at which apps can be ingested, certified, and published.

Unfortunately, you probably won’t see dramatic results until Marketplace’s next generation service is deployed later this summer. But the average app certification wait has now fallen to 2.6 business days, or about a half-day improvement over the last 10 days. (You might experience different wait times depending on the app you’re submitting.)

We’ve also deployed some bug fixes that are helping to improve App Hub responsiveness.

I’m well aware there’s more work to do. But I wanted you to know that we take your feedback and concerns seriously and are attacking the problem on multiple fronts. I’ll have more to say on short-term plumbing upgrades—and planned long-term improvements to Marketplace and App Hub—in future posts. In the meantime, please let me know what’s on your mind.

Disabling Google Instant Search in IE Permanently

Walt Ritscher — 2012-04-12T20:30:46

I’m not a fan of the Google Instant search feature. Not a problem, as Google provides a way to disable the feature[1]. Except when it doesn’t work. Instant search re-enables itself constantly, it’s like the undead rising over and over again. Use this URL I found that if I use this URL http://www.google.com/webhp?complete=0&hl=en I always [...]

Browsing to website URL in a ViewModel

Walt Ritscher — 2012-04-12T08:13:48

During a WPF class last week I was asked a lot of questions about ViewModels. We were eating lunch, I was enjoying a smoky BBQ sandwich with all the fixings, when one of the guys at the table asked how to launch a webbrowser from the ViewModel. I had the code already, I’ve used it [...]

Cover art for my HLSL book on O’Reilly Media

Walt Ritscher — 2012-04-10T23:05:58

When you write for the O’Reilly animal book series you get a book cover with animal artwork. For many years the most typical O’Reilly books, the "animal books," have been designed as thorough guides for work with established technologies. The original animal design was developed by Edie Freedman because she thought that Unix program names [...]

Reduce Memory Usage

Windows Phone Dev Blog — 2012-04-10T19:16:00

The second of the four principles I mentioned in Optimizing Apps for Lower Cost Devices is Reduce Memory Usage.

Per certification requirement 5.2.5, apps should not exceed 90MB of memory usage on 256MB devices. When thinking about targeting 256MB devices, your first order of business should be to check whether your apps exceed 90MB today. If they don't, then reducing memory usage is less urgent (but still important as I'll mention later). If they do, then memory tuning will be required.

Leverage the memory profiler and memory-related API's to identify areas of opportunity to improve memory usage in your app. These tools can help you understand pretty quickly what the peak memory usage of your app is as well as what the breakdown of memory usage is across various states of your app.

A general principle to keep in mind is that loading less will result in less memory usage. Loading less could mean loading less data at a time, loading less/smaller content, or fixing leaks which result in more objects residing in memory over the lifetime of your app.

Many apps load and display lists of data (news articles, recipes, events, search results, etc.) often across several pivots on a page. If each of these pivots loads hundreds of list items (usually with images attached to each one), this can result in wasted memory usage particularly if (1) the user never views particular pivots or (2) the user never scrolls below 20 items in any given list. If several pages in your app display lists of data in this way, then memory usage can add up quickly as users navigate through your app. Wherever possible, load less data at a time. Defaulting to a small amount of items in each list and then loading more data as the user requests it can enable you to load the most relevant content in your UI at once (rather than potentially harm user interactivity by loading data in response to user input like pivot selection changes) while keeping your app's memory footprint at a reasonable level.

Asset memory (for images, sound effects, etc.) can quickly add up if you're not careful about how you load assets. The more assets you load into memory at a time, the larger your memory footprint will become. Not only does the amount of content you load affect memory usage, but also does the size of the content. Memory usage of images, for instance, can be approximated by multiplying width * height * bpp (bits/pixel). Higher resolution images will naturally translate into higher memory usage. Loading a 1024x1024 image into memory only to scale it down to a 100x100 container will consume more memory than is necessary. If you're doing this for every image in a list or in a photo gallery feature, then you're using a lot more memory than you need to be. Load thumbnails where it makes sense, and load higher resolution content as the user requests it. If your content is preloaded in your app, make sure that the resolution of the content aligns with the sizes of the containers that will host the content. If you're loading images from a web service, check for options to load lower resolution images instead of higher resolution versions. PictureDecoder.DecodeJpeg can generate thumbnails from high resolution image streams so use this to your advantage. If you're building a game, load assets for the on-screen experience only and flush those assets when they are no longer necessary. Hanging on to assets unnecessarily can result in OOM (out-of-memory) exceptions or general performance problems as the size of your game grows.

Memory leaks can bloat your app footprint and should be identified and addressed. Common sources of memory leaks are building circular navigation loops and failing to deregister event handlers to long-lived objects. Apps that use a home button can result in circular navigation loops which can fill the back stack with redundant page instances. These page instances consume memory and could result in your app crashing due to an OOM (out-of-memory) exception while users navigate through your app. Avoid circular navigation loops by removing home button functionality or by leveraging the new back stack manipulation API’s exposed in Windows Phone 7.5. Neglecting to deregister event handlers to static objects can prevent objects from being reclaimed by the garbage collector. Imagine a search results page where the user navigates back and forth between the details of a search result and the search results page itself. If the details pages hold on to references to long-lived objects, they could continue to reside in memory even after the user navigates back from them. Be sure to deregister event handlers to static objects when they are no longer needed to prevent such leaks. OnRemovedFromJournal is the recommended place to perform this task since it handles page closure both via backward navigations as well as via the back stack manipulation API’s.

Additionally, you should be careful with the use of memory-intensive controls like the WebBrowser and Maps controls. IE can consume a lot of memory when rendering complex websites. This is true even today. The WebBrowser control essentially embeds IE in your app, so if you allow users to navigate to arbitrary complex websites in your app, the memory that IE uses will be attributed to your app. This could result in your app running out of memory if the sum of your app's memory usage plus IE's memory usage exceeds the recommended 90MB limit. If you'd like to use the WebBrowser control, just be mindful of the content that users are allowed to load. If the content isn't very complex, then performance/memory issues shouldn't be a concern. If users can load complex content in the control and your app footprint is already large, you may want to consider using the WebBrowserTask on 256MB devices to reduce the memory usage inside of your app. Similarly, for the Maps control, you may want to leverage the BingMapsTask/BingMapsDirectionsTask to offload map memory to a system process. If a customized map experience is critical to your app, then loading fewer overlays or otherwise simplifying your map experience can help save some memory as well.

As I mentioned before, if you're exceeding 90MB today, then you're likely violating some of these principles and tuning will be required to target 256MB devices. If you're not exceeding 90MB, tuning the memory usage of your app is less urgent but still has its benefits.

To enable apps to use up to 90MB on 256MB devices without jeopardizing the overall integrity of the system, we improved paging support in the OS with the Windows Phone 7.5 Refresh to better manage and distribute memory between background services/processes and the foreground app. While paging is generally abstracted from you, apps may perform slower or glitch occasionally if they push the device to its limits. Apps that use less than 60MB of memory will generally not be impacted by paging. Apps that use between 60MB and 90MB of memory will participate in paging, more so as you approach 90MB. Apps that fall in this range will be more likely to suffer from slower performance or glitches depending on the rest of the activity on the system. The smaller your app's memory footprint, the less likely it will be impacted by this variability.

In addition to having better performance, apps that use less memory are more likely to fast resume. A precondition to fast resume is that the OS has enough free RAM available to keep apps dormant (in memory) in the back stack. On 256MB devices, free RAM is not as abundant as on 512MB devices, so an app that approaches 90MB of memory usage will be tombstoned immediately as it leaves the foreground to free up RAM for the incoming app. Apps that use less memory are more likely to be kept alive in the back stack. It should be noted that the Task Switcher (tap and hold Back to visualize the back stack and quickly navigate to a given app) will always be available on 256MB devices. What we're discussing here is merely the mechanism by which a 7.1 app will fast resume (the existing app instance is returned to the foreground from memory) vs. resume from tombstoning (where the app instance is torn down when it is placed in the back stack, and a new app instance is created when the app returns to the foreground). Apps that use less memory are more likely to benefit from fast resume.

Tuning memory usage is a critical component of optimizing apps for 256MB devices. After becoming comfortable with these guidelines, it will become quite natural for you to build very efficient apps. It's a lot easier to build efficient apps from the beginning than to try and tack on efficiency after you've architected your app, so take comfort in knowing that the knowledge you gain tuning your existing apps (and seeing the results you achieve) will be directly applicable to your future Windows Phone projects. At the end of the day, your users will notice and appreciate the efficiency gains.

The Passing of another home computer legend: Jack Tramiel dies at 83

Pete Brown — 2012-04-10T00:14:25

Jack Tramiel, the founder of Commodore International, and father of such beloved computers as the PET, VIC-20, C64, C128 and others, passed away this weekend at the age of 83.

According to many of the books I've read, Jack was often considered a tough guy to work with, as he drove his employees and the rest of the industry, relentlessly. Some say he even used unfair tactics to get what he wanted.

Commodore started with typewriters and calculators. To give you an idea of Tramiel's thriftiness and approach to business, he wanted their PET computer to use calculator buttons, instead of a real keyboard, because they had so many calculator buttons otherwise going to waste.

The end result, however, was the single best selling individual computer of all time: the Commodore 64. This computer, with any operating system, memory, or performance upgrades, was sold for almost 14 years. During that time, the C64 had better sound and graphics than almost any other computer available, and at a fraction of the cost. Imagine a single computer today (not an architecture or OS family) selling (and selling well) for that long, virtually untouched.

Semi-historical movies like "Pirates of Silicon Valley" tend to focus only on Apple (Steve Jobs) and Microsoft (Bill Gates) when it was Commodore that introduced more kids and adults to computers during the 80s than just about anything else. In the middle of the 80s, Commodore had upwards of 30 to 40% of the entire home computer market.

My Commodore 128 in the 80s:

My current Commodore 128 (not the original one I owned, as my parents threw that in the bin) being played by my son 3 years ago:

http://www.flickr.com/photos/psychlist1972/3331263565/in/set-72157614855631104

Yet Another Podcast #63–Windows 8 with Shawn Wildermuth

Jesse Liberty [MS] — 2012-04-09T20:52:27

The Hello World of genetic algorithms

Josh Smith [MVP] — 2012-04-08T18:23:09

I just published an article on my iJoshSmith blog that explains how a simple genetic algorithm works. The article is titled “Simple Genetic Algorithm in Objective-C” and can be found here… http://ijoshsmith.com/2012/04/08/simple-genetic-algorithm-in-objective-c/ If you’re interested in expanding your mind today in some strange new ways, go check it out!

First Experiences with the new Netduino GO, and how it relates to .NET Gadgeteer

Pete Brown — 2012-04-08T00:40:01

I just received a bunch of packages from both Secret Labs and GHI Electronics. The Secret labs packages contained their brand new Netduino GO. The GHI package contained the FEZ Cerebus Starter kit I ordered.

This post looks at the new Netduino GO and briefly compares it to the .NET Gadgeteer (Cerebus and others). I also build a couple simple example applications using the Netduino GO kit.

The Hardware

the hardware came in a number of classic Netduino Blue boxes, with each board and module inside packaged in quality ESD-proof bags. Secret Labs has always had a good unboxing experience. I've also really like these bags as they just seem to be quality.

Disclosure: These bits were provided to me free, from Secret labs. I also purchased $150 worth of GO modules from Nwazet using my own money. You may remember them from the PIX-6T4 and my game: Sixty4Racer. The Nwazet modules, including a touch screen, should arrive later this coming week.

Also, keep in mind that although I work for Microsoft, Microsoft doesn't make a dime off any of these devices. It is all free and open source (Apache licensed). The .NET Micro Framework 4.2 is actually 40% community contributed as well.

Here are some photos of the packaging and modules.

The downside to the packaging is you end up with a lot of blue boxes hanging around. I haven't yet figured out a good use for those, although I employ one or two on my bench to hold loose screws and whatnot. I'm not sure how Secret Labs plans to package up kits, but it would probably be more environmentally friendly to put all the individually wrapped modules in a single box for shipping.

The Netduino GO modules have their mounting holes on 5mm centers, just like the Gadgeteer. So, I was able to use a Tamiya 70172 Universal Plate (Large) as a home for everything.

Top to bottom, left to right:

RGB LED Module
Netduino GO main board
Netduino Shield Base (for using arduino/netduino shields with the GO)
Button module
Button module
Potentiometer module

The Netduino GO board came with a couple 10 wire cables, but the modules themselves did not. The ribbon cables with the red stripes on them are extras from my Gadgeteer cables. I'm a bit torn in that I think each module should come with a cable, but at the same time, those cables tend to be expensive, and I do have an awful lot of extras lying around because each Gadgeteer module comes with a cable. I'd be interested in your thoughts and expectations here.

In any case, make sure you order some extra cables if you plan to hook up more than a module or two at a time.

If you look closely at the modules on my dev board, it looks suspiciously like Gadgeteer. In fact, here's a GHI Cerebus on the same type of mounting board:

Also shown in this picture is my MIDI module (I plan to release a version for the Netduino GO as well)

Superficially, they look almost identical. The connectors are the same 10 pin micro IDC connectors. On the Gadgeteer, they're black, on Netduino, they're blue, but otherwise they are identical parts. Orientation is also 180 degrees different, but that's not really a functional difference. Here's a side x side of the Cerebus and the GO in kit form. (the kits are not equivalent in price or functionality. I just used the photos the two vendors have on their sites)

It's hard to really see it from this photo, but the Netduino GO main board is just a bit than the FEZ Cerebus main board. GHI also has several other Gadgeteer main boards and kits (like the Spider and the Hydra). The Cerebus is just the latest offering. The Hydra and Cerebus are open source hardware and software, as is the Netduino GO.

The Netduino currently has provision only for USB power (although I understand there may be an adapter coming), provided directly on the main board. The Gadgeteer always has the power provided by a separate module, always colored red. The source of that power can be an adapter, USB, batteries, or something else.

Module-wise, the GO modules tend to be a bit larger as well. It appears there are a few reasons for this:

GO modules (so far) always have their connector on the top. To save board size, many small Gadgeteer modules have the 10 pin connector on the bottom
GO modules include a coprocessor chip (or module controller, or whatever you'd like to call it).

The second item brings us to the main difference in the approaches. The architecture.

The Architecture

The real difference between .NET Gadgeteer and the Netduino GO is the way the modules communicate with the main board.

Let me start by saying that I strongly believe there is merit in both approaches. I like the socket-type approach on Gadgeteer, and I also like the GO!bus approach used by the Netduino. I'm not picking sides here, just describing how they work. This is the kind of stuff holy wars are made from. Let's not go there.

Design Approach

The .NET Gadgeteer uses a socket identifier approach. Each main board surfaces a number of sockets, each of which is assigned a socket type. For example, socket type "U" is for UART (serial) communications. Socket type "A" supports analog communications. There's pin sharing and whatnot behind the scenes, all managed by the board code, but in essence, you are surfacing the MCU's different pins in the form of sockets. If a main board has, at most 6 analog inputs, you cannot get more than that without adding a co-processing board with its own MCU with its own analog inputs, communicating to the main board over serial, I2C, SPI, DaisyLink (more on that in a moment) or something else. This approach is a simplification and formalization of the pin-based approaches we've seen starting with Arduino and others.

The Netduino uses the GO!bus protocol (discussed below). The main board only provides digital communications with modules. It doesn't surface any specific pin types, and all sockets are (to the best of my knowledge) equivalent. Therefore the modules own all capabilities and the main board serves only to run your code and communicate with the modules themselves.

Communications Protocols

On the Netduino, all modules communicate with the main board using the digital GO!bus protocol. This is a chip-to-chip SPI protocol (I believe it also can work over serial if you prefer) of varying speed. I've seen mentioned speeds up to 40MHz. The on-module chips that provide this functionality are pretty cheap ($0.30 each in quantity), but have a number of capabilities. I've ordered a bunch from Digikey to experiment with. They're small format surface-mount components, though, so not exactly breadboard-friendly without a breakout board. ( Appropriate breakout boards can be ordered from Seeed and other places. Be sure the pin pitch matches the chip you're experimenting with). Secret labs is also looking to potentially expand the universe of supported (meaning they provide GO!bus code) chips to ones like AVR and more, making it easier for DIY folks to experiment.

The .NET Gadgeteer also has an I2C-based module communication protocol called Daisylink. Its primary purpose is to allow chaining a number of modules together, but it is a digital protocol implemented by a few modules including the multicolor LED module. I haven't seen any vendor-provided Daisylink module code, but some folks in the community have been working on that. Daisylink is, by far, not the most common way to create modules for the Gadgeteer, however. Most use X/Y socket types, serial, SPI, or something else.

Aside: the on-module processor approach

Before the GO was introduces, I was looking at creating a number of modules for the .NET Gadgeteer (I still am). In each case, those modules requires an on-module processor to handle things like multiplexing many inputs, handling some logic specific to the board, or something else. The on-module processor approach is actually one of the best ways to scale out a solution whether you're using the Netduino or the .NET Gadgeteer. The Netduino GO approach simply formalized it and provides tested code you can use to get started.

Using this approach, you can, for example, create a module that can be wired up to 64 buttons, or have 16 analog potentiometers, or which can control a large LED array, or a bunch of servos or anything else. It's a very valid (and sometimes necessary) approach regardless of which board you use.

Another example is my MIDI module. At its heart, it's a very simple module. However, there are certain MIDI functions, like MIDI soft thru, clock/sync generation, active sense mode, message filtering, and more which would be best implemented in native C code on an on-module processor. I may create a version of the MIDI module which works with the GO, but also provide firmware options (either different firmware or an on-module jumper or something) to enable it to communicate with the Gadgeteer as well.

Finally, the Netduino GO does allow you to use X, U, or S Gadgeteer modules in compatibility mode. Unfortunately, this ties up a number of sockets to make it work, so I suspect it will be good for emergency use only; you wouldn't want to design modules around it. You would need to create a special driver for the GO anyway, as all the Gadgeteer code infrastructure isn't there on the board firmware.

Enough of the comparison. Let's take a look at the experience of building a simple Netduino GO demo application.

Netduino GO Installation

I previously had installed the .NET MicroFramework 4.2 SDK, so I didn't have to mess around with that. I won't cover much of installation here, as the full Netduino GO SDK wasn't yet ready when I got the hardware.

Worth noting was that I didn't need a special driver for the GO. Instead, I plugged it into my machine, and it was recognized as a Netduino. It just worked.

Hello World: Lighting up the RGB LED

As I mentioned, I didn't have an official SDK yet, instead, I created a regular Netduino project, changed its framework version to 4.2, and then added a reference to the Netduino GO libraries sent to me by Chris at Secret labs. Presumably, with the new SDK, the experience will be File->New->Netduino GO Application.

using System;

using System.Threading;

using Microsoft.SPOT;

using Microsoft.SPOT.Hardware;

using SecretLabs.NETMF.Hardware;

using SecretLabs.NETMF.Hardware.NetduinoGo;

using NetduinoGo;



namespace NetduinoGoFirstApp

{

    public class Program

    {

        public static void Main()

        {

            var led = new RgbLed((GoBus.GoSocket)8);

            led.SetColor(255, 40, 0);

        }



    }

}

Plug the RGB LED into any socket on the main board. (Netduino GO doesn't require you to match socket IDs or letters or anything). I used socket 8 in the example here. If you choose a different socket, just indicate that in the code.

Deploy and run that application, and you'll see a bright orange color from that LED. Those multicolor LEDs are very nice. They have excellent colors and are super bright, even at their default 33% brightness (100% would be insanely bright).

Here's the same code showing the LED in blue.

using System;

using System.Threading;

using Microsoft.SPOT;

using Microsoft.SPOT.Hardware;

using SecretLabs.NETMF.Hardware;

using SecretLabs.NETMF.Hardware.NetduinoGo;

using NetduinoGo;



namespace NetduinoGoFirstApp

{

    public class Program

    {

        public static void Main()

        {

            //var led = new RgbLed((GoBus.GoSocket)8);

            //led.SetColor(255, 40, 0);



            var led = new RgbLed();

            led.SetColor(0, 0, 255);

        }



    }

}

Note that in this case I didn't specify a socket ID. I only have one RGB LED module, so it identified itself to the main board using the GO!bus, and it just worked. I really do like that particular feature of the GO!bus as it means you can move modules around without changing code. This is great flexibility, especially if you're providing something that will go into an enclosure.

Each socket has an LED next to it on the main board. The socket being used for communication glows blue when the module is used from code.

If you have more than one identical module connected, it appears that the GO!bus just picks the first one it finds.

Varying the LED color with a potentiometer

Time to kick it up a notch. The kit I received has a potentiometer module and two buttons. I want to make it so the potentiometer can be used to change the color of the LED by varying the R, G, and B components independently. Ideally this would have three potentiometers, but as I have just the one, I decided to make it so the button cycles between R, G, and B, and the potentiometer changes one component at a time.

Here's the code.

using System;

using System.Threading;

using Microsoft.SPOT;

using Microsoft.SPOT.Hardware;

using SecretLabs.NETMF.Hardware;

using SecretLabs.NETMF.Hardware.NetduinoGo;



namespace NetduinoGoFirstApp

{

    public class Program

    {

        private static NetduinoGo.RgbLed _led;

        private static NetduinoGo.Button _button;

        private static NetduinoGo.Potentiometer _potentiometer;



        // r, g, b in an array

        private static byte[] _colorValues = new byte[3];

        private static int _colorIndex = 0;



        public static void Main()

        {

            _led = new NetduinoGo.RgbLed();

            _button = new NetduinoGo.Button();

            _potentiometer = new NetduinoGo.Potentiometer();



            _button.ButtonReleased += OnButtonReleased;



            _led.SetColor(0, 0, 0);



            while (true)

            {

                _colorValues[_colorIndex] = (byte)(255 * _potentiometer.GetValue());

                UpdateLedColor();



                Thread.Sleep(100);

            }



        }



        // switch between R, G, and B

        static void OnButtonReleased(object sender, bool buttonState)

        {

            _colorIndex = (_colorIndex + 1) % _colorValues.Length;

        }



        // set the LED color to the current selections

        private static void UpdateLedColor()

        {

            _led.SetColor(_colorValues[0], _colorValues[1], _colorValues[2]);

        }

    }

}

That was pretty simple to develop. A polling loop checks the potentiometer value 10 times a second, and updates the LED at the same time. Press the button to cycle between R, G and B components.

In this picture, note how the Netduino has blue LEDs lit next to each active socket. This helps you visually confirm which socket your drivers are using. The tiny blue LEDs aren't as bright as they appear in this photo, that's just my camera being annoying.

Conclusion

Secret Labs has come up with an interesting new platform here. I've only begin to scratch the surface, and haven't gotten into using the shield base for Arduino/Netduino classic shields, or described the process of creating a module from scratch. I'll write about those more in the future as I play with the devices more.

Should you go with Netduino GO or Gadgeteer?

That's a tough question for sure.

Right now, the decision is going to come down to what you want to do with the devices. The .NET Gadgeteer has, by far, a much richer ecosystem of modules by GHI and Seeed. Netduino may get there, but as it was just launched this week, it's not going to happen overnight. If you want the most immediate prototyping opportunities, using an existing set of plug-and-play modules, you'll probably do better with .NET Gadgeteer right now.

The Netduino supports existing Arduino-style shields just as it always has, but just as you had to before, you'll need to write (or find code for) drivers to make those work.

Long-term, I would expect the Netduino GO to also have a very rich ecosystem of modules. Plus, the potential of those individual modules is, in my opinion, greater, as the reall processing all happens on-module.

I'm really impressed with what Secret Labs has come up with, and believe it has some real potential. I like the formalization of the on-module logic design, and the fact that Secret Labs standardized on inexpensive chipsets with free compilers, making it easier for DIY folks to create their own modules. You can count me among the people who will take a stab at creating modules or module kits for this device.

I'll show off the Netduino GO, along with the Gadgeteer main boards and modules, in my talk at the free Online p&p Symposium on April 24th. Please register.

Windows 8 and the Windows Phone SDK, pt. 2

Windows Phone Dev Blog — 2012-04-06T02:06:53

Last month, I posted to let developers know that we were aware of some of the challenges that were present in running the Windows Phone SDK on the Consumer Preview of Windows 8. In that post I mentioned that we were working on addressing those problems. My colleague Cliff then followed up with the announcement of the release of the Windows Phone SDK 7.1.1 update, which does unblock the use of our SDK on Win 8, (although not officially supported).

Lots of people are digging into the new development platform opportunities provided by Windows 8, and we understand there are a lot of questions about what they may portend for Windows Phone developers. While we aren’t yet ready to talk about our future plans, we do believe there are certain things we can tell you. In fact, we’ve already talked quite a bit about this at the //BUILD conference last September (see our sessions recorded online at http://wpdev.ms/phoneatbuild).

With regard to existing applications: today’s Windows Phone applications and games will run on the next major version of Windows Phone. Driving application compatibility is a function of Microsoft’s commitment to its developers. Regardless of what we release in terms of new developer features and functionality, we have made a large investment in protecting your existing investments.

We’ve also heard some developers express concern about the long term future of Silverlight for Windows Phone. Please don’t panic; XAML and C#/VB.NET development in Windows 8 can be viewed as a direct evolution from today’s Silverlight. All of your managed programming skills are transferrable to building applications for Windows 8, and in many cases, much of your code will be transferrable as well. Note that when targeting a tablet vs. a phone, you do of course, need to design user experiences that are appropriately tailored to each device.

Microsoft is committed to creating an ecosystem that maximizes your investments. This is not an overnight endeavor, but we’re confident you’ll be pleased with where we’re going with the Windows Phone developer platform. As always, please let us know in the comments, or in our forums, if you have questions or concerns; we can’t answer every question just yet, but I hope we’ve dispelled some of your concerns.

Yet Another Podcast #62–Joe Stagner

Jesse Liberty [MS] — 2012-04-04T17:39:20

Optimize Startup Time

Windows Phone Dev Blog — 2012-04-03T18:48:00

The first of the four principles I mentioned in Optimizing Apps for Lower Cost Devices is Optimize Startup Time.

Fast startup is an essential component of any mobile application. It is the first impression a user has of your app and is the first chance you have to either impress or frustrate your users.

If you're wondering just how fast your startup time can get on Windows Phone, use the VS Project Templates as a starting point. Create a new project, deploy it to the device, and experience how quickly the app starts up.

A general principle to keep in mind is that any regressions in startup time from the VS Project Templates are the result of app code delaying the rendering of the first frame. The more app code you can remove or delay before the first frame is rendered, the closer your startup time will match the baseline startup time of the VS Project Templates.

To fully understand the areas of opportunity for improving startup time, it's important to understand the workflow of a launching application.

The App constructor is called in App.xaml.cs.
XAML in App.xaml is parsed.
Application_Launching is called in App.xaml.cs.
The Page constructor of your MainPage is called.
XAML in your MainPage is parsed.
OnNavigatedTo is called in your MainPage.

Once you understand this workflow, it is easy to conclude that any app code or XAML introduced in this workflow will result in startup time regressions from the VS Project Templates.

To minimize the impact of app code in this startup path, you should either remove code from these events or execute code on background threads to unblock the UI thread. Only code executing on the UI thread will have a severe impact on startup performance. Deferring activity to background threads will allow your first frame to render quickly. Use Dispatcher.BeginInvoke from background threads to return back to the UI thread when necessary.

To minimize the impact of XAML parsing on startup time, you can simplify and remove unnecessary XAML from both your MainPage and from App.xaml.

Remove unnecessary namespaces declared in <phone:PhoneApplicationPage>.
1. If your XAML elements aren't prefixed by a declared namespace, then the namespace declaration can be safely removed.
Avoid explicit declarations of default attribute values.
1. Grid.Row="0", for instance, is the default value if Grid.Row is not declared, so just don't declare it.
2. SupportedOrientations="Portrait" and Orientation="Portrait" can be removed as well for portrait only pages since this is the default.
3. Understand default values and remove redundant XAML.
Avoid retemplating controls in App.xaml.
1. Retemplating controls can require complex XAML which is expensive to parse.
2. For Metro-style apps that are theme-aware, this is less of a concern. If you need to retemplate controls to support a branded experience, for instance, then understand what is necessary to override and what can be omitted.
3. If templates are only needed for particular pages, consider moving the custom templates to the pages that need them. This will delay the cost of parsing the XAML until the necessary page is loaded rather than require the cost to be paid at startup.
Normalize Style declarations.
1. If you are consistently setting FontFamily, FontSize, and Foreground in a similar way on several TextBoxes, for instance, then consider using Styles instead.
Simplify page layouts.
1. Don't use nested Grids and StackPanels when one root container would be sufficient to layout your page.
Declare your app bar in code.
1. This will be faster to process than parsing the XAML and is actually the only way to localize your app bar components.

With your first frame rendered quickly, you can then turn your attention to indicating progress to the user while the rest of your content loads. Perceived startup time can go a long way to minimize the amount of frustration content load times can impose on users. The first frame of your app should always include the chrome of your application (system tray, app title, page title, pivot titles, app bar, etc.) as well as a ProgressIndicator to indicate that your content is loading. You'll want to use the ProgressIndicator over other progress bars as (1) the ProgressBar control has known performance issues and (2) the ProgressIndicator will provide the most consistent experience with the rest of the built-in experiences on the phone.

Note that the system tray and app bar are shell components and so will render more quickly than the content in your PhoneApplicationPage. You can take advantage of this to improve perceived startup time even further. You'll notice in the Weather app that the system tray and app bar appear first followed by the rest of the page content. If you're using the system tray ProgressIndicator as recommended above to indicate progress, it will appear as well immediately when the system tray is rendered.

A bonus to using both the system tray and app bar is that these components render together and provide a recognizable chrome for your app while it loads. Many apps hide the system tray and use only an app bar. If you've used these apps, you'll notice often that the app bar renders first before the rest of the content loads. The lack of symmetry in this case introduced by not showing the system tray actually contributes to the perception of lag that the user experiences. By adding the system tray, you can eliminate this perception while also providing a consistent chrome that is recognizable across apps. If you don't want to show the system tray but want to take advantage of it for the reasons mentioned above, show the system tray on launch with an opacity of 0. Using an opacity of 0 means the system tray won't affect your page layout at all. Once the rest of your content loads, you can then hide the system tray if you'd like.

Many apps use a splash screen to solve the perceived startup problem as it is cheap to implement and can promote the brand of the app. While this is a great practice, you may find that after following the guidance above, the splash screen will actually slow down your startup time. Adding a splash screen to the Weather app, for instance, would actually harm its startup performance. With your startup time optimized, assess whether a splash screen is really necessary. Your apps will actually feel more like integrated experiences if they don't use a splash screen, so don't be afraid to leave it off completely. The combination of fast startup time, no splash screen, and extensibility points like secondary tiles will really make your apps shine on Windows Phone.

The Internet is Not a Democracy (or: how not to gain customer confidence)

Pete Brown — 2012-04-03T10:01:21

Warning: this is as much a rant as anything remotely useful. Oh, and don't comment without reading the whole thing :)

The Internet is not a democracy. More specifically, blog commenting systems aren't a democracy. Blog authors and administrators get to decide which comments show up on their blog, and which do not. On my own blog, I remove spam messages (or I let Akismet do it in most cases), and the one or two truly offensive troll comments I get every once in a while -- usually only if a post hits reddit or /. . Other than that, I like to keep the spectrum of comments, good and bad, on my blog. I don't pre-moderate as that's just exudes untrustworthiness, and it's a pain to do.

Not everyone agrees with that approach.

The DIY 3d Printer Blog

When you see a blog post like this one, and see the overwhelmingly positive response, you're only seeing part of the picture. See, in this case, Junior moderates his comments and only lets through the ones which meet the goals of his business and his agenda. It's not a democracy, the blog owner gets to decide what shows up. Silencing opposition is a pretty big and powerful hammer. As a blog owner, I'm all for keeping this level of control with the blog owner. But also, as a citizen of the Internet, I try to be very fair and reasoned in how I wield it.

I've been looking forward to the release of his 3d Printer for quite some time. What Junior finally announced was a bit of a let down, but something I would still consider, as the resolution on the printer is spectacular. These two paragraphs in that post, however, set off a few alarms:

Because of this, we think would make more sense to move for only a basic kit, where we would provide all documentation needed to build the Printer, as well the Resin formula and just sell the software and the controller board. The documentation would have the detail technical specification, BOM and Suppliers.

This basic kit (Document + Software + Controller Board) would be sold around $600 USD, but even for that we would need a good volume to be able to produce it.
For this reason we're creating a Pre-order list for both Kits (full and basic), so we can decide the best way to move forward.

The controller board is fairly inexpensive. There are tons of multi-axis boards out there, including many OSH (Open Source Hardware) ones. Almost all are under $150. While I'm sure his controller board offers some additional things, it's probably nothing out of the ordinary. So the real value here is the software. This was further corroborated by his "Wow!!! Thanks for all the emails!!!" blog post where he enumerated several of the pricing tiers:

Software + Complete CD (399 USD - including shipping):
The CD above + full license of our software (features of the software will be in the FAQ)
Software price after Indiegogo: (549 USD)

Basic Kit I (Software + Controler board + Complete CD) (599 USD - shipping not included):
All items above + 1 controller board (able to control the entire printer).
(This basic kit does not include motors or linear guides or projector)
Price After Indiegogo: (849 USD)

...

Unfortunately we will be able to deliver only 250 full kits this year for this Indiegogo campaign, because of production limitation and we will probably just take new orders next year once we deliver all Indiegogo perks.

So Junior isn't *really* selling a printer. He's selling software. That's ok, just not quite what I had expected. As a business, it makes sense, as the software is where the margin is. In contrast, most other 3d printers sales are about selling the hardware, but the software is all free and open source, constantly improved by an active community of developers.

Anyway, $400 to $549 for CAD/CNC software from an individual or small business is a bit scary. So, I wrote a comment to Junior on the previous blog (before the pricing post, back when the alarms first went off), asking what his plans were for support and escrow of his software and code. When someone offers to sell me software multiple hundreds of dollars, and they're just an individual, and the software is proprietary, I want to know what the support policy is going to be. I wanted to know what guarantees he had in place, and if he's putting the source in escrow.

Why Escrow and Support are Important

Why is this important? His software is not OSS, and I don't want to get something proprietary and have him jump ship, leaving me holding something that can never be upgraded. This originally came to mind because Junior never answers questions on his blog or on twitter. Communication is strictly one-way. Back when I worked in the IT department of a company in MA, I helped develop a bit of very cool (but small) software we sold to hospitals. Because hospitals are huge multi-million dollar institutions, and we were not, they required the software and its source to be placed in escrow. That meant that if the company I worked for folded or otherwise failed to uphold its end of the escrow contract, the hospital would get the source code, data, and binaries for the application. This is important protection for any company or individual.

In another example: I bought some CNC software and hardware some time ago. Shortly after I bought that, the person/company who sold it went slightly psycho and shut down his support forums. Before that, if someone questioned him, he'd rip them a new one and kick them off his forums. He also tried to make the support forums a for-fee item after the fact. It was…strange. I stayed on his good side, but support by fear isn't exactly my cup of tea. Unfortunately, the hardware was proprietary and the software was also proprietary. That meant that he was the sole source of support if I wanted to stick with his products. I'm still stuck with a hardware/software pairing that can't be broken, and there's been almost no real innovation in the software. Ugh.

In any case, Junior didn't let my first question through on his blog. I was equal parts surprised and disappointed, as the comment was not a troll comment and also wasn't rude, or spammy or anything.

So, I wrote again (at 4/1 5pm eastern time), on the "Thanks for all the emails" post. Here's the exact post (I saved it this time):

Once again, I need to ask about the software.

You are an individual, selling custom proprietary (non OSS) software for a non-trivial price. What's the guarantee that you'll be around and will support your product? Are you putting the software and its source in 3rd party escrow? What's your support policy/plan? Bug fixes? Supported operating systems?

I know blogs are not a democracy, but please post the question this time. This is important stuff.

Thanks.

Pete

Unsurprisingly, that comment was also not posted on the 3d Printer DIY Blog. Comments posted before and after mine showed up in his nightly moderation batches. Both of mine were both posted using Google IDs with a photo -- they wouldn't have tripped a spam filter or anything. Junior also never answered any of my early queries over Twitter.

He could have answered it over email if he didn't want it publicly posted on his blog. Instead, the queries were just ignored. At the time of this writing, his FAQ doesn't address any of these concerns.

I was tempted to go to his new indiegogo campaign and post the question there, as I don't believe he can moderate posts. However, at that point, it would just be a vendetta, as he has clearly proven to me that he is not the kind of person I'm comfortable dealing with. $600 is not nothing. But hey. I see his indiegogo campaign is doing well, and there are lots of people for whom this isn't a concern. I do (seriously) wish him the best of luck with it, and I really do hope he does something to ensure that folks aren't left in the cold.

Contrast

This is in contrast to other products I've seen developed openly on the web. Shapeoko, for example, was developed in the open, had a successful Kickstarter campaign, a wiki with help, a free support forum, and Edward Ford went way above and beyond in answering questions. He was answering questions long before he had actual bits in people's hands.

Here's another one I've dealt with. John at Microcarve was happy to help me out when I bought a Z-axis mount from him. He answered all my questions and delivered above and beyond. He's also quite active in the CNC zone community. He didn't pop out of nowhere: he has a reputation and is trusted. He also has a Yahoo group for support of his products, Q&A etc.

Other more established examples include Chris Walker at Secret Labs (Netduino, Plus and Mini) and Gus Issa at GHI Electronics (Gadgeteer Hydra/Spider/Cerebus + Panda). Both of these guys are active in supporting their communities. Both make real money developing products that are, to various extents, open source software and hardware. Both are people I'm comfortable sending money to.

Lessons Learned

What are the lessons to be learned here?

If you're selling software, you need to be prepared to support it, and for the questions from people who want a few answers before shelling out. The people asking the hard questions could very well be your best customers and advocates. That's just good business.
You can make money selling software, but unless you're trying to build a big business out of it, you may find it easier to simply develop it in the open, as OSS. If your whole business is built around selling the software (which is what it appears Junior was working towards all this time - the printer itself is just ancillary), this may not work for you.
When you see overwhelmingly one-sided comments on a blog, and no one is asking the hard questions, ask yourself if you're really seeing the whole picture.
Indie campaigns that aren't OSS/OSH just feel old-fashioned.
Simply being reasonable in your feedback doesn't mean the blog author/business owner will post it or answer it. Blogs aren't a democracy. Ok, I take it back. They are a democracy, and I'm voting with my feet and my wallet.

Globalizing and Localizing a Windows Phone App

Windows Phone Dev Blog — 2012-04-02T18:05:00

With Marketplace recently launching in 13 new markets, it's more important than ever to have a globalized, localized app that can reach as many of your customers as possible – but doing so can seem daunting. This blog post seeks to demystify the process and help enable you to write a truly global app.

What is a globalized app?

A globalized app displays things like dates and money in a way that's familiar to a user. If you have a calculator app, some people will expect to see a dollar sign, and others will expect a euro. Or even more important, consider a financial app where a difference between a period in one country/region and a comma in another can change the currency amount by a factor of ten! Dates also differ by country/region – sometimes the month comes before the day, sometimes after. By globalizing your app, it'll feel natural to your customers, no matter where they are.

Globalizing your app is fairly straightforward, and can be done using the CultureInfo class. Check out How to: Build a Globalized Application for Windows Phone for a code example of how to use it.

This blog post will mostly focus on localizing your app – a meaty topic that can be tricky to understand.

What is a localized app?

You can think of a localized app as one that's been translated into one or more languages. There's a few things you can localize in your app:

App Text - menu headings, help text, etc.
App Description - seen in the marketplace
App Title - appears in the application list and on the app title
Application Bar text - if you include an Application Bar

Do I have to localize my app to publish in multiple markets?

No – the two actions are separate. When you submit your app to App Hub, you'll eventually reach a Pricing page where you can choose where your app will be published. You can either select specific markets or 'Worldwide distribution' to include them all.

It's important to understand that this is the only way you can choose where your app is published. Localizing your app is a separate process, and has no impact on where your app ships.

As a note, there are certain countries/regions that have stricter than usual content guidelines. If you decide to publish your app in these marketplaces, make sure you've read requirement 3.10 listed at Content Policies. Also keep in mind that your app must pass certification for all markets you choose – this means that if you choose 'Worldwide distribution', your app must pass certification for all of the supported markets. If you have trouble passing certification for certain markets, an option is to unselect those markets on the Pricing page.

If that's the case, why should I localize my app?

Because you want customers around the world to enjoy – and use – your app.

Let's say you write an app in English, and publish it worldwide. Even if they can physically see your app in their marketplace, someone who can speak and read only Spanish won't be able to understand your app description, and your app likely wont be useful to them. By localizing your app into the Spanish language, that customer would be able to use and understand your app.

When would I not want to localize my app?

There are a couple of cases where it might not make sense to localize:

App Title

Localizing your app title is often a good thing. Say you've created a calculator app, and the title is something obvious like 'Calculator'. By localizing your app title into French (France) and calling it 'Calculatrice', someone in the French marketplace will easily know what your app is.

On the other hand, what if your app title is your company name, such as 'Contoso App'? In this case your name is your branding – you don't necessarily want to localize that into other languages, because you're promoting your app under, and as, your company name.

Language-specific apps

Usually, you'll want to localize your app into multiple languages so you can reach the most customers. But what if, for whatever reason, you decide you only want to ever target a certain group of customers in a certain market? For example, you've written a Spanish news app that you want to market only to Spanish-speaking customers in Spain. In this case, you can save time and energy by not localizing your app into other languages.

That being said, even if your app only supports one language, it's still a good idea to structure your app so that it can be easily localized into other languages in the future.

I'm sold – how do I localize my app?

Localization includes multiple tasks – there are primarily four areas to consider, but we'll mostly focus on localizing app text.

App Title

The app title appears in the application list on the app tile. You can localize your app title by creating a resource-only DLL file for each language. How to: Localize an Application Title for Windows Phone has a full write-up of how to do this.

App Description

You've created an app, you've localized your app text into multiple languages, and you're ready to submit to App Hub. During the ingestion process, App Hub detects which languages you support and will prompt you to enter a language-specific description (and some other metadata) for each language you support.

Be sure that each description matches the language in question, as otherwise you'll fail certification. For example:

Application Bar

When it comes to localization, the Application Bar is handled differently than other controls in your app. If you include an Application Bar in your app, you can localize the text labels on each button. How to: Build a Localized Application for Windows Phone has a code example at the bottom of the page that you can use to do this. Also check out BindableApplicationBar on CodePlex for a third party solution. But before dealing with your Application Bar, you'll need to understand how to localize your app text, which brings us to…

App Text

App text is essentially any text that appears in your app except for the app title or Application Bar text.

How to I localize my app text?

Let's start with the most common case, and then move on to some edge cases. Basically, rather than hard-coding your text into a specific language in XAML, we'll localize your app text by using data binding to obtain the localized values of a word or string from a resource file.

To localize your app text, you'd do the following:

Specify the Neutral Language

Decide the language you want to be the 'default' for your app. This language in Visual Studio is known as the neutral language.

By default, Visual Studio sets the neutral language to the language you choose when installing the SDK.

This is important to understand because App Hub assumes that your neutral language is your default language. If you install the SDK with language set to English, unless you change the neutral language, any app you create will have its neutral language set to English. You need to make sure you change the neutral language to whatever your default language actually is.

This language has to be supported by Windows Phone, meaning it's listed in the Display languages table at Culture and Language Support for Windows Phone. If you choose something else that's not listed at the Culture and Language Support topic, you'll fail certification.

To set the neutral language in Visual Studio, open the project properties, click the Application tab, and then click Assembly Information.

For in-depth coverage on how to change the neutral language, see How to: Build a Localized Application for Windows Phone.

Create Resource Files for Each Language

Create a resource file for each language that you plan on supporting.

You'll first set up your default resource file, AppResources.resx. Your strings in this file have to be the same language of what you chose for your neutral language in step 1, or you'll fail certification.
Every other language besides your default is set up in its own file, labeled with the correct "culture name". For example, if you plan on supporting Spanish (Spain), you'd name your AppResources file 'AppResources.es-ES.resx'. For a full list of culture names you can use, see Culture and Language Support for Windows Phone. To learn more about how culture names are constructed, see the CultureInfo class. Put your language strings into each resource file, translated into that language.

Replace Hard-coded Text with Data Binding

Replace hard-coded text in your app and use data binding to reference values from your resource files.

For in-depth coverage on how to create these resource files, see How to: Build a Localized Application for Windows Phone.

What happens if I don't localize in some languages? Can those users read my app?

Yes. For example, let's say you've written an app in French (France). You want all of your text to be in French most of the time, but there's one or two strings you want to be different just for people with the Spanish (Spain) display language set.

You'd do the following:

Set your neutral language to 'French (France)'
Create a default AppResources.resx file and put your strings, in French, in the file
Create a AppResources.es-ES.resx file (es-ES is the culture name of Spanish (Spain))
Put only the selective strings in there that you want to be different for people with the Spanish (Spain) display language setting

So, what happens if someone with the Spanish (Spain) display language setting opens up your app? What about someone who is using English (United States) or any other display language?

Windows Phone uses the following algorithm to determine what text to display:

What display language is set on the device?
Is there a resource file in the app that matches that display languages?

a. If yes:

A. Is the string in the app located in the resource file?

i. If yes:

I. Show the translated string

ii. If no:

                                      I. 'Fall back' to the default language, in this example, 'French (France)', and show that string instead. In our example, this means that someone with English (United States) set will see the French (France) string, because there is no AppResources.en-US.resx file with a corresponding string.

      a. If no:

               A. 'Fall back' to the default language, in this example, 'French (France)', and show that string instead.

Notice that the same fall back behavior happens if either the resource file is missing entirely, or if the string isn't found in the file.

Based on the above algorithm, someone with the Spanish (Spain) display language set will only see a Spanish string if you've set that string up in the AppResources.es-ES.resx file. If not, you'll see the default (French) equivalent since it's set as the neutral language.

Likewise, if someone has English (United States) or any other display language set, they will only ever see the French strings, since there are no resource files or strings set up for those display languages.

How do I localize for specific regions?

Most languages have multiple regions associated with them. For example, there's the Spanish language, but there's different versions of it depending on region, such as Spain and Mexico. Each display language supported on Windows Phone is a specific combination of language and region, such as Spanish (Spain) or French (France). Where it gets tricky is that a user can control both their display language and the 'Region format' – and Region format shows far more options than the supported display languages.

Since not all strings are the same between language regions, what if you have an app that you want to localize for both the supported display language Spanish (Spain), and the unsupported Spanish (Mexico)?

Technically, you can do this by following steps similar to what you did in the previous example:

Choose Spanish (Spain) for your neutral language since it's the supported display language of the two, and add those strings in your default AppResources.resx file
Create a new resource file for Spanish (Mexico), which has a culture code of es-MX. You'd create AppResources.es-MX.resx, and put your Spanish (Mexico) strings in there.

Note: You can find a large list of culture codes at the National Language Support (NLS) API Reference page.

Seems like it would work, right? The problem is, even if the user has set their Region format to Spanish (Mexico), your AppResources.es-MX.resx file will not load. This is because Windows Phone will look for a resource file that matches whatever the user has selected for their display language, it will not look for a file based on the Region format.

There's a workaround that lets you get around this, you'll just need to add one line of code to the Application_Launching method of App.xaml.cs:

AppResources.Culture = CultureInfo.CurrentCulture;

By using this code, your app will show text from the resource file matching the Region format of the phone, not the display language. Like always, if you don't have a resource file that matches, the fall back process happens.

You can use this workaround to target any language region, as long as a user is able to select it on the settings page.

Make sure you choose the right neutral language!

Even with this workaround, for certification reasons, you need to make sure that the neutral language you choose is a supported display language.

Are regional descriptions supported on App Hub?

Let's say you submit the Spanish app we've been talking about to App Hub – you have Spanish (Spain) set up as your neutral language, you've created a regional file for Spanish (Mexico), and you have the right code in your app so the regional strings will display.

App Hub will only detect one language – Spanish. It maps this language to the display language we support, in this case, Spanish (Spain). You'll notice on App Hub that on the Pricing page, you'll be prompted to add a description and metadata for 'Spanish (Spain)', with no option to input different info for Spanish (Mexico).

How do I localize for a language that isn't supported?

We've talked through localizing for a region that a user can select on the phone, using Region format. But what about cases where you can't select the language or region at all?

For example, you decide to write an Icelandic news reader app. Even though Icelandic isn't officially supported on Windows Phone, the text would display in Icelandic to the user, because the phone supports the right fonts. But your app will fail certification because it must be localized in at least one supported display language. What to do?

There's a workaround for this, too. If you plan on shipping an app that is written in a language we don't support, and it's not available in Region format, you can do the following:

1. Hard code your app to be written in the unsupported language, if you don't plan on supporting more languages in the future. OR, create your default AppResources.resx file and put your unsupported language strings in there, if you plan on supporting more languages in the future or will support additional languages in your submission.

2. Set your neutral language to one of the supported display languages. For example, 'English (United States)'.

3. On App Hub, you will be prompted to input metadata and a description for the neutral language you chose (for the above example, you'll be prompted for English). You must include the following three items in the 'Detailed description' field to pass certification:

A note, such as ‘The language of this application is [unsupported language name]’. This note must be written in the same language as the neutral language. For example, if you chose 'English (United States)' as your neutral language, the note must be written in English (United States). This note must be the first item in the ‘Detailed description’ field.
Your app description, in the same language as the neutral language.
Your app description, in the unsupported language.

At the risk of making things sound even more complicated, you can technically do this one other way. Let's say you already have a news reader app that's localized into many languages, and you want to add support for Icelandic (an unsupported language). You can still do this, you'll just need to set up an additional resource file, using any one of the supported display languages you don't plan on localizing for, and go through the same metadata/description steps on App Hub.

Other localization resources

If you're porting an app from Windows Phone OS 7.0, take a look at this blog post by Mike Francis. He calls out some common errors you might run into when submitting your app to App Hub.
If you're localizing for any English variant, be aware that App Hub refers to them by different names than what's listed in the supported display languages table. See this Support post for more info.
And of course, there are also the MSDN docs.

A Million Little Programs

Charles Petzold — 2012-04-02T14:00:00

My programming tutorials tend to have lots of little programs to illustrate particular techniques, so as I've been working on the first several chapters of Programming Windows, 6th edition, here's what the far end of the Windows 8 Start screen soon became:

... more ...

Maker Geek Roundup 010 for 4/1/2012

Pete Brown — 2012-04-02T04:42:40

3d Printing, Laser Cutting, and CAD/CAM/CNC

Unbelievable! Thanks for all emails! (3d Printer DIY) (Junior announces pricing and a Indiegogo campaign)
Prototyping A Lunar Mining Robot On A MakerBot (MakerBot)
Four, no, Fourteen months.. part 5 of ? (Just Another RepRap)
Click, print and wear: a glimpse into 3D future (Brisbane Times)
MENDELMAX - Quick-fit X and Quick-fit Extruder/s (RichRap)

.NET Gadgeteer

.Net Gadgeteer Pomodoro Timer (jedibowler)
.NET Gadgeteer Motor Control with Potentiometer (Michael Dodaro)
- also .NET Gadgeteer Motor Driver with Two Motors and Potentiometer
Saving settings to XML Configuration Files (Marco Minerva)
Saving Sensor Data as Comma Separated Values (csv) on the SD Card (Michael Dodaro)
.NET Gadgeteer Relay Actuator via REST Web Service (Michael Dodaro)

Other .NET Micro Framework General (Netduino, GHI FEZ, etc.)

How-To: Write a Netduino driver for the Grove chainable RGB LED (Tim Mattison)
Modbus-TCP library for Netduino (Highfield Tales)
Latest MSDN Article (Colin Miller)

Arduino

Getting Started with the Fingerprint Sensor (Adafruit)
Controlling a Micro-Servo | Android + Arduino (Marc Tan)
Rain barrel irrigation system keeps your plants fed when you're too busy (Hack a Day)
Drummerbot Makes Beats with Arduino (Make)
RTC and port expander for an Arduino nixie clock (Electronics-Lab.com)

Other Microcontrollers (PIC, AVR, ARM, BeagleBoard, and more)

Road Testing an ARM LPC2101: Part 1a (Bot Thoughts)
Using 2 identical I2C device on the same I2C bus (solution working better) (Laurent Ellerbach)

General Electronics and Hardware Hacking

Coil-less FM Transmitter (Circuit-Zone.com)
4-Channel Pt100 Thermometer (Electronics-Lab.com)
Soldering the Binary Burst Clock PCB (Jumptuck)
Comparing digital and mechanical potentiometers (Electronics-Lab.com)

Robots and Robotics Studio and *Copters

Boston Dynamics Sand Flea Robot Demonstrates Astonishing Jumping Skills (IEEE Spectrum) (be sure to watch the video)
Makibot (Telepresence robot with Skype, controlled via PHP) (Priithansen.com)

Synthesizers, Music, and MIDI

NOISY JELLY on Vimeo (vimeo)
"What Is Love" - Bare Floppy Drives Make Beautiful Music (Retro Thing) (better than most similar things)

Photography

Build A CFL Based Continuous Light Source (DIY Photography)

General Maker

Redditor Builds Solar Powered Wikipedia Server (Tech the Future)
Soccer simulator rules a child's birthday party (Hack a Day)
Build an elevator controller, gain a friend for life (Hack a Day)

Retro Computing and Commodore!

Floppy autoloader takes the pain out of archiving 5000 Amiga disks (Hack a Day)
The best April fool! (MOS6502)
An unexpected link (MOS6502)
M-Tanks (MSX) (RGCD)
Genlock on the C64 (MOS6502)

WPF-Blogger.com [Language: en]

Programming Windows 6th Edition Preview Ebook Is Here!

Listbox, Why Art Thou Blanking?

MSDN Webcast series on building Metro style apps

Programming Windows 6th Edition Preview Ebook Coming!

Memory Profiling - The Heap Summary View

Heap Summary View

Summary

Silverlight 5.1.10411.0 Released Today

Building Metro style apps with C++ event is now a live webcast

Teaching kids electronics, electricity, and logic using littleBits

Electronics and programming

littleBits

Logic

One issue with littleBits

Building your own bits

Yet Another Podcast #64–John Papa & Javascript

Delivering Rich Mobile Web Experiences in Windows Phone 7.5 (ESPN.com Case Study)

Symposium Session: Gadgeteering and the .NET Micro Framework

Visual Studio Achievements For Windows Azure Buzz

Four ways we’re improving Marketplace

GridView Control in Windows 8

Two Marketplace changes; An update on 9 new markets

Respond to User Input

Insidious ByRef Legacy Code Issue

Announcing the Building Windows 8 apps with C++ Windows camp

Agenda:

2-4-6-8-10

Maker Geek Roundup 011 for 4/21/2012

3d Printing, Laser Cutting, and CAD/CAM/CNC

.NET Gadgeteer and Netduino GO

Other .NET Micro Framework General (Netduino Classic, GHI FEZ, etc.)

Arduino

Other Microcontrollers (PIC, AVR, ARM, BeagleBoard, and more)

General Electronics and Hardware Hacking

Robots and Robotics Studio and *Copters

Synthesizers, Music, and MIDI

Photography

General Maker

Retro Computing and Commodore!

Wanted!! Great Windows 8 Metro style apps

Using a Style to Simulate TextTrimming on TextBox

Can this be true? MSDN subscribers ignoring $4K of free Azure services

Memory Profiling - Launching, Graphs and Markers

Launching the Memory Profiler

Stop Profiling

Memory usage graph

Image load markers

GC markers

Insight

Summary

Using Parallel.ForEach To Aggregate Results From JSON Files Stored in Windows Azure Blob Storage

Workaround for CA0055 Error with Silverlight Projects in Visual Studio 2010

How to Reproduce the Issue … in theory

The Workaround

Handle Feature Reductions

Free Microsoft Azure Trial for your application

XAML Snippets and Visual Studio

Where to get .NET Gadgeteer and Netduino GO compatible 10 pin IDC sockets, and how to solder them

A comparison of socket implementations

Techniques for designing and soldering the connector

Step 1: Tin one pad

Step 2: Install the socket

Step 3: Secure the socket at the opposite corner

Step 4: Solder the remaining pins (including the first one)

Step 5: Inspect and Check

Coding Signing Internal Applications and a Gotcha

Win 8 Page Navigation

Turning Special Collection types (HttpCookieCollection) to Generic List

Here comes Windows 8

Adjusting to rapid Marketplace growth—and preparing for the future

Disabling Google Instant Search in IE Permanently

Browsing to website URL in a ViewModel

Cover art for my HLSL book on O’Reilly Media

Reduce Memory Usage

The Passing of another home computer legend: Jack Tramiel dies at 83

Yet Another Podcast #63–Windows 8 with Shawn Wildermuth

The Hello World of genetic algorithms

First Experiences with the new Netduino GO, and how it relates to .NET Gadgeteer

The Hardware