WPF-Blogger.com [Complete Feed]

Marketplace now open in 5 new markets

Windows Phone Dev Blog — 2012-02-03T18:02:28

I’m happy to report that the Windows Phone Marketplace is now officially open for business in 5 new markets around the world—Argentina, Indonesia, Malaysia, Peru, and the Philippines. We can’t wait to see all the great new apps you’ll create and publish for customers there.

As I mentioned a few weeks ago, if you’d like your existing apps to reach Windows Phone owners in these new places, just log into App Hub and select them from the list—or choose “worldwide” if you want your app to appear in all 41 of the markets Marketplace is now available in. (You’ll need to do this even if you’ve previously opted to make your app available globally.) Here’s a quick walkthrough.

Just a reminder that apps submitted to the Marketplaces for Indonesia, Malaysia and China (which is accepting apps but not yet open to consumers) will be subject to additional requirements due to local laws, regulations, or norms. For more details, see the Application Certification Requirements. If your app fails certification because of these additional requirements, you’ll need to update and resubmit it, or uncheck the submission boxes for those markets.

That’s it for now.

Complimentary Copies

Charles Petzold — 2012-02-02T18:00:00

When an author gets a book published, the publisher generally gives the author 10 complimentary copies of the book. Usually the author signs these books and gives them to all his friends, but then he has 7 or 8 copies still left over, and these tend to gather dust on the bookshelves of the author's home.

... more ...

[WP7] Usando los servicios de Live

llamo César Reneses [MVP] — 2012-02-02T01:20:22

Preparando una idea para un juego que tengo entre manos se me ha ocurrido que podría intentar conectar con los servicios que ofrece Live para ofrecer una experiencia mas social en el juego a parte de lo que es el propio juego. El SDK de Live nos permite hacer uso de Skydrive, los contactos y el [...]

Windows 8 Touch Events Interactions

Charles Petzold — 2012-02-01T13:00:00

During the week in September that I was attending the Microsoft Build conference and learning all about Windows 8, only one topic made me gloomy: This was the Windows 8 implemention of the Manipulation events. These events provide a high-level application programming interface to touch input, so obviously they are very important.

... more ...

Cell·SDK: El mismo código en Windows Phone, iOS y Android

Juan María Laó Ramos — 2012-02-01T13:07:59

¿Es posible ejecutar el mismo juego o aplicación en diferentes dispositivos móviles? La respuesta es: ahora sí. Me llena de orgullo y satisfacción anunciaros el lanzamiento del proyecto en el que hemos estado trabajando desde hace ya un tiempo en Syderis Technologies: Cell·SDK Podéis descargarlo de manera totalmente gratuita y empezar a probarlo. Os cuento, [...]

Event Handler Memory Leaks, Unwiring Events, and the WeakEventManager in WPF 4.5

Pete Brown — 2012-02-01T05:27:14

Many developers don't realize that a common source of memory leaks in .NET applications is the event handler. WPF 4.5 includes built-in support for weak events to help us do the right thing and not eat up all the available memory.

The Problem

Events are ubiquitous in .NET. When you add an event handler using the EventName += <my event handler delegate> syntax, the event source acquires a reference to the listener. This situation is a circular reference, as the listener had a reference to the source to begin with.

These references are "strong references". That is, they are actual pointers to resources.

In the .NET framework, circular references aren't usually a problem. If the set of objects can't be traced back to the root object in the application, they are garbage collected. That's great, but in this case, due to the references from the event source to the event listener, as long as the event source is reachable, the listener will also stay around, as the event source can be traced back to a valid object root.

This can be a real problem if the event source is long-lived, as is the case with things like application configuration objects, or other static or singleton objects. Event handlers are often on the UI side of things, so the listener can be a resource and memory heavy Window object.

Take this scenario: Over the course of an application's lifetime, the user opens and closes document windows. The document windows each have a reference to some other object: it could be the parent window, it could be a static configuration class, it could be a shared singleton data provider somewhere up the chain. The important thing is that the windows are listening to an event from that object: CollectionChanged, some custom DataLoaded or other event.

Now, when the parent window (and your code) releases all reference to the window instance, the event source still has a reference to them. And, because the event source also has a reference from the application (implicit if it's static - man that lifetime gets ugly), the windows stay around:

No GC or disposal for those window instances. Windows tend to have a lot of resources tied up just to paint (control templates, controles themselves, data even) so they're not cheap resources. It gets even nastier, though. If those instances have references to, say, individual ViewModel instances, and those ViewModels have references to a cache of data, you can end up with pretty enormous memory leaks. Open up enough windows and, eventually, your app will run out of resources.

Basis for Comparison

Before we look at the problem, here's a profile of the application opening 200 windows, closing the 200 windows, and then forcing a GC. I did this three and then closed the app. Each window allocates a bunch of memory in an array just to give it a payload. The window code looks like this:

public partial class TestChildWindow : Window

{

    long[] _memoryHog;



    public TestChildWindow()

    {

        InitializeComponent();



        Random rnd = new Random();



        string imageName = "Assets/image" + rnd.Next(1, 9) + ".jpg";

        NeatoImage.Source = new BitmapImage(new Uri(imageName, UriKind.Relative));



        _memoryHog = new long[1024];



        Unloaded += new RoutedEventHandler(TestChildWindow_Unloaded);

    }



    void TestChildWindow_Unloaded(object sender, RoutedEventArgs e)

    {

    }

}

In the upcoming examples, the TestChildWindow will have a reference to the SettingsManager. This is a stub class meant to represent pretty much any long-lived instance in your application.

namespace WpfWeakEventManager

{

    class SettingsManager

    {

        public event EventHandler SettingsChanged;



        private static SettingsManager _current;

        public static SettingsManager Current

        {

            get

            {

                if (_current == null)

                    _current = new SettingsManager();



                return _current;

            }

        }

    }

}

Finally, the Main Window has three buttons that I used to test the application. The first opens 200 windows. The second closes all windows (except the main one) being tracked by the application. The third forces a GC collection. It also has a listbox to show diagnostic information when I'm not running with an attached debugger.

namespace WpfWeakEventManager

{

    /// <summary>

    /// Interaction logic for MainWindow.xaml

    /// </summary>

    public partial class MainWindow : Window

    {

        private SettingsManager _current;



        public MainWindow()

        {

            InitializeComponent();



            // make sure SettingsManager is referenced outside

            // just the child windows. Normally this would happen

            // just do to general use of the class. Forcing it here.



            _current = SettingsManager.Current;

        }



        private void OpenWindowsButton_Click(object sender, RoutedEventArgs e)

        {

            int openedCount = 0;

            DebugList.Items.Add("Total Memory Before Opening Windows: " + GC.GetTotalMemory(true));



            for (int i = 0; i < 200; i++)

            {

                var window = new TestChildWindow();

                window.Show();

                openedCount++;

            }



            DebugList.Items.Add("Opened " + openedCount + " windows.");

            DebugList.Items.Add("Total Memory After Opening Windows: " + GC.GetTotalMemory(true));

        }



        private void CloseWindowsButton_Click(object sender, RoutedEventArgs e)

        {

            int closedCount = 0;

            foreach (Window window in Application.Current.Windows)

            {

                if (window != this)

                {

                    window.Close();

                    closedCount++;

                }

            }



            DebugList.Items.Add("Closed " + closedCount + " windows.");

            DebugList.Items.Add("App has " + Application.Current.Windows.Count + " window(s) it's holding on to.");

        }



        private void CollectButton_Click(object sender, RoutedEventArgs e)

        {

            GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced);

            //GC.Collect();

        }

    }

}

I experimented with a few variations on GC.Collect and some of the other notifications before the code that is here. A plain old GC.Collection will likely work just as well in any case.

Here's what the window looks like after I opened 200 windows and then closed them and then opened another 200. 200 windows is actually a lot of windows, as it turns out, but if you consider an application where your user opens up 1 customer record every 5 minutes (for a phone support person, this is conservative), over the course of an 8 hour day, that could be as many as 160 forms, and that's assuming they close the application every day when they leave.

Now I needed to find a good way to track memory usage. The profiler in Visual Studio is really good for finding performance bottlenecks, but not really meant for the real-time memory usage graphing I wanted to do. So, I downloaded the 10 day trial of .NET Memory Profiler (an app I used a lot back when I was consulting) and had it capture data while I performed the above actions.

In this graph, the pink line is the active memory in use in bytes, the green line is the number of root references. (note: none of the memory graphs include memory from on-window images. I ran without the cute images, but I left the code in the form and the images in the screenshot just because)

Remember, this is without any of the circular reference problems discussed so far. Now, let's take a look at the same actions when I have an event handler wired up in the constructor of the window.

Notice something about that graph? Yep. Memory just isn't being returned. It's leaking, and the root references keep on climbing. The only difference between this profiled version and the previous was that I added the SettingsManager event handler wireup in the constructor:

public partial class TestChildWindow : Window

{

    long[] _memoryHog;



    public TestChildWindow()

    {

        InitializeComponent();



        Random rnd = new Random();



        string imageName = "Assets/image" + rnd.Next(1, 9) + ".jpg";

        NeatoImage.Source = new BitmapImage(new Uri(imageName, UriKind.Relative));



        _memoryHog = new long[1024];



        SettingsManager.Current.SettingsChanged += Current_SettingsChanged;



        Unloaded += new RoutedEventHandler(TestChildWindow_Unloaded);

    }



    void Current_SettingsChanged(object sender, EventArgs e)

    {

        // do something

    }



    void TestChildWindow_Unloaded(object sender, RoutedEventArgs e)

    {

    }

}

The Unloaded handler is empty, but it is wired up. The key change here is the SettingsManager.Current.SettingsChanged wire-up.

There are a multitude of considerations in this example, but let's deal with just the topic of this post: the event handlers.

Solution 1: Unwire Your Event Handlers

This generally doesn't work if you use anonymous delegates (one reason to be careful about using them with objects that live outside the scope of a single method), but in cases where you have a real event handler method, unhooking them when you're done with them is definitely a best practice.

You can remove event handlers in Dispose methods, or in the case of a window, in the Unload event handler. That's what I did here. The code is a simple change:

void TestChildWindow_Unloaded(object sender, RoutedEventArgs e)

{

    SettingsManager.Current.SettingsChanged -= Current_SettingsChanged;

}

All I did was remove the event handler inside the Unloaded handler. Take a look at the impact it had on memory:

That's much better. The root references and memory both drop when I hit the "collect" button. Compare this to the previous example where the memory never went down. As to the differences between this graph and the first one, chalk it up to sample timing and my own non-deterministic button pushing.

So, that's a great approach. In fact, if you can do this, you should do this. It's simple and highly effective.

For other situations, perhaps where you don't control all the code, or when unwiring events is difficult or inconvenient, there's the Weak Event Pattern.

Solution 2: Weak Events

It's not always possible or practical to unwire event handlers. Actually, let me rephrase that: sometimes the level of effort and thought that needs to go into *where* you put event handler unwiring is more than developers have time to put into the app. :)

Enter the Weak Event Pattern

The concept of a Weak Event is nothing new. Many others have created their own various weak event solutions for use with WPF. Previous versions of .NET and WPF included the WeakEventManager, but required you to derive your own class and implement IWeakEventListener interfaces. That was a fair bit of work for developers who just need to get stuff done. The real news here is that WPF 4.5 includes the generic WeakEventManager type to make it easier for you to implement the weak event pattern in your own code, without all the other ceremony. You can still derive from WeakEventManager (if you can do the work, it's actually a good practice due to the performance benefits you'll get from it via having actual events and not reflection look-ups), but the new generic class makes it easy enough so that there's no excuse *not* to do it.

Here's the memory usage of the application using Weak Events

And here's the code change. I removed the code to unwire the event, and did the event wireup using WeakEventManager rather than regular old events.

namespace WpfWeakEventManager

{

    /// <summary>

    /// Interaction logic for TestChildWindow.xaml

    /// </summary>

    public partial class TestChildWindow : Window

    {

        long[] _memoryHog;



        public TestChildWindow()

        {

            InitializeComponent();



            Random rnd = new Random();



            string imageName = "Assets/image" + rnd.Next(1, 9) + ".jpg";

            NeatoImage.Source = new BitmapImage(new Uri(imageName, UriKind.Relative));



            _memoryHog = new long[1024];



            // this version wires up an event handler which causes a hard reference

            // and, unless it is unwired, a memory leak

//            SettingsManager.Current.SettingsChanged += Current_SettingsChanged;



            // unwire the event handler. This is a good practice for avoiding leaks

//            Unloaded += new RoutedEventHandler(TestChildWindow_Unloaded);



            // this version avoids memory leaks without requiring you to

            // unwire the event.

            WeakEventManager<SettingsManager, EventArgs>

                .AddHandler(SettingsManager.Current,

                            "SettingsChanged",

                            Current_SettingsChanged);

        }



        void Current_SettingsChanged(object sender, EventArgs e)

        {

            // do something

        }



        void TestChildWindow_Unloaded(object sender, RoutedEventArgs e)

        {

//            SettingsManager.Current.SettingsChanged -= Current_SettingsChanged;

        }

    }

}

This new WeakEventManager is much easier to use than anything we had before. You take a hit for relying on reflection to resolve the event name, but in all but the most performance-sensitive cases (where you probably wouldn't bother with events anyway), it's going to be worth it.

Summary

Event handlers and long-lived objects can be the source of memory leaks in any .NET application. Whenever you can, you should unwire your event handlers to help avoid these leaks. When that is impractical, the Weak Event Pattern using the WPF 4.5 WeakEventManager<TObject, TArgs> is a great way to help save you from the grief of memory leaks without requiring all the ceremony we had with the regular WeakEventManager and IWeakEventListener in the previous versions.

Now there's no excuse to have leaky event handlers.

12 Horas de Visual Studio - Exprime las vistas en ASP.NET MVC

Luis Guerrero — 2012-01-31T19:57:00

Este es el material que voy a utilizar sobre mi charla sobre “Exprime las vista en ASP.NET MVC”

El código de ejemplo os lo podéis descargar de aquí, http://bit.ly/12HorasMVCCode

Aliasing en Texturas

Juan María Laó Ramos — 2012-01-31T20:30:32

Nueva entrega de la serie sobre técnicas de antialiasing, esta vez en DesarrolloWeb.com. Espero que os sirva

Memory Profiling for Application Performance

Windows Phone Dev Blog — 2012-01-31T19:50:33

Performance is a concern for all but the most trivial of applications, and in a constrained environment like the phone it is all the more so; performance issues directly manifest themselves in the user experience. Memory usage is one such source of performance issues that can degrade user experience, and the Windows Phone Marketplace enforces a technical certification requirement that an application must not exceed 90 MB of RAM usage, except on devices that have more than 256 MB of memory.

What could cause 90 MB of usage in a garbage-collected runtime? There could be several causes:

Allocating too much.
Long living objects that bloat working set.
Holding on to references unintentionally leading to memory leaks.

Applications allocating too much could end up with working sets breaching this threshold; applications with a large working set might eventually exit with an “Out of Memory” exception; and holding on to references unintentionally can lead to memory leaks causing working set to increase steadily and stealthily, eventually leading to the application exiting with an “Out of Memory” exception.

Up until the Windows Phone SDK 7.1 release, application developers had to guard against this by programmatically instrumenting their code with specific framework method calls and track memory usage. These methods included the following:

But beyond that there was little help from the tools.

The Windows Phone SDK 7.1 addresses this through the introduction to profiling tools to analyze the execution, visual, and memory characteristics of an application.

Install the SDK now, and let us walk through the Memory Profiler as we investigate a case of a memory leak caused by unintentionally holding on to references.

A Sample Application

Consider this application that has two pages, and where the second page renders several images within a grid, and where one may navigate between pages.

Page2 has 4 images controls within a grid control that is bitmapcached. During the initialization of Page2, it binds the 4 image controls to jpeg images and registers for an event handler.

The two pages look as follows:

As we try out the application going back and forth between the pages a few times, observe that memory usage keeps going up; there is a memory leak.

Visualizing the leak

To delve deeper into this leak further let us run this application through the Memory Profiler using the following steps:

Invoke the Profiler, choose “Memory (managed object allocation and texture usage)”, and launch the application. Note the memory used by the application at the top of the screen.
Click on Go To Page2. This will launch Page2, and display the 4 flower images.
Click on the back button.
Click on ‘Force GC’. Note the memory used by the application at the top of the screen. Observe that it does not go down.
Repeat steps 2, 3, 4 four more times.
Now click on ‘Stop Profiling’.

We should see a graph like the following:

As expected memory usage is steadily growing.

Analysis

Select a range, from before the start of the first plateau to just after the after the start of the last plateau, for analysis. Once analysis is complete, using Performance Warnings as the starting point, navigate to the Heap Summary view. We should see a table similar to the following:

Note that the memory held by Retained Silverlight Visuals at End is large as compared to that held by just managed objects. So, let’s drill down into these retained Silverlight visuals.

Select Retained Silverlight Visuals at End and navigate to the Types view. In the Types view, sort the Total Size (Bytes) column in descending order. We should now see a table similar to the following:

Note that Grid and Page2 are the heavy consumers. We also notice right away that 5 instances of Page2 are hanging around. In our scenario, we navigated 5 times to Page2, remember?

Let’s look at what those 10 instances of the Grid are: click on the Grid and navigate to the Instances view. We should now see a table similar to the following:

Note that 5 of the instances are being allocated from Page2. Click on the hyperlink and you can go the line of code in XAML where the Grid is allocated.

To see what is the memory being retained by the visual tree rooted at a Grid instance, click on, say, the grid with the ID 33 (this is a grid allocated from Page2), and navigate to the Visual Tree view. We should now a table similar to the following:

Note the visual tree rooted at that grid instance. We can see the 4 contained image controls, as well as the Texture memory associated with the grid.

To cross check the association between the grid instance and Page2, we can go back to the Types view, select Page2, and navigate to the Instances view. We should then see a table similar to the following:

Notice that there are 5 instances created and none of them has been destroyed (i.e. garbage collected).

Now let’s look at the Visual Tree rooted at a Page2 instance. Select the first instance, and navigate to the Visual Tree. We should see a table similar to the following:

Again, we see the grid, its associated texture memory, and its contained image controls. Earlier we saw that 5 instances of Page2 were hanging around. That leak was causing the associated grid, images, and texture memory to not get cleaned up.

Now let us see why the Page2 instances were hanging around.

Go back to the Instances view, select the first Page2 instance, and navigate to the GC Roots view. Collapse the tree structures. We should see a table similar to the following:

Ignore the weak references (these do not prevent the GC from acting on the references). But look at the TouchFrameEventHandler; expand it and we should see a table similar to the following:

There are 5 chained event handlers! The first one was allocated from our assembly. The rest were cloned within mscorlib, as each page appended its own TouchFrameEventHandler (the event handler is implemented as a .Net Delegate type). That event handler is holding a reference to the page that in turn is preventing the page from being garbage collected.

So the eventhandlers references the Page2 instances, preventing it from being GC’d; and thus assets contained in Page2 are not cleaned up (the grid, associated texture memory, images).

Solved!

All that remains to be done is to find where that handler is being registered in our assembly.

Go back to Heap Summary, select Retained Allocations at End, navigate to the Types view, sort by Type Name column, and scroll down to locate the TouchFrameEventHandler. We should see the following:

To find out where that 1 instance was allocated in our application code, select the first entry, and navigate to the Methods view. You should see the following:

Click on the Allocating Method hyperlink, and you will jump to the method that did the allocation. You should see the following:

There, right at the bottom is the place where we register to the eventhandler! The step of registering stashes away a strong reference to this instance of the page within the event handler delegate. Unless the user unregisters this handler, the Page2 instance will remain alive (and consequently so too will the grid and the images, and the texture memory will not get cleaned up).

If you comment out the line that enregisters the handler, and rerun this scenario, here is the graph you would see:

Voilà!

Conclusion

Having a garbage collected runtime removes one of the biggest sources of program errors, memory allocation errors; you no longer have to worry about freeing memory which you no longer use. But leaks spring when you unintentionally hold on to object references that you no longer use. By providing a variety of Views on the applications memory usage the Memory Profiler can be a valuable tool to detect and fix such leaks.

12 Horas de Visual Studio - Calidad de Software y patrones de diseño en Windows Phone 7.5

Luis Guerrero — 2012-01-31T15:56:00

Hoy es el evento de 12 Horas de Visual Studio de Microsoft y Globbtv, podeis ver el evento en directo aquí http://www.globbtv.com/vstudio12horas/

Este es el material que voy a utilizar sobre mi charla sobre “Calidad de Software y patrones de diseño de Windows Phone 7.5”

El código de ejemplo os lo podéis descargar de aquí, http://bit.ly/12HorasVSWindowsPhone

Yet Another Podcast #58–Julie Lerman and EF/CF

Jesse Liberty [MS] — 2012-01-31T17:34:48

Happy 75th Birthday, Philip Glass!

Charles Petzold — 2012-01-31T11:00:00

About 14 months ago I saw the New York premiere of Philip Glass's Concerto for Violin and Orchestra No.2 at Carnegie Hall performed by violinist Robert McDuffie and the Venice Baroque Orchestra. McDuffie had commissioned the Glass work (subtitled "The American Four Seasons") for a program that also included the four violin concertos collected by Antonio Vivaldi as The Four Seasons almost three centuries earlier, and McDuffie took the program on a tour of 30 American cities.

... more ...

Jetzt Backbone.js lernen: Konzept WPF-Blogger

Norbert Eder [MVP] — 2012-01-31T12:00:00

Bevor es so richtig mit Backbone.js los geht, möchte ich das neue Konzept von WPF-Blogger vorstellen, die grundlegenden Features beschreiben und über den generellen Aufbau als solchen berichten. Es sind zahlreiche Änderungen angedacht. Aus dem Feed-Aggregat soll eine Site mit weit mehr Benutzer-Interaktion entstehen. Einige Funktionalitäten stellen jedoch auch lediglich Überlegungen dar, die ich gerne zur Diskussion freigeben möchte. Aber mehr in dieser Vorstellung.

Status Quo

WPF-Blogger war ursprünglich als reines Feed-Aggregat konzipiert. Ziel war es, Feeds zum Thema WPF zu bündeln und Interessierten gesammelt zur Verfügung zu stellen. Folgende Features wurden in der ersten Version inkludiert:

Feed-Aggregation von ausgesuchten Blog-Feeds
Mehrsprachigkeit
Registrierung von neuen Feeds
Übersicht aller registrierten Feeds
Archiv inklusive Suche
Gesamtfeed und Sprachfeeds
Statistiken

Umgesetzt wurde die Website mit ASP.NET und WebForms und ganz, ganz wenig JavaScript.

Feed-Aggregat

Für das Aggregieren der Feeds läuft ein eigener Job, der zeitgesteuert sämtliche Feeds hin auf Neuigkeiten prüft bzw. bereits importierte Artikel aktualisiert. Dieser bleibt durch die Neuentwicklung der Website unberührt, da alle wesentlichen Funktionen enthalten sind.

Quo vadis?

Das ursprüngliche “Konzept” war hauptsächlich auf mich persönlich zugeschnitten. Es sollte eine Stelle sein, an der ich alle interessanten Blogs zum Thema WPF sammeln kann. Da dies auch für andere von Interesse sein konnte, hatte ich mich damals kurzer Hand entschlossen, eine eigene Website online zu stellen.

Im Laufe der Zeit hat sich gezeigt, dass das Interesse für diese Site da ist, jedoch fehlt vielen (auch mir) die Möglichkeit selbst Informationen einzustellen bzw. gute Inhalte zu teilen - kennt man schließlich auch von anderen Webangeboten. So das Feedback.

Nun gut, aber wie sieht es um den geplanten Funktionen aus?

Login über Drittanbieter. In der ersten Implementierungsphase wird Twitter implementiert. Als Erweiterung sollen Facebook und Google Plus ebenfalls angeboten werden, um möglichst wenige auszuschließen. Gewisse Funktionalitäten sind nur im eingeloggten Zustand möglich.
Suche. Eine Suche war bis dato über das Archiv bereits möglich. Dies wird weiterhin möglich sein, soll aber präsenter platziert werden.
Sprachauswahl. Wie bisher soll auch die Sprachauswahl weiter bestehen bleiben. Durch diese wird bestimmt, aus welcher Sprache Ergebnisse anzuzeigen sind. Die generelle Sprache der Website ergibt sich durch die Browsersprache.
Sharing Content. Es soll möglich sein, einzelne Artikel über unterschiedliche Kanäle zu verteilen, um guten Content bestmöglich verteilen zu können. Angeboten sollen Twitter, Facebook und Google Plus werden. Zusätzlich soll es möglich sein, Artikel für das spätere Lesen zu markieren. Dies kann wahlweise in der Applikation selbst (man muss angemeldet sein) oder über die Anbindung von Drittanbietern (Read It Later etc.) geschehen.
Statistiken. Diese sollen helfen, gute und interessante Inhalte schnell aufzufinden. Diese beziehen sich auf Topics, Autor und Aufrufen.

Nachfolgend findet sich ein Screen-Mock, der den Aufbau im ausgeloggten Zustand näher beschreibt.

Loggt sich der Benutzer ein, erhält er neue Möglichkeiten. Im ersten Schritt ist angedacht, ein Blog bzw. einen neuen Artikel einzustellen. Unter den Aktionen (rechts oben) können dann benutzerspezifische Einstellungen vorgenommen werden. Der Rest der Seite bleibt unverändert.

Allgemeine Verwendbarkeit

Eines der Ziele dieser Umsetzung ist, dass die entstehende Anwendung breiter eingesetzt werden kann. Sie soll den Grundstock für Feed-Aggregationen bieten, jedoch nicht auf diesen speziellen Anwendungsfall beschränkt bleiben.

Eingestellte Blogs und Artikel

Sämtlicher eingestellter Inhalt, der nicht aus einer vertrauenswürdigen Quelle stammt wird geprüft. D.h. ein neu eingestelltes Blog wird nicht automatisch aggregiert, sondern landet auf einer Liste von zu prüfenden Quellen. Damit soll zum Einen vermieden werden, dass Spam in der Auswahl landet, zum Anderen ist es durchaus sinnvoll, sich zuerst die Erlaubnis des Blogbetreibers einzuholen (wenn dies im Internet offensichtlich auch kaum üblich ist).

Neue eingestellte Artikel werden ebenfalls geprüft und freigeschalten. Auch hier soll es vermieden werden, dass Spam publiziert wird. Beiträge von Benutzern, die bereits 2 (oder eine andere zu konfigurierende Anzahl) freigeschaltete Artikel eingestellt haben, werden automatisch publiziert, da diese als vertrauenswürdig eingestuft werden. Dies kann über die Administration jederzeit rückgängig gemacht werden.

Administration

Die Administration soll im Wesentlichen folgende Funktionen bieten:

Benutzerverwaltung
Verwaltung der Blogs
Verwaltung der eingestellten Beiträge (Beiträge via Blog-Feeds werden in dieser Liste nicht behandelt)
Verfügbare Sprachen
Diverse Einstellungen

Die Administrationsseite wird Benutzern mit entsprechender Rolle über die Aktionen angeboten.

Nichtziel

Es ist kein Ziel von WPF-Blogger, die gesamten Inhalte anzuzeigen. Der Autor soll honoriert werden. Aus diesem Grund werden auch weiterhin nicht die gesamten Beiträge angezeigt, sondern lediglich ein Teaser.

Offene Fragen / Feedback erwünscht

Es gibt meinerseits einige Überlegungen, die grundsätzlich gut zur Neuentwicklung von WPF-Blogger passen würden, bei denen ich mir allerdings nicht zu 100% sicher bin. Ich möchte sie an dieser Stelle zur Diskussion stellen, in der Hoffnung auf Feedback.

Bewertung

Von einschlägigen Seiten (siehe beispielsweise DotNetKicks oder der deutschsprachigen Umsetzung) ist man es gewohnt, Beiträge bewerten zu können, um so die Spreu vom Weizen zu trennen. Das ist grundsätzlich eine gute Sache. Im Endeffekt ist mein Ansatz aber der Aktualität gewidmet. Der Benutzer soll einen schnellen Überblick erlangen, was sich in den abgedeckten Bereichen tut. Nichts desto trotz sollte er - meiner Meinung nach - doch auch eine Rückmeldung erhalten, welcher Inhalt von anderen empfohlen wird. Anstatt einer direkten Bewertung kann dies aber auch durch die eigentliche Statistik-Auswertung geschehen. Links, die häufig geklickt werden, scheinen grundlegend interessanter zu sein, als solche mit wenigen Aufrufen. Daraus könnte eine Bewertung abgeleitet werden, ohne den Benutzer zu einer Bewertung zu nötigen.

Kommentare

Wünschenswert wäre eine Möglichkeit Kommentare zu hinterlassen. Die Ideallösung wäre, dass sämtliche Kommentare an das eigentliche Blog zurückfließen und dem Verfasser des Artikels zu Gute kommen. Allerdings habe ich hierfür noch keine zufriedenstellende Lösung gefunden, wodurch ich die gesamte Funktionalität in Frage stelle. Meinungen?

Ausblick

Der nächste Artikel der Serie über Backbone.js beschäftigt sich mit dem Thema der Suchmaschinen. Darin wird hinterfragt, für welche Teile der Website der Einsatz von Backbone.js tatsächlich geeignet ist. Soll heißen, welche Inhalte werden statisch ausgeliefert und welche erst durch den Client erstellt.

The .NET Gadgeteer Diaper Alarm Part 1 (Moisture Sensor)

Pete Brown — 2012-01-30T23:22:37

During the .NET Microframework and .NET Gadgeteer code camp talk that Andrew Duthie and I gave several weeks back, we tossed around the idea of using the Gadgeteer and a moisture sensor to alert parents of, ahhhh, soggy diaper issues.

Shortly before the holidays, in the mail, I got a package of goodies from Microsoft Research. That package included one of these moisture sensors from Seeed Studio. These are meant for checking to see how wet soil is, but I figure one man's diaper is another man's soil, so, I can't resist. Must…prototype…solution.

WARNING: Science in Progress. Also: diaper jokes.

First Iteration

I didn't have any of that handy inoffensive blue liquid available (the stuff they use to represent *any* bodily fluid on commercials; pretty sure that's how Smurfs are grown), so lacking any actual babies (my kids are all potty trained now. Yay!) I'm using plain old water. The real thing is a bit more conductive, so you may need to vary some values I use. Also, I'm dealing with liquids only in this post. You're on your own with anything more…substantial, but I might recommend some sort of scale, or for the newborns, perhaps a blast detector held on with this.

Hardware

I'm using the Moisture Module from Seeed Studio. (You can also purchase it through GHI as they have a partnership.) This module returns back an analog voltage that is proportional to how wet the area is. As mentioned, it's is really meant to be used in soil, to tell you if you need to water your plants, so we'll have to finagle a few things to make it work here.

It's wired to socket 9 on my Gadgeteer board. That's one of the two analog sockets on the GHI Electronics Spider. I had one of the extra long ribbon cables which was perfect for this. You don't want the rest of your modules anywhere near what we're doing here. Also, this probably works best with babies who are relatively sedentary, preferably sleeping. Otherwise, you'll end up with a miniature Borg running around the house trailing some sort of dangling box of electronic goodies.

Warning: I'm reasonably certain that none of this is actually baby-proof.

Yee Old Test Subject

Next, I need something to test in. No, don't go there as my wife would not appreciate getting that kind of laundry from me, not even in the name of science. I'm pretty sure I could get my almost-6 year old son to cooperate if I offered LEGO or something as a reward, but that'd also get me on the naughty list. Lacking other creative solutions, I'm just going to use a small plate and a paper towel to see how this all works.

I'll wet the towel, and wait until the moisture starts to hit the sensor. Then I can adjust for sensitivity. The idea is not to make the sensor swim, but to get an idea of how we the towel needs to be for this to work. Remember, the sensor is designed to be stuck in soil, not placed down on a towel.

Software

Be sure to download the latest Gadgeteer SDK and driver package. The latest rev (as of this month) includes support for all the GHI and Seeed modules on the market, including this one. Once you'd done that, it's time to create a new project. Open up Visual Studio and create a new .NET Gadgeteer Project. I named mine DiaperMonitor.

Next, add the main board, if it's not already there. By default, mine came up with the FEZ Hydra, presumably because that's the last one I used. I simply removed that and dragged on a FEZ Spider from the list of main boards in the toolbox.

Next, I added a Seeed.MoistureSensor module. You can either connect it automatically, or pick the port yourself and drag the connection to create the link. I have the moisture sensor on socket 9 as shown here. I also added one of the brand new GHI LED7R modules just to give us something interesting to light up.

If you don't have one of the new LED7R, you can use any LED module and simply change the code we'll use for the light up.

Le Code

The first iteration of code is simply going to check the moisture level, and light up the LED7R when the moisture level makes it over a certain threshold. On the Gadgeteer, you don't want to have a tight loop running from the ProgramStarted method - doing so would prevent other event handlers from running.

The code for the sensor is really simple. If you look at the sensor itself, it appears to simply send a voltage down one side of the tongs and checks for conductivity with the other side. The driver uses a digital output for sending and an analog input for receiving. I was actually surprised to find a through-hole NPN transistor (it's a TO-932 package 2N2222 amplifier marked 2N2222 H331) in there, as almost everything else gadgeteer-related uses surface mount components (including the two resistors on the board), but I know the 2N2222 itself is difficult (impossible?) to find in an SMT package.

I'm far from an electronics expert, but my guess is that one side of the fork sends the regular (apx) 3.3v signal from pin 3 into the dirt/diaper. The other side will get a very faint amount of voltage transferred through the medium which it then amplifies with the transistor in order to make it meaningful to the microcontroller.

So, instead of using a polling loop, I kick off a timer to handle polling the sensor. The timer is set to poll once per second and compare the returned value to the minimum moisture level. If the level is passed, then the LED7R animates once and then stays on. After changing the diaper, you reset the Gadgeteer to restart the program. Inelegant, but simple.

using System;

using System.Threading;

using Microsoft.SPOT;

using Microsoft.SPOT.Presentation;

using Microsoft.SPOT.Presentation.Controls;

using Microsoft.SPOT.Presentation.Media;

using Microsoft.SPOT.Touch;



using Gadgeteer.Networking;

using GT = Gadgeteer;

using GTM = Gadgeteer.Modules;

using Gadgeteer.Modules.Seeed;

using Gadgeteer.Modules.GHIElectronics;



namespace DiaperMonitor

{

    public partial class Program

    {

        private GT.Timer _pollingTimer;

        private int minimumBadMoistureLevel = 200;

   

        void ProgramStarted()

        {

            Debug.Print("Program Started");



            _pollingTimer = new GT.Timer(1000);

            _pollingTimer.Tick += OnPollingTimerTick;



            _pollingTimer.Start();

        }



        void OnPollingTimerTick(GT.Timer timer)

        {

            int moisture = moistureSensor.GetMoistureReading();



            Debug.Print(moisture.ToString());



            if (moisture > minimumBadMoistureLevel)

            {

                AlertParents();



                timer.Stop();

            }

        }



        private void AlertParents()

        {

            lED7R.Animate(10, true, true, true);

        }

    }

}

This approach is nice, but doesn't do another loud or obvious. You'd have to keep looking in the room and checking for the lights. Chances are, the baby's own internal alarm would start sounding before you noticed the lights. In addition, this doesn't allow for any configuration of level, so on a hot summer night (thank's to Sammy Hagar, that song is now stuck in my head), there may be a general level of damp which doesn't quite meet the bar for a burst dam.

So we have two problems: one is configuration, the second is for meaningful alerts. Let's look at configuration first.

Second Iteration - Configuration

The next step is to configure that alert level. You can leave it as a fixed value in code, or you can configure it via any number of other external inputs. One approach would be to use a potentiometer to set a threshold. Another would be to sample the current value and say that value is the "normal" value and anything well above it would be the "wet" value.

Either approach would require some input device, like a button, to enable the timer and possibly to sample the data.

First, I need to know what the possible values are. I couldn't find any documentation, so I simply went to the Gadgeteer codeplex site and looked at the source code. As I suspected, the sensor is an extremely simple wrapper around the analog input class. It returns a value in the range of 0 to 1600, as evidenced by this code:

/// <summary>

/// Gets the current moisture reading.

/// </summary>

/// <returns>An integer value, where 0 is fully dry and 1000 (or greater) is completely wet. </returns>

public int GetMoistureReading()

{

    return (int) (analogInput.ReadProportion() * 1600.0);

}

It also has a nice comment which isn't surfaced in the compiled version I have, so I assume that's a somewhat later rev. (Actually, I just looked in the Object Browser and there it is. I wonder why intellisense wasn't showing it? Odd.) In any case, it's useful to know you can always go and inspect the source if you have any question about how something is working at the Gadgeteer module driver level.

So what can we do with that information? Well, let's look at the potentiometer approach.

Potentiometer approach

One thing most MCUs don't have is a large number of analog inputs. In order for a MCU to enable analog input, it has to have a digital to analog converter channel available. Most MCUs which have on-board ADC support either 10 bit or 12 bit analog conversion. The specs for the EMX module used by the Gadgeteer show that it has 7 10 bit analog inputs total. The FEZ Spider surfaces six of them, but only on two sockets. So, unless you have a multi-input devices that can use the 3 pins on a type A socket (or you create a breakout of some sort), you really end up being able to take input from only two analog modules. That leaves us with our diaper sensor and a potentiometer.

For this, I added a potentiometer module to the other analog socket: socket 10. The pot is going to be used to configure the minimum level at which we'll set off the diaper alarm. In addition, I added a button module that we'll use to arm the device.

The new code refactors a few things. Explanation after the listing.

using System;

using System.Threading;

using Microsoft.SPOT;

using Microsoft.SPOT.Presentation;

using Microsoft.SPOT.Presentation.Controls;

using Microsoft.SPOT.Presentation.Media;

using Microsoft.SPOT.Touch;



using Gadgeteer.Networking;

using GT = Gadgeteer;

using GTM = Gadgeteer.Modules;

using Gadgeteer.Modules.Seeed;

using Gadgeteer.Modules.GHIElectronics;



namespace DiaperMonitor

{

    public partial class Program

    {

        private GT.Timer _pollingTimer;



        private const int MoistureLevelRangeLow = 50;

        private const int MoistureLevelRangeHigh = 800;

        private int _minimumBadMoistureLevel = 200;

   

        void ProgramStarted()

        {

            Debug.Print("Program Started");



            button.ButtonPressed += button_ButtonPressed;

        }



        void button_ButtonPressed(Button sender, Button.ButtonState state)

        {

            Debug.Print("Button Pressed");



            if (_armed)

            {

                Disarm();



                // animate counter-clockwise and turn off

                lED7R.Animate(10, false, true, false);

            }

            else

            {

                Arm();

                lED7R.Animate(10, true, false, false);

            }

        }



        private void SetTriggerLevel()

        {

            // read from the pot

            double pot = potentiometer.ReadPotentiometerPercentage();



            // calculate the moisture level based on the bounds

            _minimumBadMoistureLevel = MoistureLevelRangeLow +

                (int)(pot * (MoistureLevelRangeHigh - MoistureLevelRangeLow));



            Debug.Print("Minimum trigger level: " + _minimumBadMoistureLevel);

        }



        bool _armed = false;

        private void Arm()

        {

            SetTriggerLevel();



            // start the timer

            _pollingTimer = new GT.Timer(1000);

            _pollingTimer.Tick += OnPollingTimerTick;



            _pollingTimer.Start();



            _armed = true;



            Debug.Print("Armed.");

        }



        private void Disarm()

        {

            // stop the timer

            _pollingTimer.Stop();

            _pollingTimer.Tick -= OnPollingTimerTick;



            _armed = false;



            Debug.Print("Disarmed.");

        }





        // event handler for the timer that polls the moisture sensor

        void OnPollingTimerTick(GT.Timer timer)

        {

            int moisture = moistureSensor.GetMoistureReading();



            Debug.Print(moisture.ToString());



            if (moisture > _minimumBadMoistureLevel)

            {

                AlertParents();



                Disarm();

            }

        }



        // do all the obnoxious alert stuff in here

        private void AlertParents()

        {

            Debug.Print("Diaper Alert!");



            // animate clockwise and leave on

            lED7R.Animate(10, true, true, true);

        }

    }

}

The new workflow is this:

Set the potentiometer to some minimum trigger level. There's no readout or anything at the moment, so you'd just have to eyeball it.
Once the pot is set, click the button to arm the diaper alert. The LEDs will cycle and you know it's armed.
Wet the diaper (not you, personally, I hope)
Diaper alert and then the system disarms.

When disarming the alarm, to avoid leaks, I remove the event handler. When arming, I wire it back up. In our particular example, this doesn't buy you anything, but if you were to pull this code out into another class, it almost certainly would save you from eating up all the memory on the device over time.

This new workflow is pretty good, but the diaper alert leaves something to be desired. You'd have to get in there to notice the LEDs (in a dark room they'd be ok), but there's nothing to really grab your attention. Clearly we can't have a piercing piezo siren or something, as that would wake up baby before the wet does.

What other options do we have?

Well, how about an alert that is sent to a remote device?

That's the topic of the next post :)

Summary

Ok, that was fun :)

For most of us, this is probably not how we'll use the Gadgeteer. Kids generally have pretty good built-in wet diaper alarms as it is. However, you can use this sensor for just about anything from plant moisture detection to water leak detection to more. More importantly, this post shows how to use an analog sensor of any type, including how to configure the range and some other useful NETMF tips.

The Last Catfish in the East Village?

Charles Petzold — 2012-01-30T19:40:41

People who live in New York City often inhabit tiny apartments, and the only reason we tolerate them is that we've exchanged private spaces for public spaces. We can frequently be found not in our apartments but walking around outside, or in a store, or a theater, or a concert hall, or a museum.

... more ...

Multisampling

Juan María Laó Ramos — 2012-01-24T12:40:51

Aquí tenéis la sexta entrega de la serie sobre aliasing. En esta entrega veremos qué es el Multisampling Multisampling es la solución para aquellos que quieren usar supersampling, pero no se lo pueden permitir. La idea es sencilla: en lugar de aumentar la resolución de todo el renderizado, ¿qué pasaría si dejamos la renderización de [...]

Jetzt Backbone.js lernen: Die Serie

Norbert Eder [MVP] — 2012-01-28T14:36:24

Nach der erfolgreichen Serie über Knockout.js und dem durchwegs positiven Feedback, möchte ich - wie bereits angekündigt - eine neue Serie starten. Diese beschäftigt sich mit Backbone.js. In dieser Vorabinformation möchte ich kurz darauf eingehen, was der Leser erwarten darf. Und das ist eine ganze Menge, da diese Serie einen gänzlich anderen Weg einschlagen wird.

Praxisbeispiel

Im Rahmen der Knockout.js-Serie wurden unterschiedliche Beispiele behandelt. Diese wurden möglichst nahe an der Realität gehalten, aber es mussten auch Teile konstruiert werden. Dies soll in dieser Serie anders sein.

Im Rahmen der Backbone.js-Serie wird ein bereits bestehendes Projekt neu implementiert. Konkret geht es um meine Website http://wpf-blogger.com. Diese aggregiert Feeds von Bloggern zu WPF, Silverlight und Windows Phone in mehreren Sprachen. Damit soll einschlägigen Entwicklern eine zentrale Anlaufstelle für aktuelle Tipps, Tricks und Techniken auf Basis der genannten Technologien geboten werden.

Diese Entscheidung hat mehrere Hintergründe: So besteht die aktuelle WPF-Blogger bereits unverändert seit mehreren Jahren und bedarf zahlreicher Neuerungen. Da mir eine Weiterentwicklung auf der aktuellen Basis wenig zielführend erscheint, habe ich mich dazu entschieden, auf aktuelle Technologien und Techniken zu setzen, auch wenn manches davon als Hype angesehen werden kann.

Was kann der Leser nun erwarten?

Da ein konkretes Projekt zur Umsetzung gelangt, wird die Backbone.js-Serie einen hohen Grad an Praxiswissen und - im Rahmen der Umsetzung gemachten - Erfahrungen aufweisen. Ideal, um sich ein Bild über diese Bibliothek zu machen und einen etwaigen eigenen Einsatz besser abschätzen zu können.

Ein weiterer Mehrwert besteht sicherlich darin, dass ich - als der Autor dieser Serie - Backbone.js gerade erst lerne. Daher sind zahlreiche Hinweise auf Fallen und Tücken zu erwarten, in die ich getreten bin - oder noch treten werde.

Großes Augenmerk werde ich auch auf die Themen Konzept und Testing legen.

Eingesetzte Technologien und Bibliotheken

Das Projekt soll aus aktueller Sicht folgende (Quasi-)Standards, Technologien und Bibliotheken umfassen:

HTML5
CSS3
jQuery
Backbone.js
.NET

Sollte sich die Notwendigkeit ergeben, weitere Bibliotheken zu verwenden, wird diese Liste entsprechend erweitert.

Hinweis: Die obige Liste setzt auf weit mehr als nur Backbone.js. Auch diese werden in dieser Serie teilweise besprochen/diskutiert. Das Hauptaugenmerk wird jedoch auf Backbone.js gelenkt.

Sourcecode / Sharing

Jeder soll sich den aktuellen Sourcecode ansehen, aber auch für eigene Projekte verwenden können. In der Knockout.js-Serie habe ich hierfür teilweise JSFiddle verwendet, ist aber in diesem Rahmen nicht sehr zielführend. Aus diesem Grund habe ich mich entschieden, das gesamte Projekt auf github zu hosten.

Inhalt

Die einzelnen Teile dieser Serie sind nicht im Vorab festgelegt, sondern ergeben sich aus der laufenden Entwicklung des Projektes. Die untenstehende Liste ist daher als flexibel anzusehen und wird ständig erweitert bzw. auf dem aktuellen Stand gehalten.

Jetzt Backbone.js lernen: Die Serie (dieser Beitrag)
Jetzt Backbone.js lernen: Konzept WPF-Blogger
Jetzt Backbone.js lernen: Überlegungen zum Thema Suchmaschinen
Jetzt Backbone.js lernen: Grundlagen Backbone.js
Weitere Teile: TBD

Auf neue Teile wird zusätzlich über Twitter hingewiesen.

Feedback

JavaScript, HTML5 und CSS3 waren bis dato nicht mein Hauptscope. Daher ist es sehr wahrscheinlich, dass jede Menge meines Codes einfacher, schöner und besser geschrieben werden kann. Damit die Leser, die, so wie ich, ebenfalls keine Gurus auf diesem Gebiet sind, sich weiterentwickeln, hoffe ich auf zahlreiches Feedback. Darum bitte ich schon jetzt die Gurus unter meinen Lesern, mit ihrer Meinung nicht hinter den Berg zu halten.

BAOC Countdown and WPAppItUp Wrap-Up

Windows Phone Dev Blog — 2012-01-27T20:01:43

Big App on Campus: Two Weeks Left!

Back in November, we announced a developer promotion for US students called “Big App on Campus.” There are exactly 18 days left to enter. Though we think it’s a no brainer, some of you have asked “Why should I enter?” Let’s recap:

1. For the experience of a lifetime -> 10 finalists, along with one of their friends, will win a trip to SxSW in March. If selected as a finalist, you and your friend will get to come hang out with The Gracious Few (featuring members of the bands LIVE and Candlebox) and attend a rocking concert.

2. $30k in prize money -> the top paid app and the top free app will each win $15,000!

3. Serious bragging rights -> finalist apps will be featured on our Facebook page and the developers behind these creations will have some crazy stories to tell about their time in Austin at SxSW.

<aside reason=”toAppeaseTheLawyers”>No Purchase Necessary. Open only to US university students 18+ who are legal residents of the U.S. and D.C. Submissions due 02/14/2012 and game ends 03/13/2012. For Official Rules, click here</aside>

All Windows Phone applications published since August 1, 2011 are eligible for entry. However all apps must be published to the Marketplace by February 14^th. Make your Valentine proud and enter your app today – I’m sure she/he won’t mind helping you spend the $15k in winnings up for grabs. Check out our Facebook page for all details and information on how to get started on building your first, or next, Windows Phone app.

#WPAppItUp Wrap-Up

Starting back in October, we challenged students to create Sketchflow prototypes of their app ideas for Windows Phone. I’m happy to announce the full list of winners:

Congratulations to all the winners!

Ben

@benlower | phoneninja@microsoft.com | +1 (206) 659-NINJA (6465)

Playing A Sound, Simplified

Jesse Liberty [MS] — 2012-01-27T17:49:25

Jetzt Knockout.js lernen: Mapping

Norbert Eder [MVP] — 2012-01-27T12:30:00

Im letzten Teil meiner Serie zu Knockout.js beschäftigen wir uns mit dem Mapping Plugin. In einigen der letzten Beispiele wurde mit JSON gearbeitet und so Daten simuliert, die vom Server stammen. Damit diese an eine View gebunden wurde, musste das ViewModel (welches Observables enthält) manuell aufgefüllt werden. Das Mapping Plugin bietet hier eine Unterstützung, die in diesem Anwendungsfall sehr viel Aufwand spart. Dieser Artikel zeigt wie es funktioniert.

Voraussetzungen

Damit das Mapping-Plugin verwendet werden kann, muss es via github bezogen werden. Hier der Direktlink zur aktuellsten Version. Das Script ist dann natürlich entsprechend einzubinden.

Grundlagen / Wiederholung

In den letzten Teilen dieser Serie wurden alle ViewModels manuell erstellt und sahen - mehr oder weniger - so aus:

     var MyViewModel = function() {

        this.title = ko.observable();    

        this.author = ko.observable();

        this.pages = ko.observable();

    }

Die Daten wurden dann so gesetzt:

    myViewModel.title('Ein Buch');

    myViewModel.author('Ein Autor');

    myViewModel.pages(500);

So musste das für jede Variable vorgenommen werden. Ein recht großer Aufwand, vor allem, wenn die Struktur komplexer wird.

Knockout.mapping kann diesen Aufwand für uns stark minimieren.

Beispiel

Nun aber zu einem Beispiel an Hand dessen wir uns ansehen, wie knockout.mapping funktioniert. Dazu benötigen wir eine View, die mit einer Schaltfläche ausgestattet ist. Bei einem Klick darauf werden JSON-Daten vom Server geladen und an die View gebunden. Hier vorerst die View:

    <div id="control">

        <input type="button" data-bind="click: loadData" value="Load data"></input>

    </div>

    <div id="data">

        <h2>Loaded Data</h2>

        <p>

            <span data-bind="text: userName"></span><br/>

            <span data-bind="text: tweetCount"></span>

        </p>

    </div>

Soweit noch nichts Neues, aber wenden wir uns der JavaScript-Seite zu.

    $(function(){

    var OverallViewModel = function() {

        this.loadData = function() {

            $.getJSON('http://dl.dropbox.com/u/30654117/Demos/JavaScript/Knockout.js/Mapping/data/data.json', function(data) {

                var viewModel = ko.mapping.fromJS(data);

                ko.applyBindings(viewModel, document.getElementById('data'));

            });

        };

    }

    var firstViewModel = new OverallViewModel();

    ko.applyBindings(firstViewModel, document.getElementById('control'));

    });

Hier wird ein ViewModel namens OverallViewModel definiert und an das DIV mit der Id control gebunden. Darin enthalten ist die Funktion loadData, welche bei einem Klick auf die Schaltfläche ausgelöst wird.

Darin wird im ersten Schritt das JSON vom Server bezogen. Im Anschluss wird ko.mapping.fromJS mit den Daten als Parameter aufgerufen. Das Ergebnis ist ein ViewModel, welches die entsprechenden Eigenschaften, welche im JSON definiert sind (als Observables) besitzt.

Der Vollständigkeit halber hier das JSON:

    {

        "userName": "Norbert Eder",

        "tweetCount": 10000

    }

Das resultierende ViewModel wird nun via ko.applyBindings an das DIV mit der Id data gebunden und die Daten kommen sofort zur Anzeige. Das einfache Beispiel ist fertig. Aber das Plugin kann noch mehr.

Ins Mapping eingreifen

Meine erste Frage - und das wird vermutlich jedem so gehen, war:

So ein einfaches ViewModel ist ganz nett, aber was, wenn ich Funktionen, berechnete Eigenschaften etc. benötige?

Aber auch hierfür gibt es eine entsprechende Lösung.

Erweitern wir obiges Beispiel ein wenig. Zu den rudimentären Tweet-Informationen sollen nun einzelne Tweets hinzugefügt und angezeigt werden. Jeder Eintrag soll mit einer Schaltfläche bestückt werden, mit deren Hilfe ein Retweet durchgeführt werden kann. Auch das sollte nun recht einfach gehen, haben wir uns doch bereits mit Templates beschäftigt. Die Herausforderung ist jedoch, die Tweets mit einem eigenen ViewModel zu versehen, welches eine entsprechende Funktion retweet anbietet, um eben diese Aktion ausführen zu können.

Zuerst aber ein Blick auf die Daten, zwecks Übersicht der durchgeführten Änderungen:

    {

        "userName": "Norbert Eder",

        "tweetCount": 10000,

        "tweets": [

            {

                "content": "Ein Testtweet der mit Sicherheit 140 Zeichen nicht überschreitet."

            },

            {

                "content": "Knockout.js ist schon eine sehr feine Sache!"

            },

            {

                "content": "Bin schon gespannt auf Backbone.js. Soll auch nett sein."

            }

        ]

    }

Nun muss die View umgebaut und mit einem Template versehen werden, auch noch nicht spektakulär:

    <div id="control2">

        <input type="button" data-bind="click: loadData" value="Load data"></input>

    </div>

    <div id="data2">

        <h2>Loaded Data</h2>

        <p>

            <span data-bind="text: userName"></span><br/>

            <span data-bind="text: tweetCount"></span>

        </p>

        <div data-bind="template: { name: 'tweet-template', foreach: tweets }"></div>

    </div>    

    <script type="text/html" id="tweet-template">

        <p data-bind="text: content"/>

        <input type="button" value="Retweet" data-bind="click: retweet"/></input>

    </script>

Interessant ist das ViewModel, oder besser gesagt, sind die beiden ViewModels, da für die Anzeige eines einzelnen Tweets ein weiteres ViewModel (nennen wir es TweetViewModel) definiert werden muss. Immerhin möchten wir eine Funktion unterbringen. Darin sehen wir nun auch bereits den ersten Trick:

    var TweetViewModel = function(data) {

        ko.mapping.fromJS(data, {}, this);

        this.retweet = function() {

            alert("retweeted");

        };

    }

Die Funktion retweet ist einfach und zeigt hier lediglich einen Alert an. Zumindest kann so die Funktionalität getestet werden. Interessanter ist, dass das ViewModel Daten als Parameter übergeben bekommt und diese via ko.mapping.fromJS auf sich selbst appliziert. Damit werden für die in den Daten enthaltenen Eigenschaften korrespondierende Observables am ViewModel erzeugt. Erster Teil erledigt.

Nun muss noch ein Weg gefunden werden, eine Instanz von TweetViewModel pro Item zu erzeugen. Dazu muss das Haupt-ViewModel ein wenig adaptiert werden.

Hinweis: Dieses wurde mit einem anderen Namen als im einfachen Beispiel zu sehen, da es im gleichen Beispiel zu finden ist, Download siehe weiter unten.

Sehen wir es uns an:

    var AnotherViewModel = function() {

        this.loadData = function() {

            $.getJSON('http://dl.dropbox.com/u/30654117/Demos/JavaScript/Knockout.js/Mapping/data/data2.json', function(data) {

                var viewModel = ko.mapping.fromJS(data, mapping);

                ko.applyBindings(viewModel, document.getElementById('data2'));

            });

        };    

    }

Abgesehen davon, dass die Daten nun von einer anderen Quelle bezogen werden, sticht diese Änderung ins Auge:

var viewModel = ko.mapping.fromJS(data, mapping);

Es wird ein neuer Parameter übergeben. Eine Konfiguration für das Mapping.

    var mapping =  {

        'tweets':  {

            create: function(options) {

                return new TweetViewModel(options.data);

            }

        }

    }

Darin wird ein create-Callback definiert, der sich auf das Array tweets bezieht (siehe Daten weiter oben) und für alle Einträge aus dem tweets-Array (siehe Daten) aufgerufen. Als Parameter werden options übergeben. Diese enthalten:

data: Ein JavaScript-Objekt mit den Daten
parent: Das Eltern-Objekt oder das Array zu dem die Daten gehören

Schlussendlich definiert die Zeile

return new TweetViewModel(options.data);

dass eine neue Instanz von TweetViewModel instanziiert werden soll. Die Daten werden als Parameter übergeben und innerhalb des ViewModel weiterverarbeitet (siehe weiter oben).

Das wunderschön gestaltete Ergebnis:

Fazit

Diese beiden Beispiele zeigen sehr schön, dass man sich mit Hilfe des Mapping Plugins jede Menge Schreibarbeit - und damit durchaus auch Fehler - sparen kann. Durch das mögliche Eingreifen in die Erstellung der ViewModels sind alle notwendigen Szenarien vorstellbar und keine Grenzen gesetzt.

Download / Showcase

Getestet werden können die beschriebenen Beispiele hier. Gleich untenstehend der Download des gesamten Paketes:

Feedback

Gerne nehme ich jegliches Feedback zu diesem Beitrag, als auch zur gesamten Serie zu Knockout.js entgegen. Hat dir die Serie geholfen? Hast du Anmerkungen, Anregungen? Fehlt ein Teil, sprich, wurde ein wichtiges Thema nicht besprochen? Teile es mir doch einfach mit und verfasse gleich einen Kommentar.

Jetzt Knockout.js lernen: Die Serie

The n00b filter: Bad UX at its Finest in Eagle PCB

Pete Brown — 2012-01-27T03:55:54

Speaking of UX…

I finally decided to download and learn to use the industry-standard PCB and schematic layout software: Eagle. I've tried a bunch of others, and quite frankly, got tired of always using "also ran" software. The majority of the info on the web is for Eagle. It certainly doesn't have the best UI or the best workflow, but it has absolutely the most amount of information and the best support from PCB manufacturers. It's the industry standard, and like most industry-leading technical software (ever use industry-leading 3d modeling software? Gak!), it has some crazy issues.

Here's the workflow. First, while working on the Schematic, you click this "Add" toolbar button

Next, you're shown a screen with the libraries on the left, and the selected part on the right. You can browse the libraries here, but it is not something I went into with the intent of using it to manage library entries.

I wanted to add the component, but I wasn't sure which button to press. Silly me, thought maybe "drop" meant to "drop it on the schematic" because, for whatever reason, "OK" didn't seem right.

Wrong.

"Drop", without so much as a confirmation MessageBox removes the library from the parts libraries on your computer. Yeah, so now I need to go find the library which contains every type of diode, because, umm, I deleted it.

At first, I thought I actually deleted it, but it turns out Eagle marks it to make it not show up in the Add dialog. I'm still going to finish this post anyway, because the brick was already passed painfully through the orifice when the library just went *poof* off the list.

To restore it, you have to go into their separate Control Panel application (hint: if your app has a "control panel" app, there's an issue). That's better than having to reinstall the product, or download the library from RapidItsNotReallyATrojanWeSwearShare.com, but it's not entirely intuitive.

This type of feature can only be called a n00b filter, although I'm sure there's a more technical UX antipattern name for it, probably one which includes a four-letter word or two.

I have a lot of experience in software. I rarely need to be hand-held, and the last time I took a class to learn how to use a piece of software was to be a Novell 4 CNA in the mid 90s, and I took that class *after* I had already set up the network. I almost never read manuals, and use "Help" in apps maybe 5 times a year total, and only because I'm trying new stuff all the time. All I'm trying to say here, is I'm not afraid of software, and I very rarely do something which destroys work or accidentally does a format c:\ or anything.

Seriously. No confirmation. It's a button on the "Add Component" screen.

No wonder users hate us.

MVC / Razor Style-Switcher – Quicky

Mario Priebe — 2012-01-26T13:25:17

Heute möchte ich zeigen, wie man sich einen einfachen Style-Switcher mittels jQuery in einem MVC / Razor Projekt einbauen kann. Den Basis-Style setzen wir zu Beginn, wenn die Seite zum ersten Mal geöffnet wird. Wichtig ist, das wir eine Id setzen, um in unserer jQuery Funktion dieses Element wieder zu finden. <link id="jQ" href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/themes/base/jquery-ui.css")" rel="Stylesheet" [...]

Maker Geek Roundup 006 for 1/25/2012

Pete Brown — 2012-01-25T20:08:25

The Maker Geek Roundup aggregates information of interest to makers everywhere. Topics include .NET Micro Framework, 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.

Jetzt Knockout.js lernen: Formularvalidierung mit Undo

Norbert Eder [MVP] — 2012-01-25T11:30:00

In Jetzt Knockout.js lernen: Observables erweitern der Serie zu Knockout.js wurde gezeigt, wie Observables erweitert werden können. Als Beispiel diente eine Validierung auf Basis von einzelnen Observables. Nun hängen diese in der Regel aber in einem Formular zusammen, wodurch eine Gesamtvalidierung und eine damit verbundene Freischaltung von Schaltflächen bzw. weiteren Interaktionsmöglichkeiten einhergeht. Dieser Beitrag greift das Validierungsbeispiel auf und erweitert es im Rahmen dieser Anforderung.

Ausgangspunkt

Den Ausgangspunkt dieses Beitrags bietet dieses Beispiel, zu dem Florian einen sinnvollen Erweiterungswunsch hinterlassen hat:

Interessant wäre noch ein Save-Button, der nur aktiv ist, wenn es keine Fehler auf dem gesamten Formular mehr gibt, sowie ein Cancel- bzw. Undo-Button der bei eventuellen Fehlern, die Werte zurücksetzt auf den ursprünglichen Wert.

Aus meiner Sicht handelt es sich hierbei um eine gängige Anforderung, die ich natürlich aufgegriffen habe. Wer den Hintergrund des Beispiels erfahren möchte, kann dies hier vollständig nachlesen. Als Zusammenfassung: Das Beispiel zeigt, wie ein eigener Extender für Observables unter Knockout.js geschrieben werden kann, um einzelne Observables zu validieren. Als Validierung wurde eine Erweiterung hinsichtlich Pflichtfelder implementiert. Eine Gesamtvalidierung war nicht vorgesehen.

Gesamtvalidierung

Aktuell wird jedes Observable einzeln validiert. Entsprechend der Anforderung sollen nun zwei Schaltflächen für das Speichern, als auch das Zurückstellen auf die zuletzt gültigen Werte (im Fehlerfalle) hinzugekommen. Damit diese auch entsprechend freigeschalten sind, muss das ViewModel bekannt geben, in welchem Status es sich gesamt befindet. Dieser ergibt sich aus den Status jedes einzelnen Observables. Dies können wir uns berechnen lassen (ko.computed) und nennen wir hasErrors.

     self.hasErrors = ko.computed(function() 

    { 

       return self.title.hasError() || 

              self.author.hasError() || 

              self.pages.hasError(); 

    });

Hinweis: self ist eine Referenz auf this und wurde im Vergleich zum originalen Beispiel hinzugefügt, um innerhalb der anonymen Funktion auf die Eigenschaften und Funktionen des ViewModels zugreifen zu können.

Damit könnten nun auch bereits die beiden neuen Schaltflächen gesteuert werden:

    <input type="button" value="Save" data-bind="disable: hasErrors"></input>

    <input type="button" value="Undo" data-bind="enable: hasErrors"></input>

Auf die Speichern-Schaltfläche möchte ich an dieser Stelle nicht weiter eingehen, viel spannender ist hier der Undo-Button. Dieser soll ja - im Fehlerfalle - die zuletzt gültigen Werte hinterlegen. Dies bedeutet, dass diese erfasst werden müssen.

Nun ist es so, dass die einzelnen Eingabefelder eine value-Bindung besitzen und das Durchschreiben der Werte via valueUpdate auf den Wert afterkeydown gesetzt wurde. Das ViewModel wird also in Echtzeit aktualisiert. Darauf können wir also nicht aufbauen, da der Benutzer beispielsweise per Backspace alle Zeichen von “Beispiel” löschen könnte, durch die Echtzeit-Aktualisierung würde der zuletzt valide Wert durch “B” repräsentiert. Worauf wir uns jedoch hängen können ist das Verlassen des Fokus, also dem OnBlur-Ereignis.

Dazu brauchen wir eine Funktion, die uns den beim Verlassen vorhandenen - gültigen - Wert übernimmt:

    self.updateLastValidValue = function(observable) {

      if (!observable.hasError()) {

          observable.lastValidValue(observable());

      }

    };

Als Parameter wird das an das Eingabefeld gebundene Observable übergeben. So kann auch auf die durch den Extender geschriebenen Eigenschaften (siehe hasError) zugegriffen werden. Läuft die Validierung ohne Fehler, dann ist ein entsprechender Wert vorhanden und kann übernommen werden. Hierzu wird eine neue Eigenschaft namens lastValidValue mit dem Wert gesetzt.

Damit dies nun bei allen Eingabefeldern berücksichtigt wird, ist deren Bindung zu aktualisieren, hier an Hand der Titel-Eingabe:

    <input data-bind='value: title, valueUpdate: "afterkeydown", event: { blur: function() { updateLastValidValue(title); }}' />

So werden die Werte nun weiterhin in Echtzeit übernommen und zusätzlich beim Verlassen des Feldes die Funktion updateLastValidValue des ViewModels aufgerufen. Das ist allerdings noch nicht alles, denn ein etwaiger initial gesetzter Wert würde nicht berücksichtig werden. An dieser Stelle bietet es sich an, den bereits existierenden Extender (requireField) zu erweitern:

    ko.extenders.requiredField = function(target, message) {   

        target.hasError = ko.observable();

        target.validationMessage = ko.observable();

        target.lastValidValue = ko.observable();

        function validate(newValue) {

           target.hasError(newValue ? false : true);

           target.validationMessage(newValue ? "" : message || "* required");

        }

        function setInitialValueIfValid() {

            if (!target.hasError()) {

                target.lastValidValue(target());

            }  

        }

        validate(target());

        setInitialValueIfValid();

        target.subscribe(validate);

        return target;

    };

Neu ist die Funktion setInitialValueIfValid(). Diese wird beim Erstellen von requiredField durchlaufen (siehe den Aufruf direkt nach der initialen Validierung) und, wenn ein Wert vorhanden ist, lastValidValue mit dem entsprechenden Wert beschrieben.

Zu guter Letzt fehlt noch das tatsächliche Zurückschreiben der Werte, wenn die Undo-Schaltfläche geklickt wird. Dazu benötigen wir eine Funktion, nennen wir sie resetToValidValues:

    self.resetToValidValues = function() {

      self.title(self.title.lastValidValue());

      self.author(self.author.lastValidValue());

      self.pages(self.pages.lastValidValue());

    };

Außerdem muss die click-Bindung auf der Schaltfläche gesetzt werden:

    <input type="button" value="Undo" data-bind="enable: hasErrors, click: resetToValidValues"></input>

Fertig ist die Gesamtvalidierung des Formulars, inklusive der Möglichkeit, die zuletzt gültigen Werte zurück zu schreiben.

Ergebnis

An dieser Stelle nun zwei Screenshots, die die Implementierung visuell veranschaulichen. Der erste Screenshot zeigt das gesamte Formular ohne Validierungsfehler:

Und hier nun im Fehlerfalle:

Download / Showcase

Wie immer gibt es auch dieses Beispiel vollständig für eigene Tests. Unter http://jsfiddle.net/VgvuK/ findet sich die entsprechende Spielwiese. Wer möchte, kann sich dies auch unterhalb ansehen, sollte hierbei allerdings auf die Nutzung eines IE verzichten:

Fazit

Die notwendigen Erweiterungen der “Feld-Validierung” konnte in meinen Augen mit sehr wenig Aufwand auf eine Gesamtvalidierung erweitert werden, wodurch für den Benutzer sehr schnell ersichtlich ist, welche Aktionen zur Verfügung stellen. Ein äußerst sauberer Weg, durch die mögliche Auftrennung.

Feedback

Gerne nehme ich - wie immer - konstruktive Kritik, Anregungen und Anmerkungen entgegen. Einfach einen kurzen Kommentar hinterlassen, es findet sich sicherlich die eine oder andere Verbesserungsmöglichkeit.

Jetzt Knockout.js lernen: Die Serie

Now, more than ever, you need a designer

Pete Brown — 2012-01-25T07:52:53

Before joining Microsoft, I was a consultant, primarily building desktop applications using a variety of MS technologies. During my last couple years there, Silverlight was a large part of that both for full apps and as parts of larger web sites. Prior to that, it was WPF, Windows Forms, VB, HTML and even SharePoint.

tl;dr: The point of this long post is not to show you examples of good design or pick apart existing designs. I'm not really qualified to do that. However, I can point out the need for design and give you some small amount of ammunition when presenting this to your own management. Visual and UX Design matters, even for internal apps, often far more than architecture or the other things we focus on. You'll be more efficient with a designer on-team, who you can iterate with. The world is evolving and we need to keep up. Go hire one now.

tl;dr the tl;dr: Hire a UX/Interaction designer.

The company I worked at wouldn't hire a UX/Visual designer. Why? Because they felt they could never sell the benefit of good UX and visual design to customers, and couldn't keep a designer busy 100% of the time. The problem was, without a portfolio of well-designed UI and sites, it became self-fulfilling. I had contended that if they hired one, they'd be amazed at just how busy that person would end up being. Quite frankly, they just didn't see the value.

It got to the point that when I walked into my management's office, they'd be like "You're not going to tell us to hire a designer again, are you?"

You may even be thinking the same thing, this post may see like Déjà vu if you've followed my blog for a few years :) I took a more conservative approach to the problem in that 2010 post. Basically saying the same types of things Scott Hanselman recently pointed out in his Skip Intro post: don't over do it, and don't use things just because they're there. In that post, I argued that if you want to just keep making the same old battleship gray applications, you don't *need* a designer. However, I still think you can benefit from one in your projects regardless. So, I'm going to backtrack a little bit and deliver a more absolute form of the message: yes, you need a designer. Whether it is HTML/JS/CSS, or XAML/C#/VB, or something else, you should have design talent on staff.

For a bit, we toyed around with the idea of partnering with an outside firm. The problem was, there was too much of a "hand off" approach to the design. Without having the design talent on-staff, you couldn't iterate during the project. The design was passed in at the beginning and then slowly destroyed by the developers (or people like me who had good UX but horrible Graphics design skills) over time.

I likened it to other disciplines, like partnering with a firm just to design the database. Sure, design it all up-front and then make the project live with that throughout the rest of the lifecycle. No one found that to be a sane idea, but still couldn't see the parallel with UX and Graphics design.

Now, in their defense, the company primarily worked on large-scale transaction processing systems. However, the business had slowly evolved to include more commercial work, and more intranet and internet sites for these same customers. Also, in their defense, our customers felt the same way. They wanted really great UX and graphics, but somehow felt those things simply fell from the sky. They didn't want to pay for designers on projects either. They were still stuck in the team makeup and ideas that worked for mainframe applications and, as in most cases, haven't moved on.

One thing the enterprise development community in general has been slower to adopt is the idea that you really do need visual and UX design talent on staff. Application success or failure rarely comes from architecture, or reuse, or whether or not you use stored procedures or which ORM you use. Those are things we do to meet other, more internal, goals, most of which users don't care about in the least, many of which offer more perceived benefit than actual real project benefit. As Scott mentioned in another post, users don't care if you use Web Sockets. Sure, if you really botch the architecture, the app may be unusable, but beyond that, your investment is better spent elsewhere.

Knowing Your Limits

Yesterday, Scott Hanselman blogged about the emerging trend to throw a dog's breakfast of features into HTML5/CSS3/JS sites. He and I chatted about it for a little, and felt I should write something up here as well. Go read his post as well.

It's natural for developers to push the boundaries when a new technology comes out. That's how we learn. That's fine for demo sites in developer echo chambers and compos, but don't do it in front of actual users. It's too easy to have your app look and perform like a Pirate's idea of wealth: all money and no style. Scott has links to a few examples of that in his post. There are a couple other good ones in the comments.

How did we get to this point? Why do so many still not even realize we're here?

Modern Development

First, a little history:

I don't wear a suit to work. In fact, I work from home, so what I wear barely counts as clothing some days. I also don't sit in front of a highly non-ergonomic greenscreen device, trying to remember arcane codes (ok, well I do when I'm messing around with microcontrollers or old computers). Why? Because the world has moved on from that. Gradually over the years, more and more UX thought has been given to applications.

When applications were just command-line affairs, the only UX you really had to worry about was how hard the transaction codes were to remember. Most of the UX was the huge three-ring binder manual or the multiple volume boxed sets with textured cloth covers. Users often spent as much time in that as interacting with the screen, especially during their first X months. Graphics were Escher prints you hung on the wall. Computers were supposed to be hard, for some unknown reason. Engineering ruled the experience, and we didn't know any better.
When they became full-screen character mode applications (Curses, anyone? No? How about the windowing libraries for DOS TurboC/C++ apps? IBM 3270? No? Pah. Youngsters.) there was more UX to worry about, but the layout and workflow choices were still so limited as to make it easier for a dev with a good eye to come up with something decent. Graphics were things scientists used for data visualization. Design was for companies making physical products customers had to hold in their hands. An entire industry was built around plastic-coated cardboard keyboard templates to help you remember all the keyboard shortcuts required to navigate important applications, especially for DOS. I blame WordPerfect.
When apps became battleship gray forms over data (white 2d forms first), UX consisted mainly of making sure you had a decent tab order and "fit as much as possible" on a single screen. Navigation often resembled those character mode applications we were upgrading/scraping/rewriting because our users didn't know any better, and we didn't know how to show them something else and prove it would be more efficient and/or easier. Things started to go south here. Graphics were for games and maybe 16x16 16 color icons. Animation was for music videos.
- Early on, apps were even just black and white instead of gray. But when the gray "3d" chiseled look started coming into vogue late in Win 3.11's lifetime (there was a special common controls library just for it), developers went nuts and had apps that looked like Mayan pyramids. Borders within borders within borders. Uuuuugly. And I did it too. It was new. It was exciting, and it was abused.
When the web started making inroads into application development, UX became further complicated. First, the workflow options for early web apps really blew. Many apps had two buttons "Submit" and "Reset" and a big form above them. Validation and all other processing mostly took place server-side. Sometimes, we got clever, and sent all the data through an iframe to avoid a full page refresh. We made excuses because that's how all the other apps were working, and we didn't take much inspiration from branded experiences. However, at least they often looked nicer than those battleship gray apps. That made a real impression on people. Hmm. Graphics. Colors. Whitespace. Animation was for dancing hamsters or Pixar.
And then the proliferation of consumer-oriented smart phones and tablets with great UX, driven in no small part by Apple, really brought UX and visual design to the front. It's not because the platform had a great API or something (I've never worked on it, but I hear the platform, from a programming and design standpoint is … interesting), but because it attracted a lot of designer types. It's no accident that companies like Apple and Microsoft chose design firms to create the first showcase prototypes of their new UI technologies. Now, even inside the enterprise, many customers expect this level of UX in their own applications. Graphics, colors, whitespace, touch, animation, easing and more all become important parts of the visual design, and it's very easy to get it wrong unless you have a talent for design.
- Your users now and in the future are ones brought up on this crop of highly visual applications. What do you think they will have for expectations?

But now we're stuck, because we have the tools to do whatever we want, but haven't evolved the teams to effectively make use if them.

We've had tools and platforms to build these types of apps for some time. Flash has been around forever, Silverlight since 2007, and finally, HTML5/CSS3 and its support in browsers is mostly catching up to where FutureSplash was in 1996. The capabilities are there, we just need to use them for good.

It's not just for consumer-oriented apps, either. As companies consolidate their development staff, expose more things outside the firewall, or work to support a large number of internal users, the line between consumer and enterprise development continues to thin.

For grins, here are some apps I wrote in the 90s and early 2000-ish, where I happened to have saved some screen shots (I really wished I had saved more, especially the dBase/FoxPro apps I wrote for DOS and the VB3-6 and PowerBuilder ones for Windows 3.11). The first one was written for DOS entirely in Borland C++ (including the database) the others were, as I recall, .NET 1.0 beta versions of VB4 apps I wrote earlier. in the first one, I mainly just had to worry about tab order. In the second, the users were most comfortable with filling out an online version of the paper form (in fact, they'd have the paper form in front of them while doing this). The third was using the typical "Make it look like Outlook" model of the time.

That version actually looked quite a bit better on a giant 15" CRT, perched high enough up to count as neck-stretching exercise. :)

Like so many other developers, I simply copied prevalent design trends of the time (how many devs have you talked to back in the day who said they were trying to make their app look like Outlook or Visual Studio/Visual Basic?). I got away with it, but you can see that it doesn't 100% work. I force fit some things due to the limited palette of visual design patterns at my disposal. Bonus points: battleship gray.

Is it Customer-Facing?

I've heard many people say that they'll only invest in UX for customer-facing stuff. But who is the customer?

It depends on how you define your customer. For many IT shops, the customer works for the same company. For sales apps, many times the field laptop/tablet application is seen by both a sales person and the customer. Many of the same things you'd do in a consumer application apply to these same customers, but because they're forced to use your app, they don't get the same attention to UX that external true consumer apps do.

Here's a list of some common types of applications being built today, or in the near future. Tell me where UX doesn't matter? Which is customer-facing?

Call center apps inside an organization
The departmental day-to-day work application at your company
Consumer touch-oriented apps on phones and tablets
Consumer apps on the desktop
Enterprise shrink-wrapped products for the desktop
Your intranet site
That forms-over-data application everyone in the company uses
Time and expense reporting systems
Your one-off shell script to update a bunch of database tables

Ok, so I through the shell script in there just to have something where you could get away without UX. Of course, there's often some design put in there too. Did you take a moment to set up different command line arguments? UX, just no pretty graphics :)

How many times have you heard "Sorry, the computer is really slow today" when you talk to someone at a call center? Typically this is because it takes forever to accomplish anything on their crappy apps. Sometimes, of course, they have a 9600bps serial connection from wherever they are to wherever the data is, but most of the time it's just a crap UI that takes forever to help you, or they've forgotten how to do a certain thing in the UI because it's so non-intuitive. I've seen these apps up close. I've seen the massive amount of training that people have to go through to learn them. Some of the most horrendous UX I've ever seen was in an in-house call center application to take outage reports at a power company - one of their most critical ways to help customers. Are they not worth better UX?

UX is important for all those applications. The more the application gets used, the more good or bad UX comes into play. It's not just about selling the application and getting 5 stars, it's also about making others more efficient and making their lives a little less hellish. Making them feel good while using it is a nice bonus.

Most developers, let's not kid ourselves, are simply not well-equipped to make good UX decisions. They're too embedded in the software, and too aware of the underlying code and architecture changes that a change in UX would require so they push back, or don't even consider the things that really should be done. Or they build the system back-to-front and the UI, by necessity, resembles the data structures they used throughout the app. Oh, and changing the UX of an application is one of those things that becomes becomes far more expensive as you wait. UX is the entire workflow of the application. It touches just about everything.

What about graphics? In companies, "Designer" often encompasses both UX and Visual/Graphics design. Often, good UX designers also have a decent visual design background as well, just as developers often have more than one related skill.

Just go Find Some Free Icons

That's something I heard over and over, and you probably hear it too. "Go find some clipart" or "go find a free icon set". Ugh. Invariably, the icon set would only have 1/3 of the required icons, and the remaining ones would have to magically appear. I was able to do that (Axialis Icon Designer saw a lot of me back then), not anywhere near as well as the original designer, but well enough. There were many other applications I saw which had different icons from various sets, with incompatible styles, all mashed together on the same toolbar.

The same thing applies to site themes, css, and more. "Just go find a template" is almost as bad as "go find some free icons".

There are more choices today, but you still end up with those toolbars (or pages, or whatever) where half the icons look good, and the other half show some bad image with a three letter acronym over it.

They all have splash screens though, and with clip art. Maybe even from MS Word. :)

In some cases, the UI starts to resemble that PTA fund raising newsletter sent home with your kid, or that office baby shower announcement :)

When I did work on the graphics and visual design of applications a decade or more ago, I had to do it while hiding in the corner. I had a customer PM come over and tell me "don't let anyone see you drawing pictures". Clearly the visual design and icons and other elements "just appeared" from nowhere. The effort was not respected, but the outcome was expected.

The problem here is not that developers don't know their limits (most do), but that management doesn't see the UX/Graphics Designer role as useful. It's not seen as a science, it's art. And just like in public schools, it's art that gets cut first.

An introduction to Interaction Design should be a required subject for all Computer Science and MIS majors. Not because I would expect them to learn to be great at it, but because they need good solid exposure to it so they know something's possible, even if they don't have the required skills/talent. They'll see there's more science to it than they thought. In fact, Psychology backgrounds often help in UX design. It helps that most Psychology majors are otherwise unemployed :)

Like I said to Scott "The more freedom and power you have, the more you need someone to tell you what not to do." You need this person on your team.

Who is On Your Team?

If you are on a team larger than two people, I bet you have a project manager, a dedicated DBA/database designer (or someone who doubles as DBA and database designer while also coding queries and services and whatnot), a front-end programmer, a back-end programmer, and maybe even a tester. Maybe you have an analyst or two, although those seem to be getting scarce. Larger teams tend to have more finely grained roles.

These are all seen as specialized skills. Not everyone is great at designing databases. Not everyone is equally skilled at creating good services and APIs. Not everyone can line up fields on a form. With web apps, the division tends to be even stronger due to the different languages and platforms in use in the different tiers or sections of the application. Inside the development community we, and our managers, understand these limitations and try to work within them.

But most importantly, not everyone can take a problem and visualize an appropriate workflow and user experience, low-cost prototype it, test it with the users, and make the changes required to make the best UX the project budget will support. It's a specialized skill like any other.

And like any other part of a software project, you don't want to just do it at the end. No lipstick on a pig. Get a designer involved form the beginning, and include them in your iteration plan. You'll be amazed at what you can accomplish.

How have your battles gone on this front? Have you been able to convince management about the importance of UX/Interaction/Visual design? If so, how did you go about it? What worked? What didn't?

Google API jQuery UI 1.7.2 Theme Übersicht + Razor-Layout

Mario Priebe — 2012-01-24T15:02:13

Im folgenden eine kleine Übersicht von Google API jQuery UI 1.7.2 Designs, so vorbereitet, dass diese schnell im Header eines Razor Layouts eingefügt werden können. base <link href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/base/jquery-ui.css")" rel="Stylesheet" type="text/css" /> blitzer <link href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/blitzer/jquery-ui.css")" rel="Stylesheet" type="text/css" /> dark-hive <link href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/dark-hive/jquery-ui.css")" rel="Stylesheet" type="text/css" /> eggplant <link href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/eggplant/jquery-ui.css")" rel="Stylesheet" type="text/css" /> flick <link href="@Url.Content("http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/flick/jquery-ui.css")" rel="Stylesheet" type="text/css" /> [...]

Jetzt Knockout.js lernen: Observables erweitern

Norbert Eder [MVP] — 2012-01-24T10:00:00

Im vergangenen Teil der Serie zu Knockout.js wurden benutzerdefinierte Bindungen behandelt. Dieser Teil beschäftigt sich nun damit, wie Observables auf eigene Bedürfnisse hin erweitert werden können. Knockout.js unterstützt das Lesen und Schreiben von Werten, als auch Benachrichtigungen bei Wertänderungen. In zahlreichen Fällen (zum Beispiel Validierung) möchte man dieses Verhalten jedoch erweitern. Dieser Beitrag zeigt, wie dies umgesetzt werden kann.

Extender zur Validierung erstellen

Knockout.js bietet mit Extendern eine Erweiterungsmöglichkeit an, sich an Observables zu hängen. Das nachfolgende Beispiel erweitert Observables durch die Möglichkeit einer Validierung.

Im ersten Schritt erstellen wir ein einfaches ViewModel, welches an eine View gebunden wird. Hier das ViewModel:

     function BookViewModel(title, author, pages) {

        this.title = ko.observable(title).extend({ requiredField: "Please enter a title" });

        this.author = ko.observable(author).extend({ requiredField: "Please enter an author" });

        this.pages = ko.observable(pages).extend({ requiredField: "" });

    }

    var viewModel = new BookViewModel("Windows Presentation Foundation 4.5 - Einführung und Praxis", "Norbert Eder", 400);

    ko.applyBindings(viewModel);

Und passend dazu die View:

    <div id="bookform">

        <h3>Title</h3>

        <p>

            <input data-bind='value: title' />

        </p>

        <h3>Author</h3>

        <p>

            <input data-bind='value: author' />

        </p>

        <h3>Pages</h3>

        <p>

            <input data-bind='value: pages' />

        </p>

    </div>

Soweit nichts Neues. Nun möchten wir aber, dass eingegebene Werte validiert werden. In diesem Fall beschränke ich mich darauf, Felder als benötigt zu definieren. Ein Extender wird daher benötigt. Um einen Extender zu schreiben muss ko.extenders um eine Funktion erweitert werden, nennen wir sie requiredField. Diese enthält als Parameter das Ziel der Erweiterung und eine Nachricht (die für die Anzeige einer Meldung verwendet werden kann).

    ko.extenders.requiredField = function(target, message) {   

        target.hasError = ko.observable();

        target.validationMessage = ko.observable();

        function validate(newValue) {

           target.hasError(newValue ? false : true);

           target.validationMessage(newValue ? "" : message || "* required");

        }

        validate(target());

        target.subscribe(validate);

        return target;

    };

Der Extender hängt dem Ziel zwei Eigenschaften hasError und validationMessage um. Die erste beschreibt, ob ein Validierungsfehler vorliegt, die zweite, welcher Fehler dies genau ist. Zusätzlich wird eine Funktion validate benötigt, welche die Validierung schlussendlich durchführt. Dies ist in diesem Beispiel recht einfach. So muss lediglich auf Vorhandensein eines Wertes geprüft werden. Ist dies nicht der Fall wird die über den Parameter message übergegebene Meldung angezeigt - wurde keine eigene Meldung übergeben, wird ein Fallback auf eine Standardmeldung verwendet.

Via validate(target()); wird eine initiale Validierung durchgeführt. Per target.subscribe(validate); wird ein Abonnement hinsichtlich Wertänderungen hinzugefügt, damit auch in diesen Fällen die Validierung durchgeführt wird.

Anschließend wird das ursprüngliche Observable zurück geliefert. Das war alles, was auf JavaScript-Seite zu implementieren war. Nun ist noch die View anzupassen, um etwaige Meldungen sichtbar zu machen.

    <div id="bookform">

        <h3>Title</h3>

        <p data-bind="css: { error: title.hasError }">

            <input data-bind='value: title, valueUpdate: "afterkeydown"' />

            <span data-bind='visible: title.hasError, text: title.validationMessage'> </span>

        </p>

        <h3>Author</h3>

        <p data-bind="css: { error: author.hasError }">

            <input data-bind='value: author, valueUpdate: "afterkeydown"' />

            <span data-bind='visible: author.hasError, text: author.validationMessage'> </span>

        </p>

        <h3>Pages</h3>

        <p data-bind="css: { error: pages.hasError }">

            <input data-bind='value: pages, valueUpdate: "afterkeydown"' />

            <span data-bind='visible: pages.hasError, text: pages.validationMessage'> </span>

        </p>

    </div>

Für die Erweiterung der View wurden insgesamt drei Schritte unternommen:

Für die input-Felder wird die Aktualisierung des Wertes im ViewModel durch valueUpdate auf afterkeydown geändert, damit jede Änderung sofort im ViewModel wirksam wird und so schon zur Eingabe eine Validierung stattfinden kann.
Es wird ein span-Element eingeführt. Dieses enthält eine visible-Bindung auf die Eigenschaft hasError - ist also nur sichtbar, wenn ein Validierungsfehler aufgetreten ist. Der anzuzeigende Wert des span-Elementes wird auf die validationMessage gebunden.
Die umschließenden p-Tags wurden um eine css-Bindung erweitert. Dadurch wird bei Vorhandensein eines Validierungsfehlers eine CSS-Klasse error auf das Element gehängt, wodurch ein Styling einfach gemacht wird. So sieht es aus:

Download / Showcase

Das Beispiel kann unter http://jsfiddle.net/zHFEU/ getestet und bezogen werden. Untenstehend findet sich das JSFiddle in eingebundener Form, benötigt aber einen Browser ungleich IE.

Fazit

Dieses Beispiel hat gezeigt, wie einfach es möglich ist, ein Verhalten á la Validierung per Knockout.js und Extender zu realisieren. Auch hier gilt wieder, dass die Zuständigkeiten sauber getrennt sind und einfach gewartet werden.

Jetzt Knockout.js lernen: Die Serie

Arduino The Documentary

Pete Brown — 2012-01-24T05:48:51

For anyone interested in open source microcontroller development, or why boards are named with *duino type names, this 1/2 hour documentary is a great watch.

http://vimeo.com/18539129

Arduino.TheDocumentary.2010.English explains the origin of the Arduino in a relatively non-technical interview-based documentary style, with interviews for people involved in the creation, as well as key partners and users.

Spanish version is also available.

Yet Another Podcast #57–Kendo UI

Jesse Liberty [MS] — 2012-01-23T19:49:57

Jetzt Knockout.js lernen: Benutzerdefinierte Bindungen

Norbert Eder [MVP] — 2012-01-23T06:50:32

In den vorangegangenen drei Teilen der Serie über Knockout.js haben wir uns mit einer generellen Einführung, einer beispielhaften Bindung an Formulare und Listen als auch der Verwendung von Vorlagen beschäftigt. Dieser Teil beschäftigt sich nun mit der Möglichkeit der benutzerdefinierten Bindungen. So wird gezeigt, wann diese sinnvoll verwendet werden und wie sie denn überhaupt funktionieren.

Bindungen im Allgemeinen

Vordefinierte Bindungen stehen für die unterschiedlichsten Bereiche zur Verfügung. Abgedeckt werden Bindungen um Text und Darstellung zu kontrollieren (z.B. visible, text, html, css usw.), um mit Formular-Feldern zu arbeiten (submit, checked, value, etc.) und zur Ablaufsteuerung (foreach, if, ifnot, with).

Eine vollständige Übersicht findet sich in den Slides des ersten Teils.

Trotz der mannigfaltigen Möglichkeiten, besteht der Bedarf an eigenen Bindungen, gerade dann, wenn Werteänderungen spezielle Auswirkungen auf DOM Elemente haben sollen. Äußerst hilfreich sind benutzerdefinierte Bindungen auch dann, wenn Steuerelemente von Drittanbietern zum Einsatz kommen und so spezielle oder zusätzliche Attribute/Verhalten bedient werden sollen.

Grundlagen

Eine benutzerdefinierte Bindung wird durch folgenden Code erstellt, wobei myBindingName mit dem tatsächlichen Namen der Bindung zu ersetzen ist:

     ko.bindingHandlers.myBindingName = {

        init: function(element, valueAccessor, allBindingsAccessor, viewModel) {

        },

        update: function(element, valueAccessor, allBindingsAccessor, viewModel) {

        }

    };

Von Bedeutung sind die beiden Funktionen init und update:

init: Wird nur beim ersten Auswerten der Bindung aufgerufen. Ideal für die Initialisierung, beispielsweise dem Setzen von Eventhandlern.
update: Hier kann darauf reagiert werden, wenn sich gebundene Werte verändern. Der Aufruf erfolgt, wenn die Bindung das erste Mal angewandt wird und bei jeder Änderung des gebundenen Wertes. Sollte verwendet werden, um DOM Elemente auf Basis des geänderten Wertes zu manipulieren/aktualisieren.

Beide Funktionen sind mit insgesamt vier Parametern ausgestattet:

element: Das DOM Element der Bindung. Dadurch ist es nicht notwendig, dem Element eine Id oder Ähnliches zuzuweisen.
valueAccessor: Dahinter verbirgt sich eine Funktion, die Zugriff zum gebundenen Wert gibt. Die Funktion liefert ein Observable zurück, nicht den tatsächlichen Wert. Wird ein Ausdruck für die Bindung verwendet, dann wird dieser zurück geliefert.
allBindingsAccessor: Eine Funktion, die alle Bindungen auf dieses DOM Element zurück liefert.
viewModel: Das ViewModel-Objekt, das via ko.applyBindings gebunden wurde. Bei einer verschachtelten Bindung wird das gebundene Datenelement zurückgeliefert.

Doch sehen wir uns ein einfaches Beispiel an.

Beispiel

Sehen wir uns die benutzerdefinierte Bindung anhand eines kleinen Beispiels an. Es soll ein Eingabeformular geben. Hier können sowohl der Vor- als auch der Nachname erfasst werden. Die Daten werden darüber als Zusammenfassung angezeigt. Wird ein Wert in der Eingabe verändert, soll die Wertänderung in der Zusammenfassung mit Hilfe eines Fade-In-Effekts angezeigt werden.

Dazu ist ein einfaches ViewModel notwendig, welches an das User Interface gebunden wird:

    var viewModel = {

        firstName: ko.observable("Norbert"),

        lastName: ko.observable("Eder")

    };

    ko.applyBindings(viewModel);

Die View selbst sieht dann so aus:

    <div class="overview">

        <h2>First name</h2>

        <span data-bind="text: firstName"></span>

        <h2>Last name</h2>

        <span data-bind="text: lastName"></span>

    </div>

    <div class="data">

        <h2>First name</h2>

        <input data-bind="value: firstName" /><br/>

        <h2>Last name</h2>

        <input data-bind="value: lastName" /><br/>

    </div>

Soweit noch nichts aufregendes. Bei einer Werteveränderung, wird dies sofort in der Zusammenfassung nachgezogen. Nun soll aber noch der Einblendeffekt hinzukommen. Dazu erstellen wir eine benutzerdefinierte Bindung, die auf eine Wertänderung reagiert (update-Funktion).

    ko.bindingHandlers.fade= {

        update: function(element, valueAccessor) {

            $(element).hide().fadeIn(1000);

        }  

    };

Da lediglich auf die Wertänderung, ohne Berücksichtigung des tatsächlichen Wertes, reagiert werden muss, ist die update-Funktion ausreichend. Auch muss auf den Wert selbst nicht zugegriffen werden. Stattdessen wird lediglich das Element versteckt und via fadeIn eingeblendet.

Hinweis: Müsste auf den Wert reagiert werden, kann dieser via ko.utils.unwrapObservable(valueAccessor()) bezogen werden.

Damit dies auch tatsächlich funktioniert, muss die benutzerdefinierte Bindung noch in der View gesetzt werden:

    <div class="overview">

        <h2>First name</h2>

        <span data-bind="text: firstName, fade: firstName"></span>

        <h2>Last name</h2>

        <span data-bind="text: lastName, fade: lastName"></span>

    </div>

    <div class="data">

        <h2>First name</h2>

        <input data-bind="value: firstName" /><br/>

        <h2>Last name</h2>

        <input data-bind="value: lastName" /><br/>

    </div>

Fertig ist eine einfache Verwendung.

Download / Showcase

Das Bespiel kann unter http://jsfiddle.net/SvAHr/ getestet und bezogen werden. Oder aber auch untenstehend (IE streikt hier leider):

Fazit

Auch wenn das gezeigte Beispiel ein sehr einfaches ist, können benutzerdefinierte Bindungen sehr gut eingesetzt werden, um komplexe Verhalten zu steuern. Der Vorteil liegt darin, dass so wiederverwendbare Bindungen erstellt werden können. Im einfachsten Fall können darüber Standardverhalten/-einstellungen gesetzt werden, die jedoch nur an einer einzelnen Stelle zu implementieren/verwalten sind.

Jetzt Knockout.js lernen: Die Serie

My First Real PIX-6T4 Game: Sixty4Racer

Pete Brown — 2012-01-22T14:34:30

After assembling my Netduino-powered PIX-6T4, I wanted to go and write a simple game. This post describes the construction of that game, including all source code.

Concept

When you have 64 monochrome red pixels, you need to keep the graphics simple. I decided on a game inspired by the classic Atari River Raid game. This is essentially a vertical scrolling game where you need to dodge obstacles with your boat. Variations included things like Spy Hunter on the C64 and many many others. Most of those games also involved shooting and enemies, but that's a but more complex than you can reasonably do on this board. I won't enable moving walls like Laser Gates, but I'll leave things open enough not to make it impossible to do that in the future.

The game had to be small enough that I could figure out the API, and then design, code, and blog about it in a single evening after my kids went to bed The PIX-6T4 is fun, but I have way too many projects on my backlog to be able to devote any significant time to it (here's a taste: a ShapeOko CNC mill, an AVR MIDI->CV Converter, the final touches on the MIDI Thru Box, several MFOS Synth Modules, Several Gadgeteer Board Concepts, a Win8 XAML book, chapters to review in my Silverlight 5 book, and much much more). In fact, that was one of the big selling points of this device: simple gameplay and quick to develop for. Combined with the great library Fabien designed, and my past experience with Netduino and, more specifically, C#, and this should be an evening project.

GamePlay

A simple dodge'em racing game. Levels get progressively longer and faster until you crash. And you will crash. And burn. And die.

The joystick lets you control moving your single pixel vehicle either left or right. You can't move in any other direction.

Progression

Most good games increase in difficulty as you progress through the game. I decided that for this one, both the number of screens in the level and the overall speed would both increase as you progress through the game.

Goals

The goal is simple: not die. The longer you last, the more levels you'll make it through, and the more you'll be able to brag to your friends.

Screen Design

Back in the 80s, in 7th grade, I used to design single-color sprites for the commodore 64. The sprites themselves were 3 bytes wide, with each pixel represented as a single bit in the byte. I used to define them on graph paper, but alas, the notebooks I filled with sprites and BASIC listings have long since disappeared.

I used to create my own fonts (programmable characters) as well. Those were done in a similar way, but on 8x8 graphs, eight bytes total for each character. Some pretty amazing games were created just with character graphics (the amazing Below the Root on the C64, as I recall, was one of them. You can see it played here.). That model is what we have to work with on the PIX-6T4, but showing the equivalent of one character at a time.

Here's an image from the Commodore 64 Programmer's Reference Manual

You can see there how the letter A is formed by the bit patterns for the eight bytes. I'm going to use a similar approach for the level design here. I'll create the "blocks" that make up the play area and then chain them together to create a playable game field.

Here here are the initial screens I created, using notepad. The only criteria I had was to make sure the middle two spots were open at the start and end of each screen. Zeroes are safe areas, ones are walls/shore/hard-deadly-smashy-things.

The more variation in screens you add, the more challenging and interesting the game can be. So, I'll be sure to leave the design open enough to allow for other screens to be easily added.

I don't need to limit myself to 8 bytes high, but I did anyway, as that will let you do things like use 8x8 pixel font editors to design the screens. In fact, here are the same levels (with a couple slight modifications), plus a bunch more, done using the pixel font editor. I got a little carried away :)

The first entry is the start screen, the second is the end screen. All the ones after that are random ones which can be shown at any point during play. There are several "break" screens in there. That is, screens that aren't particularly difficult. And then there are a number of hair-pullers, and ones with dead-ends too :) Black is wall, white is passable space.

Thanks to Fabien for pointing out this tool in the source code. It's so much easier to visualize the design when using the font editor, plus you get to export the bytes automatically. Speaking of export, here's what the tool generated for me:



// Font: ScreensSource.pf



unsigned char font[2048] =

{

    0xC7, 0xC3, 0x83, 0x83, 0x81, 0x00, 0x00, 0x00,    // Char 000 (.)

    0x00, 0x00, 0x81, 0x81, 0xC3, 0xC3, 0xE7, 0xE7,    // Char 001 (.)

    0xE3, 0xCF, 0x87, 0xCF, 0x81, 0xF3, 0xC3, 0x87,    // Char 002 (.)

    0x87, 0xC1, 0xF1, 0xF9, 0xE1, 0x87, 0xC3, 0x81,    // Char 003 (.)

    0x81, 0xE7, 0x81, 0x99, 0x99, 0x81, 0xE7, 0xC3,    // Char 004 (.)

    0xE7, 0xE7, 0xF1, 0xC1, 0xCF, 0xE3, 0xF7, 0xE7,    // Char 005 (.)

    0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7,    // Char 006 (.)

    0xE3, 0xF9, 0xFC, 0xFE, 0xFC, 0xF9, 0xF3, 0xE7,    // Char 007 (.)

    0xE7, 0xE7, 0xEF, 0xE7, 0xF7, 0xE7, 0xEF, 0xE7,    // Char 008 (.)

    0xC3, 0xFB, 0xE1, 0xEF, 0xC1, 0xFB, 0x83, 0xE7,    // Char 009 (.)

    0xE7, 0xC1, 0x81, 0xF9, 0xC0, 0x81, 0x9F, 0x87,    // Char 010 (.)

    0xE7, 0xC3, 0x00, 0x7E, 0x00, 0xE7, 0xE7, 0x81,    // Char 011 (.)

    0xE7, 0x81, 0x18, 0x7E, 0x3C, 0x99, 0xC3, 0xE7,    // Char 012 (.)

    0x00, 0x18, 0x3C, 0x3C, 0x3C, 0x3C, 0x18, 0x00,    // Char 013 (.)

    0xC3, 0x89, 0x24, 0xB5, 0xA5, 0x2C, 0x81, 0xC3,    // Char 014 (.)

    0x86, 0x3C, 0x5A, 0x66, 0x3C, 0x28, 0x82, 0xC6,    // Char 015 (.)

    0x81, 0x00, 0x66, 0x66, 0x00, 0x99, 0x81, 0xA5,    // Char 016 (.)

    0xE7, 0xC3, 0xDF, 0x83, 0xF7, 0xA1, 0x8D, 0xE7,    // Char 017 (.)

    0xC3, 0x81, 0x00, 0x18, 0x18, 0x00, 0x81, 0xC3,    // Char 018 (.)

    0xE7, 0xC3, 0x99, 0x38, 0x1C, 0x99, 0xC3, 0xE7,    // Char 019 (.)

    0x04, 0x49, 0x02, 0x10, 0x4A, 0x00, 0x44, 0x20,    // Char 020 (.)

    0xA7, 0x2D, 0x6A, 0x2D, 0x26, 0x55, 0x56, 0x27,    // Char 021 (.)

    0xE7, 0xF7, 0xE7, 0xF7, 0xC3, 0xDB, 0xC3, 0xE7,    // Char 022 (.)

    0xE3, 0xCB, 0x9B, 0x3B, 0x89, 0x3D, 0x9D, 0xC5,    // Char 023 (.)

    0xE7, 0xC3, 0x99, 0xBD, 0x99, 0xC3, 0xE7, 0xE7,    // Char 024 (.)

    0xC3, 0xCF, 0xC3, 0xF3, 0xC7, 0xE3, 0xCF, 0xC7,    // Char 025 (.)

    0x65, 0xB6, 0x55, 0xB6, 0x65, 0xAA, 0x6D, 0xA7,    // Char 026 (.)

    0xE7, 0xC3, 0xE3, 0xF1, 0xF8, 0xF3, 0xC7, 0xE7,    // Char 027 (.)

    0xE4, 0xF4, 0xF4, 0xF4, 0xE4, 0x69, 0x0B, 0xA7,    // Char 028 (.)

    0x00, 0x18, 0x66, 0x5A, 0x5A, 0x66, 0x18, 0x00,    // Char 029 (.)

    0xA5, 0x91, 0x93, 0x97, 0x93, 0xCB, 0xE3, 0xE7,    // Char 030 (.)

    0x00, 0xDB, 0xC3, 0xE7, 0xE7, 0xC3, 0x99, 0x00,    // Char 031 (.)

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,    // Char 032 ( )

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,    // Char 033 (!)

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,    // Char 034 (")

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,    // Char 035 (#)

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,    // Char 036 ($)

    ...

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00     // Char 255 (.)

};

I then just needed to prune it to remove the stuff I wasn't using, and make it work in my app. The font designer certainly took a lot of the work out of it, though. The end-result can be seen in the code listing for the Screens class.

With that in place, it was time to actually start creating the game.

First Iteration: Creating the scrolling playfield

I called my project PeteBrown.Sixty4Racer. Just as in the previous post, I copied over the Program.cs file from another project and used that as the start. Please read my previous post to see what references you need and whatnot.

The first class I created was the one that manages the creation of the screens.

The Screens Class

The Screens class is responsible for storing all the known screens, and then assembling them into a level when requested. It knows how large the screens are, and how large a single level's full set of screens is.

using System;

using Microsoft.SPOT;

using netduino.helpers.Imaging;



namespace PeteBrown.Sixty4Racer

{

    class Screens

    {

        // Font: ScreensSource.pf

        private const int ScreenCount = 32;

        private const int ScreenHeight = 8;

        private readonly byte[] _screenBytes = new byte[ScreenCount * ScreenHeight]

        {

            0xC7, 0xC3, 0x83, 0x83, 0x81, 0x00, 0x00, 0x00,    // Start Screen

            0x00, 0x00, 0x81, 0x81, 0xC3, 0xC3, 0xE7, 0xE7,    // Stop Screen

            0xE3, 0xCF, 0x87, 0xCF, 0x81, 0xF3, 0xC3, 0x87,    // Char 002 (.)

            0x87, 0xC1, 0xF1, 0xF9, 0xE1, 0x87, 0xC3, 0x81,    // Char 003 (.)

            0x81, 0xE7, 0x81, 0x99, 0x99, 0x81, 0xE7, 0xC3,    // Char 004 (.)

            0xE7, 0xE7, 0xF1, 0xC1, 0xCF, 0xE3, 0xF7, 0xE7,    // Char 005 (.)

            0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7,    // Char 006 (.)

            0xE3, 0xF9, 0xFC, 0xFE, 0xFC, 0xF9, 0xF3, 0xE7,    // Char 007 (.)

            0xE7, 0xE7, 0xEF, 0xE7, 0xF7, 0xE7, 0xEF, 0xE7,    // Char 008 (.)

            0xC3, 0xFB, 0xE1, 0xEF, 0xC1, 0xFB, 0x83, 0xE7,    // Char 009 (.)

            0xE7, 0xC1, 0x81, 0xF9, 0xC0, 0x81, 0x9F, 0x87,    // Char 010 (.)

            0xE7, 0xC3, 0x00, 0x7E, 0x00, 0xE7, 0xE7, 0x81,    // Char 011 (.)

            0xE7, 0x81, 0x18, 0x7E, 0x3C, 0x99, 0xC3, 0xE7,    // Char 012 (.)

            0x00, 0x18, 0x3C, 0x3C, 0x3C, 0x3C, 0x18, 0x00,    // Char 013 (.)

            0xC3, 0x89, 0x24, 0xB5, 0xA5, 0x2C, 0x81, 0xC3,    // Char 014 (.)

            0x86, 0x3C, 0x5A, 0x66, 0x3C, 0x28, 0x82, 0xC6,    // Char 015 (.)

            0x81, 0x00, 0x66, 0x66, 0x00, 0x99, 0x81, 0xA5,    // Char 016 (.)

            0xE7, 0xC3, 0xDF, 0x83, 0xF7, 0xA1, 0x8D, 0xE7,    // Char 017 (.)

            0xC3, 0x81, 0x00, 0x18, 0x18, 0x00, 0x81, 0xC3,    // Char 018 (.)

            0xE7, 0xC3, 0x99, 0x38, 0x1C, 0x99, 0xC3, 0xE7,    // Char 019 (.)

            0x04, 0x49, 0x02, 0x10, 0x4A, 0x00, 0x44, 0x20,    // Char 020 (.)

            0xA7, 0x2D, 0x6A, 0x2D, 0x26, 0x55, 0x56, 0x27,    // Char 021 (.)

            0xE7, 0xF7, 0xE7, 0xF7, 0xC3, 0xDB, 0xC3, 0xE7,    // Char 022 (.)

            0xE3, 0xCB, 0x9B, 0x3B, 0x89, 0x3D, 0x9D, 0xC5,    // Char 023 (.)

            0xE7, 0xC3, 0x99, 0xBD, 0x99, 0xC3, 0xE7, 0xE7,    // Char 024 (.)

            0xC3, 0xCF, 0xC3, 0xF3, 0xC7, 0xE3, 0xCF, 0xC7,    // Char 025 (.)

            0x65, 0xB6, 0x55, 0xB6, 0x65, 0xAA, 0x6D, 0xA7,    // Char 026 (.)

            0xE7, 0xC3, 0xE3, 0xF1, 0xF8, 0xF3, 0xC7, 0xE7,    // Char 027 (.)

            0xE4, 0xF4, 0xF4, 0xF4, 0xE4, 0x69, 0x0B, 0xA7,    // Char 028 (.)

            0x00, 0x18, 0x66, 0x5A, 0x5A, 0x66, 0x18, 0x00,    // Char 029 (.)

            0xA5, 0x91, 0x93, 0x97, 0x93, 0xCB, 0xE3, 0xE7,    // Char 030 (.)

            0x00, 0xDB, 0xC3, 0xE7, 0xE7, 0xC3, 0x99, 0x00    // Char 031 (.)

        };



        private RacerGame _parentGame;



        public Screens(RacerGame parentGame)

        {

            _parentGame = parentGame;

        }





        public int GetLevelScreenCount(int level)

        {

            return level * 6 + 2;

        }



        public int GetLevelPixelHeight(int level)

        {

            return GetLevelScreenCount(level) * ScreenHeight;

        }



        public Composition GetLevelComposition(int level)

        {

            int levelScreenCount = GetLevelScreenCount(level);



            byte[] bytes = new byte[ScreenHeight * levelScreenCount];



            int b = 0;

            int startIndex = 0;



            for (int i = 0; i < levelScreenCount; i++)

            {

                if (i == 0)

                {

                    // finish screen. This is the second screen in the array

                    startIndex = ScreenHeight;

                }

                else if (i == levelScreenCount - 1)

                {

                    // start screen. First screen in the array

                    startIndex = 0;

                }

                else

                {

                    // regular random screen

                    int selectedScreen = _parentGame.Random.Next(ScreenCount - 2) + 2;



                    startIndex = ScreenHeight * selectedScreen;

                }



                for (int a = startIndex; a < startIndex + ScreenHeight; a++, b++)

                {

                    bytes[b] = _screenBytes[a];

                }

            }



            return new Composition(bytes, 8, levelScreenCount * ScreenHeight);

        }



    }

}

The class has the primary function GetLevelComposition which builds the background bitmap used to populate all the little red LEDs. The Composition class is one of the netduino helper classes in the PIX-6T4 library.

The next class is the main game class.

The RacerGame class

The RacerGame class is responsible for all the game-specific logic. It handles scrolling the level, displaying messages, and (eventually), moving the player around the screen and handling collision detection. In this first iteration, all it does is display the level number and then scroll the level at the appropriate speed. The first level may seem to scroll painfully slow, but trust me, throw a player pixel in there and you'll change your mind.

using System;

using Microsoft.SPOT;

using netduino.helpers.Fun;

using netduino.helpers.Imaging;

using System.Threading;



namespace PeteBrown.Sixty4Racer

{

    class RacerGame : Game

    {

        private Screens _screens;



        public RacerGame(ConsoleHardwareConfig config)

            : base(config)

        {

            _screens = new Screens(this);



            DisplayDelay = 25;

        }



        protected override void OnGameEnd()

        {

        }





        protected override void OnGameStart()

        {

            base.OnGameStart();

        }



 

        private int _currentLevel = 0;

        private float _currentlevelSpeedIncrement = 0f;

        private float _exactScrollPosition = 0.0f;



        private int CurrentWorldLine

        {

            get { return (int)_exactScrollPosition; }

        }



        private void InitializeLevel()

        {

            World = _screens.GetLevelComposition(_currentLevel);

            _exactScrollPosition = _screens.GetLevelPixelHeight(_currentLevel) - 1;

            _currentlevelSpeedIncrement = 0.02f * (float)_currentLevel; // tweak this to change speed

        }



        private void CompleteLevel()

        {

            // TODO: Play some music



            Thread.Sleep(1500);

            ScrollMessage(" Level Up!");

        }



        private void IntroduceLevel()

        {

            // show the level number

            Hardware.Matrix.Display(SmallChars.ToBitmap(_currentLevel / 10, _currentLevel % 10));

            Thread.Sleep(1000);

        }



        private bool _firstTime = true;

        public override void Loop()

        {

            if (CurrentWorldLine == 0 || _firstTime)

            {

                if (!_firstTime)

                {

                    CompleteLevel();

                }



                // Next Level

                _currentLevel++;

                InitializeLevel();

                IntroduceLevel();



                _firstTime = false;

            }

            else

            {

                _exactScrollPosition -= _currentlevelSpeedIncrement;

            }



            // draw the frame

            Hardware.Matrix.Display(World.GetFrame(0, CurrentWorldLine));

        }

    }

}

The RacerGame class knows a level is complete when the top row of pixels is the first row of pixels in the level. Remember, since we're scrolling the screen down, we're moving from the bottom to the top of the rows of pixels. Get to the top, and the level is done.

Minor But Fatal Bitmap Class Bug

The GetFrame method in the version of the source code I used has an incorrect check. Where it says if (x >= 0 && x + FrameSize < Width) it should say if (x >= 0 && x + FrameSize <= Width). Notice the <= instead of <. The incorrect check means that any bitmaps that are exactly 8 pixels wide, like the one here, simply won't display. This bug may be fixed in the source you get, but you'll want to double-check. I'm just glad I had the source to refer to (and fix!). Isn't OSS great? :)

When the level is complete, you get the scrolling "Level Up!" message. Click the joystick button and you're good to try the next level.

Now is a good time to run the game and see what it looks like. You should see a vertically scrolling playfield, but no player just yet.

Second Iteration: Adding in the player

The PIX-6T4 libraries have built-in the concept of a PlayerMissile. This is a single pixel on the playfield. It may move, so it has X and Y speed. You can show or hide it, so it has Visibility. And most importantly, it has collision detection with other PlayerMissile instances. For our game, we're not going to use that, since we're looking for collision detection with the background. So, a little manual detection is in order.

Bitmap Class Bugs

While coding this game, I found a few more bugs in the Bitmap class. I've alerted Fabien, so you should see an updated set of source code soon. The first bug is that the GetPixel and SetPixel methods do some incorrect bounds checking up front. Y is checked against width rather than height, and the opposite happens with X. We're going to use GetPixel in a moment, so fixing this is important.

Here's the updated RacerGame class

using System;

using Microsoft.SPOT;

using netduino.helpers.Fun;

using netduino.helpers.Imaging;

using System.Threading;



namespace PeteBrown.Sixty4Racer

{

    class RacerGame : Game

    {

        private Screens _screens;

        private PlayerMissile _ship;



        public RacerGame(ConsoleHardwareConfig config)

            : base(config)

        {

            _screens = new Screens(this);



            DisplayDelay = 25;

        }



        protected override void OnGameEnd()

        {

            ScrollMessage(" Game Over");

        }





        protected override void OnGameStart()

        {

            base.OnGameStart();



            _ship = new PlayerMissile()

                {

                    Name = "ship",

                    IsEnemy = false,

                    X = 3,

                    IsVisible = true,

                    VerticalSpeed = 0,

                };



            ScrollMessage(" Sixty4Racer!");

        }



 

        private int _currentLevel = 0;

        private float _currentlevelSpeedIncrement = 0f;

        private const float BaseShipSpeed = 0.25f;           // speed ship moves across the screen

        private float _exactScrollPosition = 0.0f;



        private int CurrentWorldLine

        {

            get { return (int)_exactScrollPosition; }

        }



        private void InitializeLevel()

        {

            World = _screens.GetLevelComposition(_currentLevel);

            World.AddMissile(_ship);



            _exactScrollPosition = _screens.GetLevelPixelHeight(_currentLevel) - 1;

            _currentlevelSpeedIncrement = 0.02f * (float)_currentLevel; // tweak this to change speed



            _ship.Y = CurrentWorldLine + 7; // always be on bottom line

            _ship.X = 3;

        }



        private void CompleteLevel()

        {

            // TODO: Play some music



            Thread.Sleep(1500);

            ScrollMessage(" Level Up!");

        }



        private void IntroduceLevel()

        {

            // show the level number

            Hardware.Matrix.Display(SmallChars.ToBitmap(_currentLevel / 10, _currentLevel % 10));

            Thread.Sleep(1000);

        }



        private bool CheckForCollision()

        {

            return World.Background.GetPixel(_ship.X, _ship.Y);

        }



        private bool _firstTime = true;

        public override void Loop()

        {

            _ship.HorizontalSpeed = (float)Hardware.JoystickLeft.XDirection * BaseShipSpeed;

            _ship.Move();



            if (_ship.X < 0) _ship.X = 0;

            if (_ship.X > 7) _ship.X = 7;



            if (CurrentWorldLine == 0 || _firstTime)

            {

                if (!_firstTime)

                {

                    CompleteLevel();

                }



                // Next Level

                _currentLevel++;

                InitializeLevel();

                IntroduceLevel();



                _firstTime = false;

            }

            else

            {

                _exactScrollPosition -= _currentlevelSpeedIncrement;



                _ship.Y = CurrentWorldLine + 7; // always be on bottom line

            }



            // draw the frame

            Hardware.Matrix.Display(World.GetFrame(0, CurrentWorldLine));



            if (CheckForCollision())

            {

                // game over

                Stop();

            }

        }

    }

}

This version of the source adds in the player pixel

I represent the "This Game is Too Damn Hard" Party

At this point, after adding the player and collision detection, I realized just how hard this game is! If you want to make it easier, I suggest editing the levels to make them a little more open, like a minimum of two pixels wide for any path, and no sudden moves left or right. You may even want to segment the level array into easy/medium/hard, and then change the mix of screens from level to level.

With all that in place, now is another great time to try out the game. It has all the main functionality at this point; anything else is just polish.

Third Iteration: Polishing

The first thing I realized was that it was really hard to make out the player pixel in the sea of red. That's to be expected on a monochrome display at 8x8 resolution. The approach I came up with to make it a bit easier is to simply flicker the player pixel. Each time the game loop executes, I toggle the visibility of the ship PlayerMissile to give it a nice seizure-inducing flicker.

public override void Loop()

{

    _ship.HorizontalSpeed = (float)Hardware.JoystickLeft.XDirection * BaseShipSpeed;

    _ship.Move();



    // make the ship blink so we can see it

    _ship.IsVisible = !_ship.IsVisible;



    if (_ship.X < 0) _ship.X = 0;

    if (_ship.X > 7) _ship.X = 7;



    if (CurrentWorldLine == 0 || _firstTime)

    {

        if (!_firstTime)

        {

            CompleteLevel();

        }



        // Next Level

        _currentLevel++;

        InitializeLevel();

        IntroduceLevel();



        _firstTime = false;

    }

    else

    {

        _exactScrollPosition -= _currentlevelSpeedIncrement;



        _ship.Y = CurrentWorldLine + 7; // always be on bottom line

    }



    // draw the frame

    Hardware.Matrix.Display(World.GetFrame(0, CurrentWorldLine));



    if (CheckForCollision())

    {

        // game over

        Stop();

    }

}

Sound Effects

The next thing this needed was some sound effects. When you move left or right a full pixel, it would be helpful to play a little blip. Maybe that's annoying? Nah! Let's do it.

This is really easy to do. I simply keep track of the last position the ship moved to. If the new position is different from the old one, I call the Beep function to make a noise. The actual implementation here results in an extra blip on startup, but I'm cool with that :)

private void Blip()

{

    Beep(200, 30);

}



private bool _firstTime = true;

private int _oldShipX = 0;

public override void Loop()

{

    _ship.HorizontalSpeed = (float)Hardware.JoystickLeft.XDirection * BaseShipSpeed;

    _ship.Move();



    if (_ship.X != _oldShipX)

    {

        Blip();

        _oldShipX = _ship.X;

    }





    // make the ship blink so we can see it

    _ship.IsVisible = !_ship.IsVisible;



    ...



}

Next, we need to do a little bit of exploding when you hit the wall. And yes, you will hit the wall.

The Explosion Sprite

The final thing was to add a little bit of an explosion when the player hits the wall. I designed the sprite data using the same PixelFont editor.

I then copied just those 8 x 8 bytes of data into the initializer for the sprite class. Here's the Sprite class itself (without the initializer code).

using System;

using Microsoft.SPOT;



namespace PeteBrown.Sixty4Racer

{

    class Sprite

    {

        private readonly byte[] _frames;

        private const int Width = 8;

        private const int Height = 8;

        private int _frameCount;



        public Sprite (byte[] frames)

        {

            _frames = frames;



            _frameCount = _frames.Length / Height;

        }



        public int FrameCount

        {

            get { return _frameCount; }

        }



        public int CurrentFrame

        {

            get { return _currentFrame; }

        }



        public void Reset()

        {

            _currentFrame = 0;

        }



        private int _currentFrame = 0;

        public byte[] GetNextFrame()

        {

            return GetFrame(_currentFrame++);

        }



        public byte[] GetFrame(int index)

        {

            if (index >= FrameCount)

                throw new IndexOutOfRangeException("Index must be less than " + FrameCount);



            byte[] b = new byte[Height];



            for (int i = 0; i < Height; i++)

            {

                b[i] = _frames[index * Height + i];

            }



            return b;

        }

    }

}

(The initialization code will be in the next listing.)

Next, I added in a little music. How about some Sad Trombone when you die? Sounds good to me. By looking at the Pac Man music example, and the source code for the RttlSong class, I was able to figure out how to build a string of notes to play the sad trombone sound asynchronously while the explosion happens. Rub it in!

Sprite _explosion = new Sprite(new byte[]

    {

        0x00, 0x00, 0x00, 0x18, 0x18, 0x00, 0x00, 0x00,

        0x00, 0x00, 0x18, 0x24, 0x24, 0x18, 0x00, 0x00,

        0x08, 0x3C, 0x72, 0x5B, 0xDE, 0x62, 0x3C, 0x08,

        0x3C, 0xD2, 0xAD, 0xFE, 0x5F, 0xF5, 0x56, 0x28,

        0x00, 0x3C, 0x56, 0x7A, 0x6E, 0x72, 0x3C, 0x00,

        0x00, 0x00, 0x18, 0x3C, 0x3C, 0x18, 0x00, 0x00,

        0x00, 0x00, 0x00, 0x18, 0x18, 0x00, 0x00, 0x00,

        0x00, 0x00, 0x00, 0x08, 0x10, 0x00, 0x00, 0x00

    });



protected override void OnGameEnd()

{

    var song = new RttlSong("SadTrombone:d=4,o=4,b=40:32d4,32c#4,32c4,4b3");

    var thread = song.Play(Hardware.Speaker, true);



    for (int i = 0; i < _explosion.FrameCount; i++)

    {

        Hardware.Matrix.Display(_explosion.GetNextFrame());

        Thread.Sleep(200);

    }



    ScrollMessage(" Game Over");

}

You can go further, of course, but I'm going to wrap it up at that.

Final Steps

The final things to do are to create the manifest file and bitmap which will be used on the SD card. I'll need to check with Fabien to see what the exact format of the .bin file is, but I suspect it's just the 8 bytes of data formatted like all the other bitmap data in this application. I'm also not sure if he has a nice little app to write that data out, or convert from a bitmap, or something else. I ended up just using a hex editor to recreate the pattern from one of the images I created in the font editor.

The assembly itself needs to be loaded from the SD card as a .pe file, as Fabien explains in his blog post on dynamically loading assemblies from an SD card. Be sure to comment out the #define dev before your final compile. Make sure you take the .pet file from the LE (little endian) folder, not the BE (big endian) folder. The files look identical other than byte order, but the BE version will not work.

I then created a cartridge.txt manifest file for my game. The contents of that consist of a single line:



assembly:file=PeteBrown.Sixty4Racer.pe;name=PeteBrown.Sixty4Racer;version=1.0.0.0;class=PeteBrown.Sixty4Racer.Program;method=Run

They must be in a folder with the same name as the root file name for the image. So, these go in a PeteBrown.Sixty4Racer folder.

Finally, don't forget to reflash the PIX-6T4 with the main ConsoleBootLoader application from your solution.

After that, pop the SD card into the PIX-6T4 and have a blast!

What You Can Do

This came is completely free and open source. While I'd love credit for the initial work, it's not a requirement. Go ahead and do whatever you'd like with the source and have a blast :)

Here's a video of the game in action.

PIX-6T4 Netduino Mini Game

Assembling the PIX-6T4 Netduino-powered Hand-Held Game System

Pete Brown — 2012-01-21T08:12:51

I recently picked up a PIX-6T4 build by Fabien Royer (with games by Fabien Royer and Bertrand Le Roy). This is a 64 pixel, two joystick/button, monophonic sound hand-held game device based around the Netduino Mini from Secret Labs. You create games in C# using Visual studio.

Disclaimer: I work for Microsoft and I enjoy working in the .NET Micro Framework as well as C++ on other microcontrollers. I purchased this product on my own, at full price; this is not a sample or review unit. Presumably, I got the same package of goodies everyone else gets.

Unboxing

The kit came in a regular USPS shipping box inside which were four bags. Two bags had components, and two had joysticks.

Everything was well-packed in ESD safe bags. The two joysticks were in their original as-delivered bags.

What's inside?

What the Kit Includes

The kit includes just about everything you need to assemble a working PIX-6T4 handheld game console. The PCB, of course, as well as a nice laser-cut acrylic bottom.

It can be powered by a 9v battery or a regular 9v power supply. When using a battery, you solder a barrel jack on the battery lead to make it easy to switch between the two.

The entire thing is open source hardware and software from the Netduino all the way up to the full kit and the software to run it.

What it doesn't Include

A USB to Serial converter. Many people with Netduino minis already have one of these cables. You can get them cheap online, or (worst case) get one at Best Buy or Fry's. I happened to have one just because my C64-TPC (a connection between my Commodore and my PC) needed one. Putting on-board USB would have been nice, but that typically requires a surface-mount FTDI chip which is very difficult for DIY soldering (or a breakout board from a place like SparkFun which adds bulk, cost, and complexity). The Netduino mini, unlike the Netduino, doesn't offer an external USB interface. So, while I'm not a fan of the serial approach, I do think it was the best choice here.

You can play the stock games by just loading them on the SD card. However, if you want to do any programming or debugging of your own, you'll really need the USB converter, as debugging is impossible without it.

Speaking of SD card, that's the other things that you'll need: A FAT32-formatted SD card. You'll need one of these to store the games you write and also to load the stock games.

Assembly

I love the blue board. I've always liked blue, black and red PCBs. The typical green solder mask just looks too much like some crap 486 motherboard. I'm glad they went with something attractive here.

First step is the most unusual bit of soldering. There's one surface mount component, but it's stunningly easy to solder. That's the SD card slot. Make sure you following the video and do not solder the two pins on the right (although if they're not connected to anything, as long as you don't short them, I would think they'd be fine)

Next up, flip the board over and install the IC socket for the LED controller, and then a resistor.

In this particular case, it seems the stencil for the resistor was sized for a 1/8" watt resistor. The space is also cramped, but this resistor sticking up like that just breaks my heart. At least, it's on the bottom side of the board so we can all hide our shame :)

Next, up, the LED array and then the Netduino mini socket.

A power switch and another resistor standing at attention

From there, it's the audio trim pot and the power LED. At this point, I have to mention that the power LED is REALLY bright and in your face when you're trying to play. I covered mine with a little bit of black paint, but even that isn't quite enough. I actually think it would be better to solder that LED upside down, so it is on the underside of the board. That might even be a cool effect with the acrylic down there. Fabien mentioned he might bump up the resistor value, but the more I think about putting it upside down, the more I like it. I might even desolder mine and put a new LED underneath :)

I did a few more steps before taking another photo. Resistors, the power connector (underside), and a transistor are all in place.

In case you haven't gathered, I'm not a big fan of having resistors stand up in general. In fact, I hate them in all but the most cramped design with huge multi-watt resistors. They're easy to knock over, bend, etc, and they're more difficult to solder in that configuration. There's tons of spare room on this board, so I'm not entirely sure why Fabien and folks did that. Just be careful when soldering the other components so you don't break these off.

Ceramic capacitor, electrolytic capacitor, and the 3.3v power regulator in place. If I were designing this board, I think I would have found a way to position the regulator so it lay flat on the board with its leads bent at 90 degree angles. That's a pretty common approach in other builds, like the Sammich SID I built.

Finally, the joysticks, pin headers, and the ICs themselves. Before I installed the ICs, I went and cleaned the bottom of the board with flux remover spray and a cleaning brush. It helps clean things up quite a bit. You'll see later, it also helped me see a bad solder joint. Organic Rosin flux isn't super harmful to leave on, but it's ugly to see on the board.

Don't forget the one IC that goes on the bottom.

Smoke Test

Time for a power-on test! After I cleaned it up, dried if off, and installed the ICs, I powered it up without an SD card. This is what I saw:

Sweet! I got the skull and crossbones, which means it's working. As an aside, you can also see what I was talking about with the super bright LED. It easily overpowers the playing field. Looks cool in a photo, though, a bit like a Star Trek II photon torpedo.

Next, I copied the three game folders (from the zip file referenced on the PIX-6T4 site) on to a 512MB SD card and started it up. I was greeted by the icons of the games I could choose. I picked a game and then…

And…I got nothing.

At first I thought it was this bad solder joint (which makes no sense, but hey, I figured the code was perfect!). It's really hard to see in this picture (and in fact, it looks ok in this picture), but when viewed through a lens you can see that I never heated the pin: the solder goes around the pin but never really joins with it.

I only found this after cleaning the board with flux remover. Flux can fill in holes like that and make it so you can't see them without doing a continuity test. I resoldered that pin (and the one next to it which didn't look much better), and then did a continuity test between the mini and each of the breakout pins, just to make sure there were no others.

Still no go.

After trying out a few SD cards and getting nothing, and following some other suggestions from Fabien, I still had nothing. Finally, Fabien recommended I dig out that usb->serial cable (I wasn't able to find it at first) and compile and re-deploy the current source from Codeplex. Guess what? It worked :)

It turns out I had one of the Netduino Minis that had the old firmware on it, and the games were built with new firmware. The deploy got them synchronized.

Excellent. I have a working PIX-6T4 :)

The Test Games

I tried the games that come with it. One plays the Pac Man song, one is a game of pong, and the other is an asteroid avoidance game. You have only 64 pixels to work with, and they're all the same color, so like the early days of video games, you need to use your imagination.

The stock games are well done. However, since I had the debugger/programmer connected, I wanted to go and build something myself.

My First Game

My first game is going to be a test game. I added a new Netduino application project named "PeteTestGame". I did this in the same solution that contains the PIX6T4 source code and the other three stock games. Next, I added a reference to pix6t4.netduino.helpers project.

In the project, I also removed the reference to SecretLabs.NETMF.Hardware.Netduino and add reference to SecretLabs.NETMF.Hardware.NetduinoMini

Next, add a GameOfTest class. I named it this following the naming conventions Fabien and Bertrand set up, but you can call it anything. GameOfThrones is an obvious choice ;)

The GameOfTest class

using System;

using Microsoft.SPOT;

using netduino.helpers.Fun;



namespace PeteTestGame

{

    class GameOfTest : Game

    {

        public GameOfTest(ConsoleHardwareConfig config)

            : base(config)

        {



        }



        protected override void OnGameEnd()

        {

            base.OnGameEnd();

        }



        protected override void OnGameStart()

        {

            base.OnGameStart();



            ScrollMessage(" Hello World!");

        }



        protected override void OnLeftButtonClick(uint port, uint state, DateTime time)

        {

            base.OnLeftButtonClick(port, state, time);

        }



        protected override void OnRightButtonClick(uint port, uint state, DateTime time)

        {

            base.OnRightButtonClick(port, state, time);

        }



        public override void Loop()

        {

       

        }

    }



}

Program

Next, I copied the Program.cs from one of the other projects. I made three changes to the source:

Uncomment the #define dev at the top
Changed the namespace to match the rest of the project
Changed the class in the Run method to be GameOfTest instead of the one copied from the other project

The program.cs enables you to deploy your test game as the only game on the device, without worrying about building up a manifest and icon and dealing with the SD card and whatnot. Obviously, this also makes debugging possible.

Set the game project as startup. Next, right-click and select project properties and navigate to the .NET Micro Framework tab. Make sure the deployment is set to Serial and you have the COM port that your Netduino mini is attached to.

Once done, you can run the project. In my case, I immediately saw the scrolling (and repeating) Hello World text. The ScrollMessage function is doing all the heavy lifting. It's great that Fabien put in the nifty retro font in there as well.

Next step was to add some beeping. Because, well, it's not a game without beeping.

using System;

using Microsoft.SPOT;

using netduino.helpers.Fun;



namespace PeteTestGame

{

    class GameOfTest : Game

    {

        public GameOfTest(ConsoleHardwareConfig config)

            : base(config)

        {



        }



        protected override void OnGameEnd()

        {

            base.Beep(440, 500);

            base.Beep(220, 500);

            base.Beep(440, 500);

        }





        protected override void OnGameStart()

        {

            base.OnGameStart();



            base.Beep(440, 500);

            base.Beep(220, 500);

            base.Beep(440, 500);



            ScrollMessage(" Hello World!");

        }



        protected override void OnLeftButtonClick(uint port, uint state, DateTime time)

        {

            base.OnLeftButtonClick(port, state, time);



            base.Beep(440, 500);



        }



        protected override void OnRightButtonClick(uint port, uint state, DateTime time)

        {

            base.OnRightButtonClick(port, state, time);



            base.Beep(220, 500);

   

        }



        public override void Loop()

        {

       

        }

    }



}

Now it plays a few beeps on startup and then beeps when you press down on either joystick. Note that that does stop the scrolling text, however.

I'll leave the more complex games to a later date :)

Update 1/22: To see my first real full game, check out my blog post on building Sixty4Racer.

Conclusion

I'm impressed with what Fabien has come up with here, and the stock games he and Bertrand have done are just perfect. I think the board and enclosure could use a little more design to make it more compact and also more hand-friendly, but overall, I think this is an excellent way to get into Netduino programming using something fun and exciting. Also, because of the display technology, you are constrained to creating games with very simple graphics (just LEDs) so, by necessity, you avoid that common barrier to entry. Sometimes constraint is a good thing.

Congratulations Fabien and Bertrand!

WPF 4.5 Cross-Thread Collection Synchronization Redux

Pete Brown — 2012-01-20T22:59:04

In my post about WPF 4.5 Observable Collection Cross-thread Change Notification, I showed the basics of how to synchronize collection updates in WPF, and how to avoid having to manually dispatch calls to the UI thread. In the comments, Jonathan Allen brought up some very good points that I simply didn't know the answers to (and a lock I was missing in the example). Thanks to Jonathan for keeping me honest :)

For background, go back and read that post, but then come here for some of the updates.

So, rather than guess at the answers, I went right to the guy responsible for most (all?) of the design of the binding structure in WPF: Sam Bent. I also went back to the spec document, and also dove deeper into what's actually happening.

Locking

Q: If I'm using collection synchronization, do I need to lock my own access to the collection?

A: Yes, you do. The collection won't do any locking by itself (I had thought that ObservableCollection was doing some, but both Jonathan and Sam corrected me here. Sam also pointed out this works with just about any collection). Having the collection handle any locking internally is "full of pitfalls" (Sam's words, which I agree with having seen the examples) and was abandoned early in .NET's development cycle.

What this does mean, is that my example from the previous post really needed to lock the collection add call. Here's the updated viewmodel source.

class MainViewModel

{

    public ObservableCollection<Stock> Stocks { get; private set; }



    private object _stocksLock = new object();



    public MainViewModel()

    {

        Stocks = new ObservableCollection<Stock>();



        BindingOperations.EnableCollectionSynchronization(Stocks, _stocksLock);

    }





    private Random _random = new Random();

    public void AddNewItems()

    {

        lock (_stocksLock)

        {

            for (int i = 0; i < 100; i++)

            {

                var item = new Stock();

                for (int j = 0; j < _random.Next(2, 4); j++)

                {

                    item.Symbol += char.ConvertFromUtf32(_random.Next(

                        char.ConvertToUtf32("A", 0),

                        char.ConvertToUtf32("Z", 0)));

                }



                item.Value = (decimal)(_random.Next(100, 6000) / 100.0);

                Stocks.Add(item);

                Debug.WriteLine(item.Symbol);

            }

        }

    }





    public void StartAddingItems()

    {

        Task.Factory.StartNew(() =>

        {

            while (true)

            {

                AddNewItems();

                Thread.Sleep(500);

            }

        });



    }

}

Notice how I lock the entire loop in AddNewItems. Depending on what's going on inside that loop, or how many iterations, that may simply be too large/long a lock. If you need a smaller/shorter lock, it would be safe to wrap the Add call instead, like this:

private Random _random = new Random();

public void AddNewItems()

{

    for (int i = 0; i < 100; i++)

    {

        var item = new Stock();

        for (int j = 0; j < _random.Next(2, 4); j++)

        {

            item.Symbol += char.ConvertFromUtf32(_random.Next(

                char.ConvertToUtf32("A", 0),

                char.ConvertToUtf32("Z", 0)));

        }



        item.Value = (decimal)(_random.Next(100, 6000) / 100.0);

        lock (_stocksLock)

        {

            Stocks.Add(item);

        }

        Debug.WriteLine(item.Symbol);

    }

}

I'll leave the choice of which one is appropriate up to the folks designing individual applications. It sounds like a punt, but it really is up to you guys. Each has merits (fewer lock acquisitions in first one, more atomic actions and less thread blocking in second one), but really are very application dependent. In my particular demo example here, with 100 iterations, I'm fine with handling the lock outside the loop.

About the EnableCollectionSynchronization Overload

Here's one question that Sam answered. I'll quote him directly.

Q: Why are there two overloads to EnableCollectionSynchronization?

A: You pick which overload of EnableCollectionSynchronization to use based on how your app synchronizes access to its own collection. If you're using fancy synchronization primitives - semaphores, ReadWriteLock, ManualResetEvent, etc. - you'd use the overload with a callback argument. Whenever WPF needs to touch the collection, it calls the callback, which uses the fancy primitive to gain the right permissions. On the other hand, if you're just using "lock(x) { … }", you'd use the overload with just a lock object, passing in x. Whenever WPF needs to touch the collection, it also does "lock(x) { … }". This saves one level of callback in the common case.

Also note that you can use BindingOperations.DisableCollectionSynchronization(collection) when you want to stop using synchronization.

Getting in Before the CollectionView is Created

The BindingOperations class provides an event CollectionRegistering, which lets you register the collection for cross-thread access before any CollectionView instances are generated for it. Inside this event handler, you can do the actual registering of the collection. Here's an example:

public ObservableCollection<Stock> Stocks { get; private set; }



private object _stocksLock = new object();



public MainViewModel()

{

    Stocks = new ObservableCollection<Stock>();

    BindingOperations.CollectionRegistering += BindingOperations_CollectionRegistering;



    //BindingOperations.EnableCollectionSynchronization(Stocks, _stocksLock);

}



void BindingOperations_CollectionRegistering(object sender, CollectionRegisteringEventArgs e)

{

    Debug.WriteLine("CollectionRegistering Event");

    if (e.Collection == Stocks)

    {

        BindingOperations.EnableCollectionSynchronization(Stocks, _stocksLock);

    }

}

This is actually a good place to handle the registration, as you know you'll get to register for cross-thread access at the right time, before any dependent objects are created. In fact, I'd say this is the best place to do the EnableCollectionSynchronization call. You can do it in the constructor for simple apps, but once you start adding views (and sorting, and datagrids and the like), you'll want to do it here.

What's Happening with Change Notifications

Inside the framework, pending change notifications from the background thread are queued up and then acted on by the UI thread when it has time. This helps increase responsiveness for higher-priority events like input (mouse, keyboard, touch).

This is new for .NET 4.5 as part of this cross-thread collection work.

Fin

I hope you've found that this post helps clarify some of the open questions from the previous post. The work the WPF team has done to enable cross-thread collections is a fair bit of work, even though it surfaces through a pretty small API. This is also one of those features which will simply make your own application code nicer, with less plumbing gunk in it.

Updated example code attached.

Suche der BlogEngine.NET mittels Knockout.js verbessern - ein Praxisbeispiel

Norbert Eder [MVP] — 2012-01-19T15:25:52

In meiner Serie zu Knockout.js habe ich bereits gezeigt, was diese Bibliothek leisten kann. Nichts liegt also näher, als das eigene Blog ein wenig auf Vordermann zu bekommen. Stein des Anstoßes ist die Suche, die bei BlogEngine.NET sehr altertümlich wirkt und in meinem neuen Design daher bis dato nicht berücksichtigt wurde. Mit Knockout.js sollte eine verbesserte Variante schnell implementiert sein. Da die Suchergebnisse durch diverse Bots auch nicht indiziert werden müssen, kann Knockout.js bedenkenlos eingesetzt werden. Hier mein Erfahrungsbericht.

Kontext

Um den Kontext für diejenigen zu setzen, die sich weder mit der BlogEngine.NET beschäftigt haben, noch dies wollen, ein kurze Einführung wie die Zusammensetzung hinsichtlich der Suche ist und was alles benötigt wird. Wenn Erfahrungen mit eben diesem System bestehen, kann dieser Abschnitt übersprungen werden.

Die Suche der BlogEngine.NET besteht aus folgenden Teilen:

Klasse Search, welche die Suche übernimmt und Ergebnisse zurück liefert.
Ein Steuerelement SearchBox, welches ein Input-Feld, eine Schaltfläche und noch ein paar andere Dinge rendert. Das Input-Feld selbst reagiert auf ein Enter und leitet eigentlich nur auf die Suchseite weiter.
Ein Widget, welches das Steuerelement verwendet
Eine Suchseite (search.aspx), welche ebenfalls das angesprochene Steuerelement verwendet.

Das ist grob alles. Um das gesamte User Interface der Suche ersetzen zu können, ist es also notwendig, ein einzelnes Steuerelement (zum Einbinden im Header etc.), ein Widget und eine dedizierte Suchseite anzubieten.

Suche via AJAX ermöglichen

Die Suchfunktionalität besteht bereits (durch die Klasse Search). Diese sollte soweit bestehen bleiben, um auch mit zukünftigen Versionen kompatibel zu sein.

Was allerdings fehlt, ist ein Service, um dies nutzen zu können. Damit das Ergebnis am Client gut verarbeitet werden kann, liefert dieses JSON zurück. Zusätzlich werden auf Einstellungen des Blogsystems zurück gegriffen, um die Beschreibungen der Posts für die Ergebnisliste entsprechend zu kürzen. Der Code hierfür kann man sich dann im Download-Package ansehen.

Knockout.js ViewModel

Damit in der UI die notwendigen Bindungen gesetzt werden können, ist ein entsprechendes ViewModel notwendig, nennen wir es FastSearchViewModel. Welche Möglichkeiten soll es bieten?

Es muss der Suchbegriff abgefasst werden.
Der Benutzer kann wählen, ob Kommentare durchsucht werden sollen. Diese Information ist ebenfalls durch das ViewModel zu halten.
Die AJAX-Suche muss unter Angabe des Suchbegriffs durchgeführt werden.
Eine Liste der Ergebnisse ist zur Verfügung zu stellen.
Der Benutzer möchte Rückmeldungen á la “Keine Suchergebnisse” erhalten. Diese müssen angeboten werden.
Die Suche kann theoretisch dreimal auf einer Seite vorkommen (Suchfeld, Widget und Suchseite). Dieser Umstand ist zu berücksichtigen (wichtig für die Datenbindung auf einen bestimmten Bereich, da sonst alle Suchmöglichkeiten mit derselben Bindung ausgestattet werden).
Schlussendlich bedarf es noch Kleinigkeiten, wie das Zurücksetzen des Eingabefeldes bei einem Klick bzw. dem Auslösen der Suche bei Betätigen der Enter-Taste.

All diese Dinge wurden im nachfolgenden ViewModel berücksichtigt.

     var FastSearchViewModel = function (containerElement) {

        var self = this;

        self.container = containerElement;

        self.searchValue = ko.observable('');

        self.includeComments = ko.observable(false);

        self.foundItems = ko.observableArray();

        self.showNoItemsFound = ko.observable(false);

        self.hasSearchValue = ko.computed(function () { return self.searchValue().length > 0; }, self);

        self.hasResult = ko.observable(false);

        self.notExecuted = ko.observable(true);

        self.search = function () {

            var dto = { "searchTerm": self.searchValue(), "includeComments": self.includeComments() };

            $.ajax({

                url: "uri/to/searchmethod",

                data: JSON.stringify(dto),

                type: "POST",

                contentType: "application/json; charset=utf-8",

                dataType: "json",

                success: function (result) {

                    self.foundItems = ko.observableArray();

                    if (result.d.Posts && result.d.Posts.length > 0) {

                        for (var i = 0; i < result.d.Posts.length; i++) {

                            self.foundItems().push(new ResultViewModel(result.d.Posts[i].Title, result.d.Posts[i].Content, result.d.Posts[i].Link));

                        }

                        self.showNoItemsFound(false);

                        self.hasResult(true);

                    } else {

                        self.showNoItemsFound(true);

                        self.hasResult(false);

                    }

                    self.notExecuted(false);

                    ko.applyBindings(self, self.container);

                }

            });

        };

        self.inputChanged = function (sender, event) {

            if (event.keyCode === 13 && self.hasSearchValue()) {

                this.search();

            }

        };

        self.clear = function (sender, event) {

            self.searchValue('');

            self.hasResult(false);

            self.showNoItemsFound(true);

            self.notExecuted(true);

        };

        self.closePopup = function () {

            self.hasResult(false);

        };

    };

Zu beachten ist, dass die Ergebnisse aus dem AJAX-Aufruf in ein weiteres ViewModel geschrieben werden (ResultViewModel). Dies ist notwendig, damit die Bindungen greifen, die in einem Template für die einzelnen Einträge festgelegt sind. Hier der entsprechende Code:

    var ResultViewModel = function (postTitle, postContent, postLink) {

        this.title = ko.observable(postTitle);

        this.content = ko.observable(postContent);

        this.link = ko.observable(postLink);

    };

User-Interface

Das User-Interface muss nun die für die Suche notwendigen Elemente zur Verfügung stellen und die Bindungen festlegen. Hier das auf die Suchseite vereinfachte Markup:

    <div id="fastsearchpage">

        <input id="fastsearchbox" data-bind="value: searchValue, valueUpdate: 'afterkeydown', event: { keyup: inputChanged, click: clear }" placeholder="Suche" onkeypress="return noenter()"></input>

        <input id="fastsearchcomment" type="checkbox" data-bind="checked: includeComments">Kommentare inkludieren</input>

        <input type="button" id="fastsearchbutton" data-bind="click: search, enable: hasSearchValue" value="Durchsuchen"></input>

        <div id="fastsearchresult" data-bind="template: { name: 'searchresult-template', foreach: foundItems }">

        </div>

        <div id="nofastsearchresult" data-bind="visible: showNoItemsFound">

            <p>

                Keine Suchergebnisse.

            </p>

        </div>

        <div id="nofastsearchexecuted" data-bind="visible: notExecuted">

            <p>

                Geben Sie einen Suchbegriff ein und drücken Sie Enter oder die Suchen-Schaltfläche.

            </p>

        </div>

        <script type="text/html" id="searchresult-template">

            <div class="searchitem">

                <a data-bind="attr: { href: link, title: title }">

                    <span>

                        <strong data-bind="text: title"></strong>

                    </span>

                </a>

                <div data-bind="text: content"/>

            </div>

        </script>

        <script type="text/javascript">

            function noenter() {

                return !(window.event && window.event.keyCode == 13);

            }

        </script>

    </div>

Der Großteil der darin verwendeten Bindungen bringen zur Knockout.js-Serie nichts Neues. Interessant ist das Eingabefeld selbst:

    <input id="fastsearchbox" 

           data-bind="value: searchValue, valueUpdate: 'afterkeydown', event: { keyup: inputChanged, click: clear }" 

           placeholder="Suche" onkeypress="return noenter()">

    </input>

Dieses selbst hat eine Bindung auf searchValue um den eingegebenen Suchbegriff in das ViewModel durchzuschreiben. Ebenfalls wird das Ereignis OnKeyUp abonniert um auf das Betätigen der Enter-Taste hin zu prüfen, da in diesem Fall die Suche ausgelöst werden sollte. Beim Standardverhalten der value-Bindung ist es nun aber so, dass zum Zeitpunkt des Auslösens des Ereignisses (und des Verarbeitens in der Funktion des ViewModels) der eingegebene Wert noch nicht bekannt ist. Das liegt daran, dass die value-Bindung erst beim Verlassen des Fokus die Bindung selbst aktualisiert.

Um aber derartige Anforderungen abzudecken, steht der zusätzliche Parameter valueUpdate bereit. Darüber lässt sich konfigurieren, zu welchem Zeitpunkt die gebundene Eigenschaft des ViewModels aktualisiert werden soll. Folgende Möglichkeiten stehen zur Verfügung:

change: Das ist die Standardeinstellung und aktualisiert das ViewModel wenn der Fokus zu einem anderen Element geht.
keyup: Die Aktualisierung findet beim Loslassen des Tastendrucks statt.
keypress: Das ViewModel wird aktualisiert, wenn eine Taste gedrückt wurde. Hier ist anzumerken, dass dieses Ereignis mehrfach ausgelöst wird, wenn der Benutzer auf der Taste bleibt.
afterkeydown: Hier wird das ViewModel aktualisiert, sobald der Benutzer beginnt, ein Zeichen einzugeben. Diese Auswahl eignet sich bestens dazu, wenn das ViewModel in Echtzeit aktualisiert werden soll.

Stellen wir also valueUpdate auf afterkeydown, steht beim Auslösen der Suche der durch den Benutzer eingegebene Suchbegriff bereit.

Hinweis: Zusätzlich wird beim OnKeyPress noch die Funktion noenter() aufgerufen. Diese dient lediglich dazu, ein Submit eines eventuell vorhandenen Formulars zu verhindern.

Binden des ViewModels

Damit die Bindungen angezogen werden, muss ko.applyBindings aufgerufen werden. Wie bereits oben angesprochen, kann die Suche selbst mehrfach auf der Seite vorkommen. Damit nicht alle an dasselbe ViewModel gebunden werden (und dadurch anspringen, sobald es in einem der Felder eine Aktion gibt), sollte überprüft werden, wie viele Vorkommen vorhanden sind und an jedes eine eigene Instanz des ViewModels gebunden werden.

Das Ergebnis

Für die Verwendung unter BlogEngine.NET ist nun nicht mehr viel zu tun und weniger relevant, da lediglich Widget-Control (als Host) implementiert werden muss etc. Dies kann sich der interessierte Leser im Download genauer ansehen.

Das Resultat kann sich jeder hier im Blog ansehen, da alle Suchmöglichkeiten auf dieser Implementierung beruhen.

So sieht die Einbindung des Suchfeldes aus:

Und hier noch die Suchseite:

Download / BlogEngine.NET Package

Der Download ist über die BlogEngine.NET Gallery verfügbar. Darin befindet sich die Erweiterung zur BlogEngine.NET selbst, als auch die gesamte Implementierung. Wer diese Erweiterung für sein Blogsystem basierend auf BlogEngine.NET einsetzen möchte, findet weitere Informationen unter http://devtyr.com/fastsearch.html.

Feedback

Wie immer freue ich mich über jegliches Feedback. Sowohl zum Code selbst, als auch grundsätzlich zur Funktionalität der BlogEngine.NET-Erweiterung.

Full Stack Resumes–MVVM Design

Jesse Liberty [MS] — 2012-01-19T15:15:29

New Videos Uploaded

Jesse Liberty [MS] — 2012-01-18T18:50:10

Supersampling

Juan María Laó Ramos — 2012-01-17T22:30:03

Nueva entrega de ja serie sobre técnicas de antialiasing, esta vez en DesarrolloWeb.com. Espero que os sirva

Desplegando un ChildWindow en objetos Window en Silverlight 5

La Liga Silverlight — 2012-01-17T17:33:41

Silverlight 5 cuenta con muchas características enfocadas principalmente a la construcción de aplicaciones de negocio, una de ellas es la creación de Ventanas de Sistema. Sin embargo, si necesitas mostrar un ChildWindow dentro de una ventana creada dinámicamente, el comportamiento que obtendrás tal vez no es el esperado, y es que el ChildWindow se mostrará en la raíz de la aplicación (comunmente MainPage) y no en la ventana nueva en donde estás ejecutando el código. Por ejemplo, en la siguiente figura la aplicación crea la ventana de la izquierda… …pero al crear el objeto ChildWindow dentro de la ventana en donde esperas que se despliegue: Este comportamiento no es el esperado ¿cierto? En este artículo explicaré cómo puedes obligar que el ChildWindow se dibuje adecuadamente en la ventana que le corresponda. Puedes leer el artículo completo aquí

Calling Navigate From The View Model

Jesse Liberty [MS] — 2012-01-17T17:04:01

WPF-Blogger.com [Complete Feed]

Marketplace now open in 5 new markets

Complimentary Copies

[WP7] Usando los servicios de Live

Windows 8 Touch Events Interactions

Cell·SDK: El mismo código en Windows Phone, iOS y Android

Event Handler Memory Leaks, Unwiring Events, and the WeakEventManager in WPF 4.5

The Problem

Basis for Comparison

Solution 1: Unwire Your Event Handlers

Solution 2: Weak Events

Summary

12 Horas de Visual Studio - Exprime las vistas en ASP.NET MVC

Aliasing en Texturas

Memory Profiling for Application Performance

A Sample Application

Visualizing the leak

Analysis

Conclusion

12 Horas de Visual Studio - Calidad de Software y patrones de diseño en Windows Phone 7.5

Yet Another Podcast #58–Julie Lerman and EF/CF

Happy 75th Birthday, Philip Glass!

Jetzt Backbone.js lernen: Konzept WPF-Blogger

Status Quo

Feed-Aggregat

Quo vadis?

Allgemeine Verwendbarkeit

Eingestellte Blogs und Artikel

Administration

Nichtziel

Offene Fragen / Feedback erwünscht

Bewertung

Kommentare

Ausblick

The .NET Gadgeteer Diaper Alarm Part 1 (Moisture Sensor)

First Iteration

Hardware

Yee Old Test Subject

Software

Le Code

Second Iteration - Configuration

Potentiometer approach

Summary

The Last Catfish in the East Village?

Multisampling

Jetzt Backbone.js lernen: Die Serie

Praxisbeispiel

Was kann der Leser nun erwarten?

Eingesetzte Technologien und Bibliotheken

Sourcecode / Sharing

Inhalt

Feedback

BAOC Countdown and WPAppItUp Wrap-Up

Playing A Sound, Simplified

Jetzt Knockout.js lernen: Mapping

Voraussetzungen

Grundlagen / Wiederholung

Beispiel

Ins Mapping eingreifen

Fazit

Download / Showcase

Feedback

Jetzt Knockout.js lernen: Die Serie

The n00b filter: Bad UX at its Finest in Eagle PCB

MVC / Razor Style-Switcher – Quicky

Maker Geek Roundup 006 for 1/25/2012

3d Printing and CAD/CAM/CNC

.NET Gadgeteer

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

Arduino

Other Micro Controllers (PIC, AVR, ARM and more)

General Electronics and Hardware Hacking

Robotics and Robotics Studio

Clocks

Synthesizers, MIDI and Electronic Instruments

Photography

General Maker

Retro Computing and Commodore!

Misc Geek

Just Awesome