Sully

Once again I'm visiting my work flow for syncing photos wirelessly from my phone, to my computer and back to the phone. I have blogged about this a few times in the past. In my last blog post regarding photo sync, I had turned to Lightroom mobile. It worked well for photos, but lacked any kind of support for videos.

A lot has changed over the last year. Now both Apple and Google provide bi-directional, wireless, sync of both photos and videos to and from your mobile devices, while keeping originals synced on your desktop computer and stored in the cloud. Take a photo or record a video on your device, open your computer to edit it, view the changes later in the day on your phone. It's pretty slick.

Now that both companies support sync in this manor, I thought I'd go over my workflow. The changes in the way both services handle the sync have caused me to change my work flow a bit. Since I use iOS and OS X devices most, I will be writing about Apples services today. At some point in the future I'll try and write something up on using Google Photos + Google Drive on Macs and iOS for cross-device syncing of photos and videos.

iCloud Photo Library

In 2014 Apple introduced the new iCloud Photo Library and Photos app in iOS 8. The iCloud Photo Library handles synchronizing all of your full resolution photos and videos across every iOS and OS X based device you own. Unfortunately, this is not available on AppleTV.

So, we need to turn on iCloud Photo Library on the iOS devices. You can do that by going into the iOS Settings app and navigating to Photos & Camera.

I typically leave my iOS devices with Optimize iPhone Storage enabled. This will upload the original files to the iCloud Photo Library; saving a reduce size version for the smaller iOS screens on the device. In some cases, it will remove the photo all together and leave a thumbnail. The next time you view the photo, it will download it again. I've only seen this happen on old photos, or when re-installing iOS fresh.

When you make this change you will notice that the Camera Roll is no longer available. Instead it is replaced with All Photos. That is because the photos are no longer stored on-device. Now they are stored in a shared library with multiple iOS devices, which requires more than what the original Camera Roll provided.

Now that we have iCloud Photo Library setup on your iOS devices to upload all of their photos and movies, we need to setup OS X. The Mac works much the same as iOS. You open up the Photos app (requires Yosemite or newer) and open up it's preferences. The only difference is that we want to tell the app to download all of the originals onto our Mac's hard-drive. This way, we always have our originals locally and aren't depending on the cloud keeping them forever.

Now we have all of our photos (and videos!) synchronizing wireless between our iOS devices and the Mac.

iCloud Photo Library to Lightroom

So we now have our photos and videos locally on our internal or external hard-drives. What do we do with them then? We export them from iCloud Photo Library and move them into Lightroom! I use Lightroom to handle all of my keywording and orginization of my photos and videos. The new OS X based Photos app fully supports keywording and organizing into albums and folders. It does have some issues, like not being able to move an album in and out of folders once the album is created. Keywords will sync across all of your devices, but the folder/album organization will not. Albums are only synced to iOS in a flattened layout, with no nested folders. An example of this on iOS looks like the following screenshot, where all of the years are flattened out.

As a result of this, I will continue to use Lightroom for my photo organization. I keep Lightroom as my source of truth, where all of my originals will always live. In Lightroom, they are organized like this:

So how do I get my photos from the OS X Photos app into Lightroom? I use a Smart Album in the Photos app! With Smart Albums, I can keep track of what date I last pulled photos into my Lightroom library. There are two Smart Albums I create. One that filters all photos that I have already brought into my Lightroom library, and a second that filters all photos that I have yet to export from Photos, and import into Lightroom.

So before we create our Smart Albums, we must first actually export the photos from iCloud Photo Library and get them into Lightroom. When I first turned on iCloud Photo Library, I had to wait just a little over 24 hours while it got all of the photos synchornized across the devices and downloaded onto my Mac. Your mileage will vary, depending on how many you have. You can see in the Photos preferences picture above, that it tells me my Photos library was just updated. That means I am in sync and nothing is outstanding. During a first time sync, it will count down how many photos and/or videos it has remaining to download onto your Mac.

So, if your sync is done, select the Photos library

Next you will need to select every photo in that library. You can do this with Command+A or using the Edit menu.

Lastly, we will export the selected photos from the Photos app, so that we can import them into Lightroom. Note that exporting will not remove them from iCloud Photo Library. It will instead create a copy of every photo and place the copy in the desired export folder. This is ideal, so that we can continue to view the photos and videos on our devices without any issue.

You can set some settings on your photos prior to the export taking place. I typically use the following settings for my exports.

Clicking the Export button will prompt you with where you want to store the files. You can store them anywhere for now. When we do the import into Lightroom, the Lightroom application will move them into their final resting place within your Lightroom library. So just pick a temporary location for now.

Now that the photos and videos have been exported, we need to get them into Lightroom. We can do that by opening Lightroom and doing an import.

On the left-hand side of the Lightroom import screen is the source of the files you want to bring into Lightroom. You will navigate to your temporary folder that holds your exported iCloud Photos. On the right-hand side you will select where your Lightroom library is, this will be their permanent storage location.

Now your photos are all set in Lightroom. You can go ahead and organize them, keyword them and edit them as you want. Next, make a back up of your Lightroom library! It's always good to keep a back up of your photos elsewhere once you have them all imported. Lightroom handles backups automatically for you when ever you close the app.

Once you are done organizing and keywording all of your photos and videos, go ahead and select them all in iCloud Photo Library and delete them. Once they are deleted, you will drag and drop all of the photos from Lightroom, into iCloud Photo Library. This will sync all of the keywords, meta-data, and edits made to your photos on to all of your devices.

Now you have your photos in sync across all devices. The first time you do this, it will take a bit. If you do this every couple of weeks, it won't be to much of a hastle. Let's cover how to do that now, using the Smart Albums I mentioned earlier!

Smart Albums

We will create a new Smart Album that will keep track of what photos and videos you have already imported and processed into Lightroom, and brought back into the iCloud Photo Library. A second Smart Album keeps track of what photos and videos are in your iCloud Photo Library, but not in Lightroom. These are going to be handled simply by tracking dates.

The first smart album is called "Importing - Pending", meaning these photos and videos are pending the import process into our master Lightroom library. You could call it something else, like "Need exporting" if you want.

This Smart Album will show me all of the photos and videos I need to export from iCloud Photo Library, and import into Lightroom. The nice part of using a Smart Album like this, is that now I know all of the photos I need to delete, and re-upload once I am done organizing my stuff in Lightroom. I can open this Smart Album, select all of the photos and videos, delete them, then drag and drop my stuff from Lightroom back into iCloud Photo Library. I set the date to be the date that I exported all of those photos.

The next Smart Album is what we will use to track what has already been imported into our Lightroom library. This will be called "Importing - Processed" and will have a date set to the day of the day you exported your photos. There might be some overlap when you next do some importing, but that's alright. Lightroom does a good job of detecting duplicate photos and show which ones it thinks are duplicates and won't import. Worse case, you have to review each photo for that one day. That's typically not many photos and videos and is worth the extra step to make sure you don't miss any.

Another option would be to add a keyword to every photo in your Lightroom library with a Lightroom keyword. Then you can create Smart Albums that look for that keyword. This way, new photos will lack it and can be added. The only downside is that keywords can't be applied to videos, which is why I chose not to go that route.

Now you have everything you need to keep both Photos and videos in sync across every single device, while maintaining the original, full-resolution, files on your local computer. By adding keywords correctly, you can do full searches in iOS and find photos really fast. As an example, I performed a search in my iCloud Photo Library (with nearly 9,000 files) on iOS for photos of an old car I had 8 years ago. The search results came back instantaneously.

Proper keywording of your photos in Lightroom (or in iCloud Photo Library if you don't want to use Lightroom) can really make it easy to find your photos.

Why Lightroom?

I used Lightroom in this example just because it is the photo suite that I use. The entire section based on Lightroom can be applied to the old iPhoto app or Aperture. If you want to keep your photos in iCloud Photo Library, you can do all the keywording within that app and not both with the whole export/import process. Instead just build smart albums that have look for a "processed" keyword, and add that keyword to every photo you process in iCloud Photo Library directly.

AppleTv

Sadly, the new iCloud Photo Library is not supported by the current generation of AppleTV. I'm not sure why, other than the fact that storage on the device might be an issue (iCloud Photo Library includes videos, where Photostream does not). I'm not sure, so for the time being when you have visitors, you'll need to Airplay your photos to your TV from an iOS device or from your Mac.

Another option could be to use the Flickr app. I have not used the app personally, so I'm not sure what options it has. The app does exist on AppleTV and you can upload every photo in your Lightroom library up to Flickr for viewing on the AppleTV.

I had previously been maintaining two different repositories for the Mud Designer. The first was on my personal GitHub account and the other was on Codeplex.

A few weeks ago I created a new team on Git Hub called Mud Designer. There are several repositories under the team, such as the Mud Engine, the new cross-platform server stuff and the documentation source for the real help docs.

In order to help people navigate the repositories, I have setup a Home repository. For all things Mud Designer, the Mud Designer Home should be your starting place.

Some of the repositories have source in a branch other than Master right now as its being developed. So be sure to check all of the branches out when exploring the code.

Project milestones have been defined on the Mud Engine repository and the server repository. Over the next couple of weeks I will be creating backlog work items in the issue tracker, so people can get an idea Of how far along the project is in each milestone.

As of tonight, the Mud Engine has been tested and runs on Macs running OS X. I was even able to wire up the server and get a OS X server running with the game.

Thanks to how the server was refactored into the adapter pattern I adopted a couple of weeks ago, it took very little code to wire up a OS X based server.

The code

class MainClass { public static void Main(string[] args) { SetupMessageBrokering (); var bootstrap = new Bootstrap (); bool startupCompleted = false; bootstrap.Initialize ((game, server) => { // Start the game loop. while(game.IsRunning) { if (!startupCompleted) { startupCompleted = true; } Thread.Sleep(1); } }); while(!startupCompleted) { Thread.Sleep (1); } } static void SetupMessageBrokering() { MessageBrokerFactory.Instance.Subscribe<InfoMessage>( (msg, subscription) => Console.WriteLine(msg.Content)); MessageBrokerFactory.Instance.Subscribe<GameMessage>( (msg, subscription) => Console.WriteLine(msg.Content)); MessageBrokerFactory.Instance.Subscribe<PlayerCreatedMessage>( (msg, sub) => Console.WriteLine("Player connected.")); MessageBrokerFactory.Instance.Subscribe<PlayerDeletionMessage>( (msg, sub) => { Console.WriteLine("Player disconnected."); }); } }

This code should look almost identical to the source previously posted showing the Mud Engine server running on Windows. The only difference is that I abstracted the code that can be shared across the two platforms into a bootstrap. The shared code is stuff like configuring the server and game, setting up the game and adapter and starting the game.

As development of the engine continues, I will regularly check and make sure it builds on OS X. The engine itself and its server should always run cross-platform without any issues.

I'm not sure yet what I am going to do in regards to the designer tools. Initially I was going to write it as a XAML app for Windows. Considering that the engine can now run on OS X (and I will be testing it on Linux soon), I might reconsider and look at a more cross-platform UI approach. Perhaps that would be a good excuse for me to pick up the new cross-platform ASP.Net MVC 6 stuff Microsoft is doing, and build a cross-platform self-contained web application for the designer.

Back in May I posted about how you could configure the mud server for use with the Mud Engine. Since then, I have built out an implementation of the Adapter pattern. With that, I wanted to demonstrate how you would startup the server with the engine, and configure it.

Previously in the Mud Engine

In the last iteration of my configuration setup, you had to implement the abstract ServerBootstrap class, and then build out an implementation of IServerConfiguration. The bootstrap implementation looked something like this.

public class DefaultServerBootstrap : ServerBootstrap { protected override void Run() { this.Server.GetCurrentGame() .NotificationCenter .Subscribe<ServerMessage>((msg, sub) => Console.Write(msg.Content)); while (this.Server.Status != ServerStatus.Stopped) { Thread.Sleep(100); } } protected override void RegisterAssemblies() { base.RegisterAssemblies(); } protected override void ConfigureServices() { } protected override IServerConfiguration CreateServerConfiguration() { return new ServerConfiguration(); } protected override IServer CreateServer() { var server = new Server(); server.PlayerConnected += this.ExecuteInitialCommand; return server; } protected override IGame CreateGame() { return new DefaultGame(); } protected override IInputCommand InitialConnectionCommand() { returnnew PlayerLoginCommand(); } protected override void RegisterAllowedSecurityRoles(IEnumerable<ISecurityRole> roles) { } }

Then in the application startup, you had to setup the bootstrap.

public static void Main(string[] args) { var bootstrap = new DefaultServerBootstrap(); Task bootstrapTask = bootstrap.Initialize(); bootstrapTask.Wait(); }

This was the minimum that had to be done in order to start the game with a server. There were several issues with this approach, one of which is violating SRP. The bootstrap does a lot of different things that aren't even related to the server. It defines the initial command, creates a player, and creates the game. None of which are specific to the server. These actions can be applicable in a single-player game as well.

The other thing that the bootstrap does is configures any services, and register security roles with the services. Gross. The server startup should be free of IoC dependency injection setup goo. So I set out to fix that with the new Mud Engine Adapters.

Setting up a server with adapters

Now that the server has been migrated over to use the adapter architecture, it's much more straight-forward to get a server running. Previously, the server owned the game. Now, the game owns the server - it just doesn't know it.

To start up the game, and give it a server, we do this.

static void Main(string[] args) { var serverConfig = new ServerConfiguration(); IServer server = new WindowsServer(new TestPlayerFactory(), new ConnectionFactory(), serverConfig); var gameConfig = new GameConfiguration(); gameConfig.UseAdapter(server); var game = new MudGame(); game.Configure(gameConfig); Task gameStartTask = game.StartAsync(); gameStartTask.Wait(); }

In the code above, we create a serverconfiguration. Then we create a WindowsServer instance, giving it a couple of factories and our config. Next we we create a GameConfiguration and register our WindowsServer with the game config. When we call game.Configure(gameConfig), the game will consume the WindowsServer adapter and automatically configure the server using the ServerConfiguration.

Lastly, we start the game calling game.StartAsync(). This initialize and run all of the registered adapters that the game has. In our case, it initializes and runs the WindowsServer. At this point, the WindowsServer is running and can accept incoming client connections.

There is some flexability when it comes to configuring adapters. Each adapter can either skip configuration all-together, or opt into configuration by requiring a configuration class. This can be any class that implements the IConfiguration interface. Taking this approach allows each adapter to have their own config that can be tailored to what they want to expose. In the case of Server Configuration, there is quiet a bit we can do with it. For instance:

var serverConfig = new ServerConfiguration(); serverConfig.OnServerStartup = (context) => Console.WriteLine($"Server running on port {context.Server.RunningPort}");

That code registers a callback that will be invoked when the server is starting. In this example, we just lookup the port the server is running on and write it out to the console. You can do more then just that however.

static void Main(string[] args) { var serverConfig = new ServerConfiguration(); serverConfig.OnServerStartup = (context) => { context.ListeningSocket.BeginAccept( new AsyncCallback(Program.HandleClientConnection), context.ListeningSocket); context.SetServerState(ServerStatus.Running); context.IsHandled = true; }; IServer server = new WindowsServer(new TestPlayerFactory(), new ConnectionFactory(), serverConfig); var gameConfig = new GameConfiguration(); gameConfig.UseAdapter(server); var game = new MudGame(); game.Configure(gameConfig); Task gameStartTask = game.StartAsync(); gameStartTask.Wait(); } private static void HandleClientConnection(IAsyncResult result) { Socket server = (Socket)result.AsyncState; Socket clientConnection = server.EndAccept(result); // Fetch the next incoming connection. server.BeginAccept(new AsyncCallback(HandleClientConnection), server); // Create player character here. }

In this example, we used both the WindowsServer and it's Socket to completely replace the way incoming connections are handled. We're not replacing how client communication between the server and client are handled (that is planned) but allowing users to define custom server behavior without reimplementing IServer. At the end of the OnServerStartup callback, we set IsHandled to true, which tells the server to stop using its internal startup and rely on the custom logic being defined.

There are more things you can do, such as intercepting the shutdown of the server, client connections, disconnects and more.

Sharing information across adapters

The server publishes out messages that you can intercept and react to as well. An example is this:

static void Main(string[] args) { SetupMessageBrokering(); var serverConfig = new ServerConfiguration(); IServer server = new WindowsServer(new TestPlayerFactory(), new ConnectionFactory(), serverConfig); var gameConfig = new GameConfiguration(); gameConfig.UseAdapter(server); var game = new MudGame(); game.Configure(gameConfig); Task gameStartTask = game.StartAsync(); gameStartTask.Wait(); } static void SetupMessageBrokering() { MessageBrokerFactory.Instance.Subscribe<InfoMessage>( (msg, subscription) => Console.WriteLine(msg.Content)); MessageBrokerFactory.Instance.Subscribe<GameMessage>( (msg, subscription) => Console.WriteLine(msg.Content)); MessageBrokerFactory.Instance.Subscribe<PlayerCreatedMessage>( (msg, sub) => Console.WriteLine("Player connected.")); MessageBrokerFactory.Instance.Subscribe<PlayerDeletionMessage>( (msg, sub) => { Console.WriteLine("Player disconnected."); }); }

The first thing we do is subscribe, via the MessageBroker, to a series of messages that can be published by other objects. In this scenario, the WindowsServer will publish messages that are InfoMessage, PlayerCreatedMessage and PlayerDeletionMessage. The MudGame will publish GameMessage notifications. This looks like this when the server is running and has accepted several connections, and had a few disconnects.

The flexability given now with adapters and their custom configurators will make it easy to get up and running, and still provide you with a lot of flexability when you want to do more advanced things.

As always you can replace the IServer or IServerConfiguration implementations with your own all together. Since IServer inherits from IAdapter your custom implementation can plug straight into the game using the game.UseAdapter(customServer) call.

Handling what is missing

The original implementation shown at the start of this post had some other things being done. It handled the setup of security and commanding. That responsibility will be moved to additional adapters, which will run independent of the server and game. They can subscribe to messages sent from the server and react to them, launching the initial login command and handling security without knowing that the server even exists.

var gameConfig = new GameConfiguration(); gameConfig.UseAdapter(new WindowsServer()); gameConfig.UseAdapter(new CommandManager()); gameConfig.UseAdapter(new SecurityBroker()); gameConfig.UseAdapter(new WorldManager()); var game = new MudGame(); game.Configure(gameConfig); Task gameStartTask = game.StartAsync();

Each one of the adapters shown above have not been written yet; they are coming. When they are ready, they will share the same level of flexability as the server, using configuration objects that you can intercept and interact with.

There is a lot of other new stuff happening in the engine that won't fit into this post, like a new home on GitHub (more on that in a different post), character APIs and real usage documentation.

Localization Support

The included Validation Attributes now all support localization, allowing your failure messages to be presented to the user in the native language for global applications. In order to provide this in a cross-platform manor (iOS, Android and Windows), localization support must be handled with a couple levels of indirection.

Without localization, you would manually specify the FailureMessage like this:

[ValidateObjectHasValue( FailureMessage = "Email address must not be blank.", ValidationMessageType = typeof(ValidationErrorMessage))] public string Email { get { return this.email; } set { this.email = value; this.OnPropertyChanged("Email"); } }

Localization is done by specifying a localization key on your validation rules and omitting the FailureMessage property assignment like the following.

[ValidateObjectHasValue( LocalizationKey = "User-Email-Validation-Failure-Cannot-be-blank", ValidationMessageType = typeof(ValidationErrorMessage))] public string Email { get { return this.email; } set { this.email = value; this.OnPropertyChanged("Email"); } }

When validation is performed, and the Email property is null, a localized failure message will be assigned to the FailureMessage property.

In order to facilitate this, the validation rules fetch an implementation of IValidationLocalizationService from a new Factory, the ValidationLocalizationFactory. The API ships with a Windows App Store supported localization service in the Universal App Shared project.

The factory must provide this service to the validation rules. In order to do that, you must initialize the factory. This is demonstrated in the sample projects as well, in the App.Xaml.cs file.

public App() { this.InitializeComponent(); this.Suspending += this.OnSuspending; ValidationLocalizationFactory.Initialize<ValidationLocalizationService>(); }

The factory is initialized with our Windows App Store version of the localization service included in the sample project. The validation rules will use this service any time that it needs to fetch a localized string.

Another feature of the localization support are fallback messages. While you are developing the application, you often don't have all of the localization done. You can assign a value to both FailureMessage and LocalizationKey. The validation rule will try to fetch a localized string and if none exist, continue to use the specified FailureMessage. If it finds a localized string, it replaces the fallback value with the localized string for you.

The following demonstrates this:

[ValidateObjectHasValue( FailureMessage = "Email address can not be blank.", /* fallback if localization does not exist for the key yet */ LocalizationKey = "User-Email-Validation-Failure-Cannot-be-blank", ValidationMessageType = typeof(ValidationErrorMessage))] public string Email { get { return this.email; } set { this.email = value; this.OnPropertyChanged("Email"); } }

One of the most annoying things with XAML binding in WPF and Windows App Store apps is the need to raise a property changed notification to the user interface. Typically, you would abstract the actual property changed notification in to a base class like this:

public class BindableBase : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; protected void SetProperty<T>(ref T oldValue, T newValue, [CallerMemberName] string property = "") { if (object.Equals(oldValue, newValue)) { return; } oldValue = newValue; this.OnPropertyChanged(property); } protected virtual void OnPropertyChanged(string property) { var eventHandler = this.PropertyChanged; if (eventHandler != null) { eventHandler(this, new PropertyChangedEventArgs(property)); } } }

This at least prevents you from having to implement INotifyPropertyChanged on every one of your models. The issue however is that you still need to raise the event. In order to do so, you would invoke the base class' OnPropertyChanged method.

public class User : BindableBase { private string firstName; private string lastName; public string FirstName { get { return this.firstName; } set { this.SetProperty(ref this.firstName, value); } } public string LastName { get { return this.lastName; } set { this.SetProperty(ref this.lastName, value); } } }

The boiler plate code here gets really monotonous when you have a project with more than a handful of models. Luckily, Roslyn now has Initializer support for Auto-Properties..

With Auto-Property Initializers, we can build a wrapper around the actual property and bind to the value our wrapper holds. To demonstrate, we will create a simple wrapper. There will be a generic and a non-generic flavor. The non-generic provides a static method for constructing a generic wrapper. We will call this wrapper BindableProperty.

Generic Property Wrapper

public class BindableProperty<T> : BindableBase { private T value; public BindableProperty(T value, [CallerMemberName] string propertyName = "") { this.value = value; this.Name = propertyName; } public BindableProperty([CallerMemberName] string propertyName = "") { this.value = default(T); this.Name = propertyName; } public T Value { get { return this.value; } set { this.SetProperty(ref this.value, value); } } public string Name { get; private set; } public static BindableProperty<T> Prepare(T value, [CallerMemberName] string propertyName = "") { return new BindableProperty<T>(value, propertyName); } public static BindableProperty<T> Prepare([CallerMemberName] string propertyName = "") { return new BindableProperty<T>(default(T), propertyName); } }

Non-generic static class for coonstruction

public static class BindableProperty { public static BindableProperty<T> Prepare<T>([CallerMemberName] string propertyName = "") { return new BindableProperty<T>(default(T), propertyName); } }

You can see the BindableProperty object still has a private backing field and a property setter that handles the property changed event. The difference however is that this is the only place this code needs to ever exist now.

With our new BindableProperty object, let's re-write our User.

public class User { public BindableProperty<string> FirstName { get; set; } = BindableProperty.Prepare<string>(); public BindableProperty<string> LastName { get; set; } = BindableProperty.Prepare<string>(); }

We now have properties in our model that can be data-bound to and push change notifications back to the UI. We could even provide an initial value for the properties if we wanted to.

public class User { public BindableProperty<string> FirstName { get; set; } = BindableProperty.Prepare<string>(string.Empty); public BindableProperty<string> LastName { get; set; } = BindableProperty.Prepare<string>("Stevenson"); }

Now we can create a view model real-quick for our view.

public class NewUserViewModel : ICommand { public User NewUser { get; set; } = new User(); public event EventHandler CanExecuteChanged; public bool CanExecute(object parameter) { return true; } public async void Execute(object parameter) { if (string.IsNullOrEmpty(this.NewUser.FirstName.Value) || string.IsNullOrEmpty(this.NewUser.LastName.Value)) { var dlg = new MessageDialog("User information is invalid"); await dlg.ShowAsync(); } } }

In order to execute properly, the FirstName and LastName properties need to have their Value property checked. If the Value property is null, we show a dialog. Having to check the Value property is an extra step that you wouldn't normally need to take, but one extra 'dot' is a lot less than having to write all the OnPropertyChanged boiler plate code.

Now for our view, we just wire up a quick simple user entry form. The TextBoxes are bound to the Value property in each of the User's BindableProperty properties.

<StackPanel> <StackPanel Orientation="Horizontal"> <TextBlock Text="First name" /> <TextBox Text="{Binding Path=NewUser.FirstName.Value}" /> </StackPanel> <StackPanel Orientation="Horizontal"> <TextBlock Text="Last name" /> <TextBox Text="{Binding Path=NewUser.LastName.Valuey}" /> </StackPanel> <Button Command="{Binding }" Content="Create." /> </StackPanel>

If you write a lot of code that takes dependencies in a method or constructor, you'll find that you write a lot of null checking like this:

public DefaultGame(ILoggingService loggingService, IWorldService worldService) { if (loggingService == null) { throw new ArgumentNullException("loggingService", "Logging Service must not be null!"); } else if (worldService == null) { throw new ArgumentNullException("worldService", "World Service must not be null!"); } this.loggingService = loggingService; this.worldService = worldService; }

Depending on the number of dependencies, this tends to bloat methods with more safety checks than actual code. I wanted to resolve this, and did so with a factory.

The factory needed to satisfy a few things.

Instance exceptions

Support stashing custom data in to the exceptions

Only throw if a given condition was met

Allow a callback if the conditions are not met (meaning no exception will be thrown)

Turns out this was pretty easy to implement. The end product, in its simplest form looks like this:

public DefaultGame(ILoggingService loggingService, IWorldService worldService) { ExceptionFactory .ThrowExceptionIf< ArgumentNullException>(loggingService == null); ExceptionFactory .ThrowExceptionIf< ArgumentNullException>(worldService == null); this.loggingService = loggingService; this.worldService = worldService; }

You can also invoke a callback, and provide a custom message.

public DefaultGame(ILoggingService loggingService, IWorldService worldService) { ExceptionFactory .ThrowExceptionIf< ArgumentNullException>(loggingService == null, "Logging Service must not be null!") .ElseDo(() => this.loggingService = loggingService); ExceptionFactory .ThrowExceptionIf< ArgumentNullException>(worldService == null, "World Service must not be null!") .ElseDo(() => this.worldService = worldService); }

If you need to do something more complex with your conditional check, you use a Func< bool>

ExceptionFactory .ThrowExceptionIf< Exception>( () => { this.Worlds = worldService.GetAllWorlds(); return this.Worlds.Any(); }, "An empty world can not be used!"));

It also supports providing a custom exception factory method for use. Since some exceptions have additional parameters in the constructor, this can be really useful.

ExceptionFactory .ThrowExceptionIf< ArgumentNullException>( worldService == null, () => new ArgumentNullException("worldService", "World Service must not be null!"));

We can also pass custom data in to the exception if we want.

ExceptionFactory .ThrowExceptionIf< ArgumentNullException>( worldService == null, () => new ArgumentNullException("worldService", "World Service must not be null!"), new KeyValuePair< string, string>("Member", "DefaultGame"), new KeyValuePair< string, string>("MemberType", "Constructor"));

So how does the insides work? Let's take a look

The Factory

There are a total of four factory methods.

ThrowExceptionIf< TException>(Func< bool> predicate, string message = null, params KeyValuePair< string, string>[] data);

ThrowExceptionIf< TException>(Func< bool> predicate, Func< TException> exception, params KeyValuePair< string, string>[] data)

ThrowExceptionIf< TException>(bool condition, string message = null, params KeyValuePair< string, string>[] data)

ThrowExceptionIf< TException>(bool condition, Func< TException> exception, params KeyValuePair< string, string>[] data)

and one last method for adding data to the exception

AddExceptionData(Exception exception, params KeyValuePair< string, string>[] data)

Since we can build this in an overloaded fashion, we will just build the most complex method out, then let the rest of them piggy back on top of it.

public static ExceptionFactoryResult ThrowExceptionIf< TException>(bool condition, Func< TException> exception, params KeyValuePair< string, string>[] data) where TException : Exception, new() { if (condition) { return new ExceptionFactoryResult(); } TException exceptionToThrow = exception(); AddExceptionData(exceptionToThrow, data); throw exceptionToThrow; }

This method is really straight forward, it requires a bool value to indicate if this exception must be instanced and thrown or not. If the condition is false, then we go ahead and invoke the Func< TException> delegate. This returns the exception that we are to throw.

Next we take the optional exception data parameter and pass it to an AddExceptionData method. That method will iterate over the param data and add it to the exception. We then finally throw the exception. Really straight forward.

The AddExceptionData method looks like this:

public static void AddExceptionData(Exception exception, params KeyValuePair< string, string>[] data) { foreach (var exceptionData in data) { exception.Data.Add(exceptionData.Key, exceptionData.Value); } }

Now we can build out our overloads. The second most complex one is really easy to write. We just pass a delegate in that instances a new exception using the Activator class.

public static ExceptionFactoryResult ThrowExceptionIf< TException>(bool condition, string message = null, params KeyValuePair< string, string>[] data) where TException : Exception, new() { return ThrowExceptionIf< TException>( condition, () => (TException)Activator.CreateInstance(typeof(TException), message), data); }

Next, we will provide support for delegate predicates.

public static ExceptionFactoryResult ThrowExceptionIf< TException>(Func< bool> predicate, Func< TException> exception, params KeyValuePair< string, string>[] data) where TException : Exception, new() { return ThrowExceptionIf< TException>(predicate(), exception, character, data); } public static ExceptionFactoryResult ThrowExceptionIf< TException>(Func< bool> predicate, string message = null, params KeyValuePair< string, string>[] data) where TException : Exception, new() { return ThrowExceptionIf< TException>(predicate(), message, character, data); }

The last thing we need to do is support the method callbacks. This is done using the ExceptionFactoryResult class that all of our factory methods return. This class has nothing more than a simple method that takes an Action and invokes it.

public class ExceptionFactoryResult { public void ElseDo(Action callback) { callback(); } }

Now that I have Mud Designer moved over to Visual Studio Online (VSO) I can start really making use of the Agile platform that VSO is built on top of. Going forward, the project will adopt the Agile methodology, with developing taking place during sprints.

The first sprint started today with three User Stories being brought in to the sprint.

Text File Data Storage Service

Character Security Permissions

Command Security

Text File Data Storage Service

Once this is completed, I will have the first of many data storage services created. The intent is to create a simple data store to use while I build the rest of the engine. I have other Stories for creating SQL and Cloud based services, but those are more complex. While the engine is being developed, I want to just use a simple local data store.

Character Security Permissions

This story contains the meat of the engines security framework. When completed, Permissions can be created and assigned to Roles. There will be a framework constructed for objects that need specific security permissions, to register for them.

Command Security

Pigging backing on top of the Character Security Permissions story, this will allow Commands to register for permissions they require. The engine will ensure that users have the required permissions within their roles before letting them execute the command.

Wrapping up

Since I am the only developer, each sprint is scheduled for 4 weeks, so it will be a bit before this sprint is completed. If the user stories are finished early, I will pull more stories in and continue working until the end of the sprint.

I have been really wanting to use the Visual Studio Online (VSO) service for a while now with Mud Designer. I have been holding back primarily because Mud Designer is open source, while VSO is meant for closed-source team projects. TFS doesn't come with an easy way of maintaining two repositories of the same code-base, while maintaining the version history of the source.

The solution to this was Git, but the Codeplex project was hosted on a TFS instance. I then discovered - (thanks to Richard Banks for answering my Stackoverflow post) - that the Codeplex team could convert my project to a Git repository. I promptly fired them an e-mail and had my project converted.

I have been really wanting to use the Visual Studio Online (VSO) service for a while now with Mud Designer. I have been holding back primarily because Mud Designer is open source, while VSO is meant for closed-source team projects. TFS doesn't come with an easy way of maintaining two repositories of the same code-base, while maintaining the version history of the source.

The solution to this was Git, but the Codeplex project was hosted on a TFS instance. I then discovered - (thanks to Richard Banks for answering amy Stackoverflow post) - that the Codeplex team could convert my project to a Git repository. I promptly fired them an e-mail and had my project converted.

A friend of mine, Michael Cameron, and I have started a podcast called Refactored. Our first episode starts a mini-series on software development environments and their history.

Since there are rumors still going around of a possible 13" iPad Air, I thought a picture showing a 13" Surface Pro 3 would help give some perspective.

I had a bit of free time tonight, so I thought I would put together a quick post on how the overall engine architecture now looks. The following is a diagram showing the engine's major layers.

As shown in the diagram, the application is broken up in to three major layers, not including the apps.

Engine

The Engine layer being the base layer that everything is built on top of and relies on. The engine has a Core project, that is a portable class library. This project contains all of the Types that can be shared across all platforms, including Windows 7, Windows 8, Windows 8 Metro, Windows Phone 8, iOS, Android, Linux and OS X.

The Desktop application project holds the Types that can be shared across desktop applications, with the goal being Windows 7, Windows 8 desktop, Linux and OS X.

The Networking.Portable will eventually be renamed to Default.Mobile, and that will contain Types specific to mobile devices like Windows 8 metro, Windows Phone 8, iOS and Android.

The bulk of the code will be usable across all platforms, which was the biggest challenge. Since I don't have Xamarin licenses, I can't do any testing to see if the code runs as expected on iOS & Android. I should be able to start running tests in OS X over the next month.

Windows Desktop App

This layer is composed of several projects that ultimately make up the Windows Desktop version of the editing tools & server. The actual app will reference an Infrastructure project, which will contain support Types and region definitions. A region is a part of the user interface that can hold a module and ultimately provide support for 3rd party plugins. An example of a region would be that of a menu region, content region or a toolbox region. Regions provide an easy way for 3rd party developers to create modules that plug in to the editor, in the area that they feel it needs to be installed to, with ease.

A modules project is actually another layer by itself, that sits as part of the overall app. There can be an unlimited number of module projects, each providing the actual Views and view models that the app will use. It provides support for 3rd party modules that can be plugged in to the editor at run-time. Modules are used by the editor to provide tools to the end-user for creating their game. Modules are not referenced by anything, allowing them to be freely added and removed without needing to rebuild the toolkit. The modules themselves only reference the infrastructure and shared windows library.

Both the Infrastructure and Modules projects reference a Windows Shared Library project. This project will contain code that can be shared across multiple Windows Desktop apps. Such as the Server, the Editor and a future Web-App. This will contain things such as support classes, Factories and any Facade's that can be shared.

Shared Windows Library

The Shared Windows Library will contain the code needed to set up all of the dependency's, determine what repositories and services are needed and expose them through an interface to the apps. Mostly via Factories.

Windows store Apps

This layer provides the code-base for the Windows metro styled apps. These will require their own views and view models, but should be able to share the same factories and repositories.

Repository

The Repository layer is used to bridge the gap between the App and the data storage medium. There will be two different ways to retrieve objects within the app.

Create a new instance using a Factory in the the Windows Shared Library

Fetch existing objects using a Repository.

The Repository will let the app restore, save and delete objects without the app needing to know what the storage medium is. You can easily replace the default storage mediums with something custom if you want, such as some kind of cloud hosting. The overall framework won't really need to know. There is some set-up that must be done to facilitate this, but that is pretty straight forward and will be saved for another post.

Since the data store is often times platform specific, Repositories provide the app and engine a cross-platform solution to accessing data. They don't need to know what platform they are running on, or where the data is stored. You can also intermix data stores, such as saving player data locally in encrypted files and hosting your world data in the cloud. The repositories take care of putting it all back together.

Repositories are also used for data caching. If one object asks a repository to fetch a collection of every Room in the game, the repository will cache the data fetched from the storage service. The next object that asks for a one or many rooms, will be provided an instance that was previously cached. This saves trips to the data storage, which is often times expensive from a performance stand-point to do.

Note that a Desktop and a Portable Repository project is shown only to demonstrate that you could have a repository per platform if needed. Since different platforms might require different caching techniques. When the engine ships, the goal is to only ship a Repository layer that is not broken down in to Desktop and Portable. I want that to take place at the Service layer and allow the engine and all apps to share the same Repositories.

Services

While the Repostories are meant to let objects access data without knowing where it is stored, the Services layer must communicate directly with the stored data. This layer is what performs the communication with any storage servers, deserialization of xml files, encryption and data transformation. An object can be transformed to fit in to a specific data structure for saving, and then transformed back in to the object it came from when loaded later.

Finally

This set up has provided the engine with a nice level of abstraction and layering. All of the core components in each layer are hidden behind interfaces, so 3rd party developers may customize or replace pieces within each layer as needed.

This post only showed the Windows Apps. Adding other platforms would only require a new project for each platform, such as OS X, with views, view models and any platform specific support. Once the overall product is finished, adding support for other platforms should be a relatively simple endeavor.

Tonight I was able to finally get a world clock built in to the Mud Designer engine. The world clock is pretty flexible, allowing users to specify how many real-world hours pass before 1 in-game day is completed. The engine then does a break down and broadcasts updates every in-game minute.

Time of day states

If you set your in-game to real-world hour ratio to 4:24, then the update event will get called every 10 seconds. This means that 1 in-game minute will pass every 10 seconds. If the ratio is to low, the engine will switch over and broadcast updates every in-game hour instead, to prevent stress on the server.

The engine uses an ITimeOfDayState implementation to determine what the current time of day is. It holds a collection of these objects and transitions between the different times of day as needed. The ITimeOfDayState objects have a StartTime property that tells the engine when it needs to transition to the state. This allows users to create their own time of days, such as Evening and LateNight, and let the engine handle moving between the states.

Building a time of day state is really simple. You can just inherit from it's parent class like this:

public class AfternoonState : TimeOfDayState { public AfternoonState() { this.StateStartTime = new TimeOfDay(); this.StateStartTime.Hour = 12; } public override string Name { get { return "Afternoon"; } } public override TimeOfDay StateStartTime { get; set; }

You can of course choose to implement a state from ITimeOfDayState, but by inheriting from the abstract TimeOfDayState class, the time of day engine clock will be managed for you, along with the in-game to real-world time conversions.

The engine's IWorld implementation is notified every in-game minute that goes by (or hour if the frequency is to low). When the world is notified, it updates itself accordingly, and checks to see if the state needs to be changed. If so, it transitions the states and posts it's own event that notifies registered objects that a state change took place. This allows developers to publish messages to the users when the time of day changes.

The Engine Timer

Since the engine is being built with full cross-platform support via Portable Class Libraries, I ran in to an issue with the .NET built-in thread-safe Timer class missing. After doing some searching around, it seems that Microsoft did include it in their Portable Class Library profile, but Xamarin has not. Since I am targeting iOS and Android as well, I loose out on the classes Microsoft includes in their latest profiles, until Xamarin updates their profiles.

In order to work around this, I built a custom Timer for the engine, called EngineTimer. It's pretty simple to use and looks like this.

var worldClock = new EngineTimer<IWorld data-preserve-html-node="true">((stateData, clock) => DoSomething(), this); worldClock.Start(startDelay: 0, interval: 5000);

I had mentioned a couple of times that I would be refactoring the current engine re-write using the NDepend statically analysis tool. I performed an initial analysis last night and reviewed the report and started to dig in. Some of the issues that I ran in to were really simple to fix. Let's start with those first.

Avoid unsealed attributes

Microsoft's MSDN states that for performance reasons, you should avoid unsealed attributes whenever possible. Considering that the engine's built-in validation mechanics are built off of attributes, I want to make sure and grab any performance increase that I can get.

I started out with an existing Fixture model that I created during development. The model is really simple and includes three properties, each being validated in some manor.

public class ValidatableFixture : ValidatableBase { private const string PasswordConfirmationDelegateName = "ConfirmPasswordsMatch"; public ValidatableFixture() { this.Name = string.Empty; this.Password = string.Empty; this.PasswordConfirmation = string.Empty; } [ValidateValueIsNotNullOrEmpty(ValidationMessageType = typeof(MessageFixture), FailureMessage = "Name must be set.")] public string Name { get; set; } [ValidateValueIsNotNullOrEmpty(ValidationMessageType = typeof(MessageFixture), FailureMessage = "Password must be set.")] [ValidateStringIsGreaterThan(GreaterThanValue = 4, ValidationMessageType = typeof(MessageFixture), FailureMessage = "Password must be greater than 4 characters.")] public string Password { get; set; } [ValidateWithCustomHandler(DelegateName = PasswordConfirmationDelegateName, ValidationMessageType = typeof(MessageFixture), FailureMessage = "Passwords do not match.")] public string PasswordConfirmation { get; set; } [ValidationCustomHandlerDelegate(DelegateName = PasswordConfirmationDelegateName)] public IMessage PasswordConfirmationValidation(IMessage message, PropertyInfo property) { return this.PasswordConfirmation.Equals(this.Password) ? null : message; } }

This fixture contains four total validation rules that will be invoked during the test. The most expensive of the four would be the ValidateWithCustomHandler attribute. Unlike the rest of the validation system, the ValidateWithCustomHandler attribute does not cache the MethodInfo object it fetches via reflection. At the moment, the engine just caches the attributes themselves and their associated properties for re-use across multiple instances. Caching of method delegates will make its way in to the system at some point in the future.

To get started, I wrote a simple unit test that creates 1,000 instances of the ValidatableFixture class and invokes ValidateAll(). The unit test ran through all 1,000 instances, invoking Validate() on each attribute, which caused the attribute validation to take place. In theory, there shouldn't be a huge penalty here due to the caching I am doing. Once the first ValidatableFixture is instanced, the rest of them use the PropertyInfo and ValidationAttribute cache that the first one generated. There won't be any deep walking of the attribute heirarchy.

// Arrange var fixtures = new List<ValidatableFixture data-preserve-html-node="true">(); var watch = new Stopwatch(); for (int index = 0; index < 1000; index++) { var model = new ValidatableFixture(); model.Name = "TestName"; model.Password = "pass"; model.PasswordConfirmation = "pass"; fixtures.Add(model); } // Act watch.Start(); foreach(ValidatableFixture fixture in fixtures) { fixture.ValidateAll(); } watch.Stop(); Debug.WriteLine(watch.Elapsed.TotalMilliseconds);

I ran the test 5 times and ended with an average of 41.3199ms. As you can see, I included the instance set up in the time, since that is where the caching takes place along with the bulk of the GetCustomAttribute< T>() calls.

Finally, I went through and sealed all of the validation classes and re-ran the test. To my surprise, the results ended up be slower than leaving them unsealed, with an average time of 43.3881ms.

I found this to be really interesting, as sealing the class should technically make it faster.

I was finally able to get the Mud Designer in to a usable state over the weekend. It has an improved Telnet server that is completely decoupled from the IGame interface. The only coupling the server has with the engine at the moment is a reference to IPlayer, which I might be able to get rid of at some point down the road.

I thought this would be a good time to run some code analysis on the project and see where it stands. Unfortuantely, the report didn't bring the good news I was hoping to see. Let's take a look at the report.

The project contains 1,270 lines of code (compared to Alpha 2 which had 3,852) along with 89 Types (compared to 152). The Alpha 2 release contained 8 critical rule violations and 828 standard violations. Looking at the numbers for Alpha 3, they're roughly cut in half. I was hoping for the number to be lower, but it's early enough in the re-write that I can address this and lower these numbers. The goal of the re-write is to produce a more reliable code-base that provides greater flexibility and is easier to maintain. Proper patterning, architecture, design and code quality is critical for this. NDepend does an excellent job of identifying the areas that I need to address, and allows me to research and apply code designer philosophies.

One of the things that has greatly improved with the current code base is the Cyclomatic Complexity of the source. The overall average is about the same, but the maximum is down from 74 paths to 23.