Nun ist es wohl endlich soweit. Am letzten Tag meiner Ausbildung (morgiger Prüfungstag nicht mit eingeschlossen) kann ich nun voller Stolz auf 3 Jahre neuen Wissens und neuer Freunde zurückblicken.

Es war nicht immer einfach, den Kopf “über Wasser” zu halten und sich dazu durchzuringen, doch noch ein wenig intensiver an neue Dinge heranzugehen. Aber es hat sich definitiv bezahlt gemacht.

Was habe ich also in diesen 3 Jahren erreicht? Worauf kann ich stolz sein?
Ich habe nicht nur meine Ausbildung zum Fachinformatiker für Anwendungsentwicklung absolviert. Ich habe 3 Monate Gütersloh überstanden, habe mich in der Berufsschule unter anderem mit Wirtschaft gequält, bin 2-fach zertifiziert und habe mir doch ein wenig Respekt unter meinen Kollegen erarbeitet…

Für einige mag das sicherlich wenig sein, aber ich kann von mir selbst behaupten: Darauf kannst du stolz sein

After a long time being idle I want to present a plug-in for Bukkit which I have written myself. But first of all, let me tell you a few things about what Bukkit is.

Bukkit is an open-source extension for the new popular sandbox game Minecraft. It enhances the possibilities of SMP (multiplayer servers) by introducing the possibility to add plug-ins which can change the behavior of the game e.g. breaking blocks instantly or enable the ability of flying. If you wish more detailed information about Minecraft and Bukkit, take a look at this (Minecraft) and this (Bukkit).

But now the core of this post: XPM (Xtended Plug-in Manager). It is a Bukkit plug-in for plug-in management with the following features:

• Listing all/enabled/disabled plug-ins
• Enabling a plug-in or loading + enabling it, if it was dropped into plug-in folder while server is running
• Disabling a plug-in
• Getting the version of a plug-in
• Getting the commands of a plug-in
• Reloading a plug-in e.g. when the configuration was changed

If you want to give XPM a try, you can find more detailed information and the plug-in itself here.

Die Arbeiten an der neuen Streetfighter-Homepage sind nun fast abgeschlossen und werden in den nächsten Tagen in die Testphase übergehen. Als Basis für die Seite dient WordPress, was die Erweiterung von Funktionalitäten vereinfacht. Folgendes wurde überarbeitet bzw. komplett neu eingeführt:

• Seitengestaltung
• Vereinfachung der Pflege für Ergebnisse mit PHP
• Kalender für die Übersicht kommender Spiele
• Sidebar-Anzeige der 3 folgenden Spiele
• Über Admin-Portal pflegbare Ligatabelle
• Anzeige der Liga-Ergebnisse (Neben den eigenen Ergebnissen) + Filterfunktion
• RSS-Feed für Gästebuch nutzbar
• Spieler-Übersicht umorganisiert
• Einträge im Gästebuch kommentierbar
• und noch einiges mehr im Backend

Die neue Seite ist über über folgenden Link zu erreichen
http://streetfighter.bplaced.net/

Nach einem Aufschrei nach einer neuen Homepage, müssen nun erst mal Ideen gesammelt und ausgewertet werden.

Eure Ideen bitte unten als Kommentar hinterlassen.

Gruß
Hoffi

Getting a response from a web service using Cocoa/Objective-C is not very difficult. But how to handle a response in JSON format? That’s what I want to show here.

There is a very useful and easy to use open-source JSON framework developed by Stig Brautaset on GitHub. That framework can transform JSON strings to Objective-C objects and vice versa. Here are the steps to use it in an example parsing the Twitter public timeline.

At first, get the latest build of the framework from JSON-framework on GitHub.

Open the downloaded folder. Now you can drag the Classes folder into your project after renaming it or you can also drag the contained files in a prepared group of your project (in Xcode).

Now the source is included in your project and you can start working with it by including the following *.h-file:

#import "JSON.h"

Create a SBJsonParser object to parse JSON into a native Cocoa object. SBJsonParser will return either a NSDictionary or NSArray depending on the structure of the data. You should know ahead of time the structure of the JSON object your parsing and whether it’s a single JSON object or an array of JSON objects and use the appropriate Cocoa class.

// Create SBJSON object to parse JSON
SBJsonParser *parser = [[SBJsonParser alloc] init];

// parse the JSON string into an object
// assuming json_string is a NSString of JSON data
NSDictionary *object =
      [parser objectWithString:json_string error:nil];

Here is the promised example to parse the Twitter public timeline:

// Create new SBJSON parser object
SBJsonParser *parser = [[SBJsonParser alloc] init];

// Prepare URL request to download statuses from Twitter
NSURLRequest *request = [NSURLRequest requestWithURL:
[NSURL URLWithString:
@"http://twitter.com/statuses/public_timeline.json"]];

// Perform request and get JSON back as a NSData object
NSData *response = [NSURLConnection
sendSynchronousRequest:request
returningResponse:nil error:nil];

// Get JSON as a NSString from NSData response
NSString *json_string = [[NSString alloc]
initWithData:response encoding:NSUTF8StringEncoding];

// parse the JSON response into an object
// Here we're using NSArray since we're parsing an 
// array of JSON status objects
NSArray objectWithString:json_string error:nil];

// Each element in statuses is a single status
// represented as a NSDictionary
for (NSDictionary *status in statuses)
{
  // You can retrieve individual values using objectForKey 
  // on the status NSDictionary
  // This will print the tweet and username to the console
  NSLog(@"%@ - %@", [status objectForKey:@"text"],
  [[status objectForKey:@"user"] objectForKey:@"screen_name"]);
}

I hope this example is understandable and will help you to handle with JSON in Cocoa/Objective-C.

Seit Anfang November 2010 besitze ich die oben genannte E-Gitarre der Marke Harley Benton. Ich möchte hier nun meinen persönlichen Erfahrungsbericht der Öffentlichkeit zur Verfügung stellen.

Erst mal ein paar technische Daten:

1.000 Besucher… und das seit dem 02.09.2010; also nach 5 Monaten und 18 Tagen

Ich gebe zu, es sind sicherlich Posts dabei, die nicht für jedermann interessant zu lesen bzw. langweilig sind. Außerdem gibt es Posts, welche ein gewisses technisches Grundverständnis erfordern bzw. versuchen solches aufzubauen.

Trotzdem… vielen Dank für die vielen Besuche, die eifrigen Leser und eine Erfahrung mehr. Andere zu informieren macht Spaß =)

VIELEN DANK!!!

1.000 visitors… since 02.09.2010; after 5 months and 18 days

I have to admit, that there are posts of course, which were not interesting for anybody or just boring.
In addition there are posts, that require some technical basic understanding or just trying to create it.

Anyway… thank you very much for so many visits, the eager readers and one experience more. To inform other people is fun =)

THANK YOU!!!

Part I: The basement
Part II: From basement to the second floor

In the last part I made a short introduction to Caliburn.Micro (CM) and started building the app by its basement, the Shell. In this part I will show how to handle with separate modules and the navigation between them.

The application is now looking like the following (the red is what we have, the black what is missing yet):

The projects structure (for this simple project) looks like that:

As you can see, there are folders for the specific modules and its screens but they all are empty yet. Let’s start filling them.
At first, create a new WPF UserControl.xaml with the name “ModuleA” in the same named folder. Repeat that step for the other two modules. Now there is the basic module view base but the logical part is necessary to. So the individual viewmodels have to be created too. For each view, create a new class named “ModuleAViewModel”, “ModuleBViewModel” and “ModuleCViewModel”. The base of each viewmodel should look like this:

using Caliburn.Micro;

namespace CaliburnMicroWPF.Modules.ModuleA
{
    public class ModuleAViewModel : Conductor<Screen>.Collection.OneActive
    {
        public ModuleAViewModel()
        {
            AttachView(new ModuleA(), ViewLocator.DefaultContext);
            ViewLocator.InitializeComponent(
                GetView(ViewLocator.DefaultContext));
        }
    }
}

Let me explain some things to this code.

Conductor<Screen>.Collection.OneActive

 
Means that the module is a conductor of screen objects with only one active screen at the time.

public ModuleAViewModel()
{
    AttachView(new ModuleA(), ViewLocator.DefaultContext);
    ViewLocator.InitializeComponent(
        GetView(ViewLocator.DefaultContext));
}

In the first part I mentioned that CM handles the binding between view and viewmodel by name by removing the “Model” part from viewmodels name. In this case CM would not find any module named “ModuleAView”, so the binding between view and viewmodel has to be done by hand by attaching the related view. In this example, the views do not have any code behind where to execute the InitializeComponent() and therefore the ViewLocator can handle this. That’s the viewmodel part so far. Take a look at the module views:

<UserControl x:Class="CaliburnMicroWPF.Modules.ModuleA.ModuleA"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>

        <StackPanel Orientation="Horizontal" Grid.Row="0"
                    HorizontalAlignment="Center">
            <Button x:Name="NavigateToModuleB" Content="ModuleB"
                    Width="80" Margin="5"/>
            <Button x:Name="NavigateToModuleC" Content="ModuleC"
                    Width="80" Margin="5"/>
        </StackPanel>

        <ContentControl x:Name="ActiveItem" Grid.Row="1"/>
    </Grid>
</UserControl>

The module views are made up of a StackPanel containing two buttons for navigation and one ContentControl for holding the actual screen later on. The Buttons and the ContentControl have specific names which tell CM to bind them to a specific method (Buttons) or a specific property (ContentControl) of the related viewmodel. “NavigateToModuleB” and “NavigateToModuleC” are methods in the viewmodel to handle the navigation between the modules and “ActiveItem” is a property provided by the Conductor class defining the currently active screen. The implementation of the methods can look like the following:

public void NavigateToModuleB()
{
    IoC.Get<IEventAggregator>().Publish(
        new NavigationEvent(NavigationModules.B));
}

public void NavigateToModuleC()
{
    IoC.Get<IEventAggregator>().Publish(
        new NavigationEvent(NavigationModules.C));
}

The Publish() of the EventAggregator requires one parameter of type T. Because of that I had created a simple class containing one property; an enum value named like the module to navigate to. That’s the navigation on module level but I do not want to handle the navigation between the modules on this level because of separation. Therefore the ShellViewModel should handle this.

using System.ComponentModel.Composition;
using Caliburn.Micro;
using CaliburnMicroWPF.Events;
using CaliburnMicroWPF.Modules.ModuleA;
using CaliburnMicroWPF.Modules.ModuleB;
using CaliburnMicroWPF.Modules.ModuleC;
using CaliburnMicroWPF.Navigation;

namespace CaliburnMicroWPF
{
    [Export(typeof(IShell))]
    public class ShellViewModel : Conductor<Screen>.Collection.OneActive,
                                    IShell, IHandle<NavigationEvent>
    {
        private ModuleAViewModel _moduleA;
        private ModuleBViewModel _moduleB;
        private ModuleCViewModel _moduleC;

        public ShellViewModel()
        {
            _moduleA = new ModuleAViewModel();
            _moduleB = new ModuleBViewModel();
            _moduleC = new ModuleCViewModel();

            IoC.Get<IEventAggregator>().Subscribe(this);
        }

        protected override void OnActivate()
        {
            base.OnActivate();

            ActivateItem(_moduleA);
        }

        #region IHandle<NavigationEvent> Members

        public void Handle(NavigationEvent message)
        {
            switch (message.NavigateTo)
            {
                case NavigationModules.A:
                    ActivateItem(_moduleA);
                    break;
                case NavigationModules.B:
                    ActivateItem(_moduleB);
                    break;
                case NavigationModules.C:
                    ActivateItem(_moduleC);
                    break;
                default:
                    break;
            }
        }

        #endregion
    }
}

As you can see, the ShellViewModel is a Conductor<Screen>.Collection.OneActive too because I want only one module displayed at the time. Conductor is inheriting from ConductorBase which is inheriting Screen. That’s why the Shell is a Conductor of Screen objects. In the constructor I initializes an instance of each module, to access them later on, and subscribe the ShellViewModel itself the the EventAggregator, to listen to events published by the application, the modules or the screens. To listen to a specific event, I had to add the interface implementation of the interface IHandle<NavigationEvent>.

That’s the module-based application so far. You can download the example project here. In the next part, the screens will be added to their modules to provide the third- and the last level of this application.

Part I: The basement
Part II: From basement to second floor

First of all I want to tell what Caliburn.Micro (herein after referred to as CM) actually is.
”A small, yet powerful implementation of Caliburn designed for WPF, Silverlight and WP7. The framework implements a variety of UI patterns for solving real-world problems. Patterns that are enabled include MVC, MVP, Presentation Model (MVVM), and Application Controller.” Caliburn.Micro on CodePlex

When I started using CM I was surprised how easy DataBinding in WPF can be. CM handles the binding with implemented naming conventions, so the view “ModuleAView” is bound to the viewmodel “ModuleAViewModel” just by removing the "”model” part from the viewmodels name. Controls are bound by name too. A Button named “SayHello” (x:Name=”SayHello” in XAML) is bound to the method “SayHello()” in the related viewmodel. Seems to be easy, doesn’t it?

Now, let’s come to the core of this post: the module-based application using CM. To give an idea what is meant with a module-based application, take a look at the following draft:

There’s the main application window (ShellView by default, can be renamed) containing a collection of separate modules. Each module contains a collection of different module screens. This examples constraint is, that only one module is active/displayed and only one screen of the active module is displayed. Let’s take a look to some source code…
(NOTE: Because this is a very simple example, I did not structure the project like I normally do.)

Shell (ShellView + ShellViewModel)
ShellView.xaml

<Window x:Class="CaliburnMicroWPF.ShellView"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Grid Background="White">
        <ContentControl x:Name="ActiveItem"/>
    </Grid>
</Window>

ShellViewModel.cs

using System.ComponentModel.Composition;

namespace CaliburnMicroWPF
{
    [Export(typeof(IShell))]
    public class ShellViewModel : IShell
    {

    }
}

That’s the basement of the application. To get the modularity, it needs to create views and viewmodels for every module and every screen as well. The navigation logic has to be implemented either in the shell, the modules or in the screens themself. My favourite approach is an event-based navigation to get a well-separated application. Therefor CM provides its own EventAggregator which is accessible with

IoC.Get<IEventAggregator>()

 
For more information about the EventAggregator look here.

To the end of this part, there’s our basement consisting of the ShellView and the related ShellViewModel as the top-level. You can download the example project here. In the next part, the modules will be added to the project to provide the second-level of the module-based application.