In Windows 8 Microsoft made the choice to make the Operating System “Metro First” by replacing the Start Menu with the Start Screen (and starting to move other things). You can still use the Desktop but you get there from a Metro world. The reason for this was so that developers would make Metro apps since otherwise they’d just stick to desktop apps, killing Metro (aka tablets).

In Windows 8.1 they will be bringing back the Start Button, not the Start Menu. While the merits of doing that are debatable I propose a different idea. I say give us a “Desktop First” mode in addition to what we currently have.

“Desktop First” mode would have a Windows 7 like Start Menu with the ability to launch Metro apps. Since you could still use them on Desktop developers would still have reason to make them. Maybe even more since desktop uses will be more likely to get 8 instead of 7 where they can’t run Metro at all!

So you would have these two modes: “Desktop First” for those who are in a none touch environment or just want to use the desktop and “Metro First” for tablets and other environments where the Desktop doesn’t work.

There is a flaw in this I admit. Primarily that if Paul Thurrott is right and Metro is the future than why spend the resources helping the past.

Today I ran into an interesting problem. A controller with two methods that take the same parameters and both should be GETs. After going crazy I decided to try using ActionVerbs attribute to set a method for a custom, made up HTTP method (called REMAINING) and to my shock it worked!

Now I know it isn’t really REST now but to be honest what is? So I say use this!

Well last Sunday my cousin who builds server’s for a living was over and helped me get my server up and running, mostly…
Sadly there’s a slight problem with the onboard SATA adapters so need to get a PCI SATA card but soon I will have my Server 2012 Essential home server setup!

@SimonDarksideJ Has started a very interesting project: Making MonoGame use Portable Class Libraries (PCL) for it’s core functionality (his work can be seen at https://github.com/mono/MonoGame/pull/1583).

For those who don’t know PCLs are code libraries that only reference libraries that are garenteed to be in and work the same in different implementations of .NET (and/or Mono). The idea is compile one DLL and then use it for Windows, Phone, RT, and more. For a more in depth look MSDN has a great section at http://msdn.microsoft.com/en-us/library/gg597391.aspx.

The basic idea for MonoGame is that instead of using the same code file with “#if” all over the place in different projects targeting different platforms code that is that code that is identical is in one PCL that all projects reference. Then each platform project only code that is different is included. Its a very interesting idea and one that I had originally thought about doing for my own MonoGame project. In the end though I didn’t and my reasons from them still stand.

1. When projects need code that’s completely different on top of code functions this can work more often then not its tiny little changes in the middle of functions that are 99% identical between platforms.
2. At least for me I found with PCL I had to create more and more abstractions making code hard to follow and maintain.
3. My last reason was that using Visual Studio and Xamarin Studio’s ability to add a file as a link to the original location means that changes in one platform are easily propagated across platforms.

This doesn’t mean I think PCL is pointless, more that for me at least it wasn’t right and maybe the same is true of MonoGame

Now that Google has killed Google Reader people are wondering what to use instead:

Google Reader is being shut down July 1!?!?!?!?? We need to fix this. There’s no alternative!!!!

— Scott Hanselman (@shanselman) March 13, 2013

We I’m here to offer a solution: Office365 and Outlook. While people may not know this Outlook includes a great RSS reader that I have used for years. An interesting things happens though when Outlook syncs with an Exchange server: If the RSS feeds are stored in the Exchange mailbox then they get synced to. Content and if read or not. Not only that but the feed items can be read from the web and any device that use ActiveSync to get your email from that Exchange server! No need to find if the service has an app for your device. As long as it has ActiveSync support (which most do) you can read them.

Now there is one downside: The Exchange server won’t sync the feeds, you need Outlook for that. But if you have an always on desktop just leave Outlook running…

In .NET and Mono we have this lovely property we can check for when we need to give in and make OS version based changes:

Environment.OSVersion.Version

 Today I went to go use this on my OSX application to work around a bug in MonoGame (https://github.com/mono/MonoGame/issues/1535 for those wondering). The bug is only on Snow Leopard, which is version 10.6. But when I ran that method I got “10.8.0.0” which made no sense. Getting really curious now I ran the same code on my Mountain Lion (10.8) machine and got 12.2.1.0! In looking at that version number I noticed something else: The PlatformID Mono was reporting was Unix! That got me thinking: OSX runs on top of a BSD Unix core so maybe that’s what Mono’s reporting.

After some hunting around online I found http://bit.ly/n8i06 which confirmed my thinking. In short OSX’s core is based on the OS Darwin (A Unix variant) and that’s the version Mono reports.

In my current job one of the big requirements we had was to have a way to upgrade our uses with minimal fuss. After some research I decided to build my own system using Windows Azure and WebAPI. In this first post I’m going to explain what we do and why we do it. In following posts I’ll show some of the code I’ve used (Can’t show the exact code since it’s proprietary).

The update system I build is designed to be quick and simple for both developer and end user.

• Updates are just the files that changed: Users don’t have to re-download the whole program but developers don’t need any fancy tools to create file diffs. A good trade off I think.
• Updating is done by the program it’s self: Only one program to deploy and update.
• Updates are cumulative: Updater logic will update user to most recent no mater how old they are while the developer doesn’t have to do anything special.
• More than one product can be stored in it.
• While I use Windows Azure any hosting plan with a Database and a file storage system will work.

Server

File Storage:

The updates are stored in a combination of SQL Server and Blob Storage. In the database we have two tables. The first stores the updates; their version number, the name of the product it belongs to, and an ID. The second contains a list of files in updates, linked to their update by the updates ID. Each file in the update has both the relative location on the client it belongs in and the location on the web it belongs to. In my implementation the location on the web is a Blob Storage URL.

The files that are uploaded to the server should be separated first by their product and then by the version they belong to. By separating on the version too if a file is uploaded more than once and a problem is found with an update rolling back become much easier. I personally make the path on the server the same as the relative path on the client to help prevent name collisions with files.

WebAPI

 To allow the program to access the server and get updates we use WebAPI. There only needs to be one method in the function that is given the product name and the client’s current version. The method can then search if their are any versions greater than that in the database. If not it can return a 204. If it does find them it can build up a “package” for the client that includes all the changes between it’s version and the most recent. How I do this will be explained later on.

Client

 On the client to check for updates is very simple, we just call the WebAPI control and check the response code. Updating is a bit more complex. In my program I don’t actually update the program till the user exits but there’s no reason you have to wait but if you do not much extra data is sent over the wire since you don’t send the files them selves, just links to where they are on the server (or in blob storage).

When we are doing the actual updating we have to do some interesting tricks to get around two “problems”. The first problem is that you can’t overwrite the programs files while they’re in use. This we solve by using a renaming trick. The bases of the trick is that you can rename a in use file and the write a file with the old name. The second problem is that starting in Windows Vista the “Program Files” folder is write protected unless running with administrative rights. To get around this problem but stay in the goal of self updating we launch a second version of our self with a special command line flag that will request administrative rights. This command line flag tells our program to update and then exit instead of running the normal UI logic.

Once we’re in the “Updater Mode” we can start downloading the updated files to a temporary location. We do this first so if anything goes wrong the program will still work and on next run we can try again. After we have download all the files we then use the rename trick we talked about above to move the updated files.

That’s my updater in a nut shell. In part 2 I’ll start showing some code on how I did this.

(You can get a 90 day free trial for Windows Azure, and yes I get stuff if you use my link but sadly not money)

In general I use the following rules to decide if I’m going to use an Object Literal or a Class for an Object:

1. Is the Object just going to hold data to pass around? Object Literal
2. Is the Object used as a Singleton? Object Literal
3. Is the Object an “Enum”? Object Literal
4. Is the Object going to be created more than once AND has functions? Class

Those cover 99% of JavaScript classes I create, the rest are a case by case decision.

If you like me put links to your twitter handles in your blog’s description linking them to the actual twitter account is annoying. So I created a simple JavaScript to help:

var desc = document.getElementById("description");
desc.innerHTML = desc.innerHTML.replace(/@(\w+)/g,'<a href="http://www.twitter.com/$1">@$1</a>');

One of the big differences between OSX and Windows is that in Windows every window has it’s own menu bar (the place where you find File, Edit, Help, etc.) while on OSX there’s a system controlled one that an application can add their items to. (There are other difference but the only ones that matter for here.) In most OSX applications you configure this from Interface Builder (even in MonoMac) for your windows. In MonoGame though you can’t really do this.

To do this in MonoGame you have to do some things that are very weird and very order dependent.

In you LoadContent Method you must first have the following code:

NSApplication.SharedApplication.Menu = new NSMenu();
var appMenu = new NSMenuItem();
NSApplication.SharedApplication.MainMenu.AddItem(appMenu);
appMenu.Submenu = new NSMenu();

 The code first tells OSX that we will be creating a the menu so we replace the default menu bar with our own. Now even though we have created our own menu bar OSX still adds a default implementation of the application’s menu (the menu that has your applications name). Weirdly instead of allowing you to access it via some method/property and then any new menus you add being created after it the first menu item you add becomes the application menu item and every item after that is added after the application menu. You’ll note that we don’t set a title for the menu anywhere, OSX automatically sets it for us.

To add items to the application menu you add NSMenuItems to appMenu.Submenu like so:

appMenu.Submenu.AddItem(new NSMenuItem("New"));
appMenu.Submenu.AddItem(new NSMenuItem("Open"));
appMenu.Submenu.AddItem(new NSMenuItem("Save"));

If you want to add another menu item to the menu you do:

var appMenu2 = new NSMenuItem();
NSApplication.SharedApplication.MainMenu.AddItem(appMenu2);
appMenu2.Submenu = new NSMenu("SubMenu2");

 And then you add items to it like you did the application’s menu. You may have noticed that you use Submenu to set the name of the menu and it’s sub items. No idea why but you do.

UPDATE

When I posted this I figured adding event handlers would be easy so no need to show how. PS I was wrong.

For starters there are no event or such to listen to, instead you pass in a function of “type” EventHandler as the second argument to NSMenuItem. I would prefer if we could use the more .NET like event system but what can you do.

A more interesting problem arises from the interactions between Mono and the Cocoa Framework underneath. Remember that Objective-C is NOT a Managed language and there is no Garbage Collector to not only collect out of scope object but to also smartly NOT collect objects that are still needed. This effects us in that if your NSMenuItem that you gave a function to so you would be told when it was selected goes out of scope your code will crash because the NSMenuItem was collected by the Mono GC. So if you’re creating the menu’s in a “Menu creator function” like I am, you can solve this problem by creating a member field that is of type LinkedList<NSMenuItem> and adding the NSMenuItems to it. (I use a LinkedList since it has faster appending speed and performance than a List and I don’t need a List’s access speed and performance since I never read the list.)