• Ungarn
• Litauen
• Nordic Countries (hier tippe ich einfach mal auf Skandinavien)
• Polen

Diese waren auch bei früheren Updates bereits unter den Ersten, was sich somit in Samsung’s bisherige Update-Politik einreiht.

Man darf gespannt sein, wann das Update für Deutschland aktiviert wird…

(Quelle: http://www.androidpit.de/)

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

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.

• 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/

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.

Erst mal ein paar technische Daten:

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!!!

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.