Development on AxCrypt for Mac is Stalled [Call for Developers]

Whereas the AxCrypt for Windows application is actively maintained by Axantum Software, AxCrypt for Mac – the open-source port – have seen few updates of late, understandably causing some feedback from its small community of users. It is with heavy heart that I today announce that I am dropping this project entirely. I feel that this is for the greater good, since the current situation is not helping anyone.

The project itself is still open-source, and the Windows codebase is well-written and stable, so there is room for someone else to pick up the slack. If you want to contribute, please see the Mac and Windows sources on BitBucket.

To find an alternate encryption software for Mac, please see this list from Lifehacker.

Happy Halloween with #MonoMac

As a part of this year’s Halloween celebration, I was asked by my lovely family to whip together something interesting to show on the TV – a whole lot of nothing followed by a scary image and a accompanying scary sound, maintaining the mood during the party.

Our TV is connected to a Mac Mini, acting as our media center, so what better thing than writing some MonoMac code to usher the holiday along!

I started out by creating a new Mac (open source) – MonoMac Project in Xamarin Studio, then configuring the main window to have a black background and to cover the entire screen:

Then, I had my wife gather a bunch of scary images and sounds, which I put in the Resources folder of my solution. Having an idea, graphics and sounds, it was now time to add a BackgroundWorker to the MainWindowController, showing a random image and playing a random sound at a random interval. Lots of randoms!

So, how do we actually show an image and play a sound, you ask? It’s easy as pumpkin pie!

We have 20ish images in the scary app, so I defined a constant (100 (percent)) that indicated that we should hide the currently showing image and stop the currently playing sound. The soundPlayer is an instance of NSSound, supporting all sorts of audio file formats, including .aiff, .wav and .mp3.

The last bit – the actual image display, is simply an Image Well (NSImageView) for which I created an outlet in XCode. I set its contents like so:

That’s it! With Xamarin, coding for the Mac is a breeze! Check out the full source code at Github and adjust it to your needs. Happy Halloween!

Mobility for companies and organizations

Recently, I visited a lecture, held by Mikael Håkansson at Enfo Zign. The lecture was a part of Microsoft’s Summer Camp series and was held at Microsoft’s offices in Stockholm.

Enterprise Mobility is mainly about processes – large ERP-systems, HR-systems and CR-systems, starts Mikael: It is my experience, that you purchase these systems for the processes they enable/facilitate and then you tweak your organization to fit theses systems.

Traditionally, large ERP systems do not have very intuitive user interfaces (they are largely thick windows clients), why there’s a lot room for improvement as far as clients – consuming or accessing these processes – are concerned.

To discuss the processes some of theses systems provide, let’s investigate the time reporting process: This process starts way before you actually report your hours. First off, someone creates your project and assigns time slots, before you can submit your time. Thereafter, there is usually some form of approval process by a manager.

What we are to discuss today, is Work Order Management.

In Enterprise Mobility, I have found that about 60% of your work load, is performed on the server side.

Some of the challenges you are facing when working with enterprise software, are:
- Format: Line of Business systems have their own formats. If we’re lucky, they are either some form of XML, or have the ability to export data as XML, but XML isn’t optimal either for mobile applications. Whenever possible, we prefer JSON, being a lighter weight protocol and sporting better native support on the various mobile platforms.

- Transport: REST is our preferred transport, since it’s both testable from a browser and easy to consume for our mobile clients.

- Availability: How are going to be able to let an application – running on an arbitrary 3G network – let us access corporate resources behind our firewalls, without compromising the corporate network itself?

- Security: How do we authenticate our users? How do we handle the situation where the employee quits his position, where she has used her own phone, or where an employee’s phone is lost, or get stolen?
A great benefit of using REST, is that it’s so very cacheable – a GET-call can be cashed by all intermediaries, including the client itself, reducing the number of calls to a system and rendering better scalability.

Let’s create a REST service, says Mikael, firing up Visual Studio and creating a new WCF Service Application and simply adding the WebGet attribute (from System.ServiceModel.Web):

(Quick note: The code examples I use in this post, are inspired by the ones Mikael showed, however, they are not the exact same ones. I’ve chosen to keep some of the naming you get with the project templates, for example, to make it easier for you to follow along.)

… and declaring our service in Web.Config, making sure we add a new behavior configuration:

Also, add system.serviceModel.behaviors.endpointBehavior.behavior.webHttp:

By now, your service is accessible from a web browser. The standard format is XML, and you can easily see this – and other formats – by using Fiddler:


By changing the accept header to application/json, your service application will automatically return your data as JSON (because we added the “automaticFormatSelectionEnabled” attribute to our endpoint behavior):


To post data to your service, change the method attribute from WebGet to WebInvoke:

Then, it’s as simple as adding the header “Content-Type: application/json” to post your data with Fiddler:




To solve the challenge of availability, we could put our service on a DMZ and let that service alone access our resources, i.e. effectively drill a hole through our firewall for our service. This easily gets expensive in the long run, as you add more and more services, drilling more and more holes. Another option, is to use a different type of binding – a relay binding – and let Azure tunnel the calls to your service:

Availability Challenge

Through the Windows Azure Service Bus SDK (which is available through NuGet), we get access to the *RelayBindings. After adding your bindings, we can create a public endpoint in the Azure Management portal.

… and then add an additional binding to utilize the service bus as follows:

Azure Service Bus Cost


Now, the Service bus doesn’t have a user database of its own. Instead, it is relying on the Access Control Service to manage identities. So to access our service via the Service Bus, we will have to first visit the ACS and ask it for a valid token for our realm (our service). The token that is returned, we then attach to our service call as an HTTP header:

Introducing the ACS

Federated security

If we have an existing Active Directory that we want to be responsible fo authenticate our users, we need to turn on ADFS, which lets the AD act as a Secure Token Server, issuing tokens in the SAML format (more about that here). Having enabled ADFS, we can now call our on premise AD (through, for example, a relaying service), or our AD in the cloud, ask for a token for our resource (our local service address) and then ask the ACS for a valid token for the service call itself:

With an AD


Quick note: The ACS will remove the authorization header when it calls your service, so if you are relying on claims that you retrieved from your AD (e.g. group memberships), you will need to add the authorization token a second time with another key value (for example “MyAuthorization”). However, this may cause your header to overflow, so be selective of what data you promote.


To let a variety of clients connect to the service backend, Mikael built a client library based on the – recently made portable – HttpClient. See the TokenHelper class in the example code for details.

Having a rigorous backend in place with proper authentication, adding clients is a breeze. Mikael demonstrated an ASP.NET application utilizing the backend, followed by a short demonstration of Xamarin Studio on his wife’s Mac, accessible via TeamViewer. Another option, is developing on a Mac directly (accessing Visual Studio, when needed, through VMWare or Parallels). Using MonoTouch.Dialog, Mikael easily created a declarative UI for the data his service returned. Since Mono (which the Xamarin products are based) is a binary-compatible implementation of the .NET Framework, sharing code between Windows and any Xamarin supported platform, is a breeze.


I enjoyed Mikael’s presentation and learnt a lot with regards to the Azure Service Bus and its relaying capabilities. I still need to dig some into the Active Directory Services and the federated security bit, but after the session, I’m inspired to do so.

Slide deck: SommarKollo – Enterprise Mobility
Code Samples: SommarKollo – Enterprise Mobility – DEMOS



Announcing v1.2 of AxCrypt for iOS!

The fresh from the oven – and still open-sourced – version 1.2 of AxCrypt for iOS feature separate listings of Received and Transferred documents and better utilization of the larger screens of iPhone 5 and iPads. It also invites the user to send feedback straight from the app and provides additional online resources through its main interface. Being more protective of the user’s information, AxCrypt for iOS now closes its document if you leave the app for whatever reason (say, you get a phone call). Last, but not least, the app should be more stable than ever, having both its file management and resource management looked at a little extra.

Click to go to the source file

v1.2 MainWindowController on an iPhone 5

Click to go to the source file

v1.2 FileListingViewController on an iPhone 5

Click to go to source

v1.2 MainViewController on an iPad


In this version of AxCrypt, I replaced my home made progress indicator with the excellent BTProgressHUD from Nic Wise. The Xamarin Component Store made it really easy to browse and locate the component, and putting it into my solution, was a breeze:

I also added the progress HUD to my new WebViewController, complementing the iOS’ Network Activity Indicator. As an extra bonus, if something were to go wrong, the HUD provides a nice ShowErrorWithStatus method, letting the user know what’s going on.

Separation of Concerns

Attempting to make the solution easier to manage, I broke out a lot of functionality from the AppViewController, creating the Theme class (more on that below) and the FileListingViewController, moving the flow control from the view controller to the AppDelegate, where it belongs. The result of this refactoring, was that the AppDelegate now gives you a very nice overview of what the app does, delegating control to various controllers through its application flow. I also broke out the decryption logic out of the PassphraseViewController and into its own DecryptionViewController, reducing the PassphraseViewController to, simply, PassphraseController.


As I touched on above, I broke out the shared appearance logic in this version out of the MainViewController and into a separate Theme class, coupled with two new MonoTouch.Dialog Elements – ThemedFileElement and ThemedStringElement, both delegating their cell rendering to methods in Theme. This allowed me to get an overview of all theming related code, and helped me decouple the various ViewControllers further (since their Views should match the main view without being dependent on it).

For the full set of commits, see this listing.

I hope you enjoy the new version and that you find it helpful!


Personal highlights from Xamarin Evolve

Xamarin Evolve was undoubtedly a hit and I wish I could’ve been there in person to enjoy it all. Doing the next best thing, however, I have managed to chew through quite a bit of the material Xamarin has made available from the conference. Below, is my curated list of must-see sessions.

First things first: The keynote, outlining the various advancements Xamarin have accomplished, is – of course – worth your time. Here, Miguel shows us the new integrated iOS UI designer in Xamarin Studio, tells us about C# 5 support and also drops the F# bomb. Nat continues by showing off Test Cloud. Watch it now ;-)

The other three general (or broad-reaching) sessions – How C# Saved my Marriage …, Multiplatformism: Lessons learned … and Buttons are a Hack were all good sessions too. Scott reminded us in his talk, that we can use C# for everything these days, making us feel good about ourselves. Andrew continued by giving us insights in how they ported their game (and why) to multiple platforms, and what in it took the bulk of their time. Very interesting! Josh then, told us that skeuomorphism is okay, if we take it far enough. Don’t do things half-assed, basically? Judge for yourself – it was a good talk!

Getting the Most from Xamarin Studio contained a lot of nice tips and tricks, teaching me what the quick search actually does (CMD+. on Mac, CTRL+, on Windows), walking through the built-in quick fixes (ALT+Enter), and teaching me how to turn on solution-wide source-code analysis. Awesome!

Intro to Calabash blew my mind! I found they way you are able to completely interact with your compiled app through code (i.e. automation) extremely cool! This is the technology that powers Xamarin’s Test Cloud, by the way.

Another super-interesting talk, was Sharing up to 80% code for iOS, Android and Windows platforms, a retail app case study. Sharing the actual experiences and lessons learned, and taking part of decisions that was made and their outcome, was invaluable! The two guys presenting, also had another talk with an equally long name - Create a uniform login experience with a centralized cloud authentication system. As their previous talk, this one was very interesting. However! I discourage you from listening to them both right after one another, since they are both very rich in information and slightly overlapping, easily bruising your brain. Instead, interleave the talks with something feel-goody, like Scott’s talk about C#. ;-)

Maximizing code-sharing with Xamarin.Mobile was nice to skim-through if you already knew about its existence. If not, lean back and enjoy this one as well.

Designing experiences for the iPad was a little long-winded, but then – I’m not a designer. That said, it was interesting to hear about the design process as opposed to the skewed view that designs come up out of nowhere.

Crafting interactions with Core Animation, also a little long-winded (sense a theme?), but contained some very valuable information about how UIKit works as far as layout, layers and animations work. Does a UIView render it’s content? Does a UILayer accept user input? What’s a PresentationLayer? Find out here.

Fast UI Creation with MonoTouch.Dialog was pure gold. I’m a big fan of MonoTouch.Dialog, and often-times, this is the first thing I show off when introducing a developer to MonoTouch Xamarin.iOS for the first time, due to its simple, declarative, nature.

I have yet to see all sessions, so this list is likely to be updated. Which was your favourite session? Let me know in the comments!

Announcing version of AxCrypt for Mac

After 1375 downloads and a slow increase of support e-mails and ideas, it was definitely time to address some outstanding issues and pour some love onto the application. Version of AxCrypt for Mac is all about integration with the underlying system. To quote from the version history:

    • .axx files should now be automatically registered with the system and get the shield icon as start AxCrypt from your Applications folder. However, the integration is more than skin-deep: It’s now possible to double-click on .axx files on your system to have them automatically opened with AxCrypt! Just as with the QuickView/Edit command, you can edit your document and have it re-encrypted as you quit out of your associated editor.
  • Thank you to for using AxCrypt for Mac! I’m in hopes that the updates in this version will make your workflow easier!
  • Download here. (Requires a Mono Runtime)
  • Getting “The operation couldn’t be completed. (OSStatus error -67053.)”? See this comment.

Building cross-platform mobile applications in Visual Studio, using Xamarin and Azure Mobile Services

For a recent presentation, I developed a ninja locator app, where I demonstrated how to achieve code-reuse and write cross-platform applications in Visual Studio, using Xamarin’s offerings and Microsoft’s Azure Mobile Services. The demo features two applications – one iOS app and one app for Windows Phone 8.

As the user starts either of the apps, they are presented with an option to log into their favourite login provider, whereafter they’re able to share their geographical position with a selected group of friends, thus enabling them to keep track of each other when travelling together, or – in our scenario – keeping track of your fellow consultant colleagues as they roam the streets:

Screenshot_3_24_13_7_52_PM Screenshot_3_24_13_7_53_PM Screenshot_3_24_13_7_54_PM

Screenshot_3_24_13_8_06_PM Screenshot_3_24_13_8_45_PM Screenshot_3_24_13_9_01_PM

When building cross-platform applications, one’s dependency graph is of paramount importance. Luckily, this gets easier all the time, with Portable Class Libraries (PCL) getting a wide-spread adoption. In a cross-platform application, you’ll want as much code as possible in one or several PCLs, creating suitable abstractions for native calls as needed.

In our particular scenario, I achieve code reuse in two ways: First, I’m relying on Azure Mobile Services and am using their client libraries to access their services. The client libraries are available both for Windows Phone and – through Xamarin’s Component Store – for iOS and Android. Secondly, I’ve created a Portable Class Library that contains all interaction with said client library, thus having the Business Logic of this application in one spot. Let’s take a look at the solution explorer in Visual Studio:



The solution features five projects – a core project with the shared business logic, a library each for the native implementations (I’ll get back to that later), and a native binary per platform. For the core library, I chose to create a PCL to ensure that I didn’t take dependencies on libraries that were not supported across the board. I configured the PCL like so:



… basically picking the top-tier targets, but excluding Xbox (since that severely limits your available APIs as outlined here).

<< Secret dev. challenge!! Writing this blog entry, I identified a number of logical errors/inconsistencies. But instead of fixing them, I thought I’d make a competition out of it! See if you can find them and point them out in the comments! >>

In the core library, I have a set of classes, containing shared logic:
- Configuration: Contains static application settings, such as the Mobile Services Url, its Application Key, shared color settings etc.
- UIDefinitions: Abstract class that utilizes the Configuration to relay native color objects: 
- Ninja: The single model class in this project defining a trackable resource.
- IMobileServiceTable: An abstraction over the MobileServiceTable class provided by the Azure Mobile Services Client API:
- ServiceClient: Our Azure Mobile Services interface. This client contains the shared logic we want to execute on each platform, but is kept abstract so that each platform can provide its own implementation of the Azure Mobile Services client API:

Looking at the Service Client, we see that it offers four extension points: Initialize, two versions of LoginAsync (one for the initial login, and one for repeated logins (“keep me logged in”-scenarios)) and a GetTable method that returns an IMobileServiceTable<T>. Using these extension points, the Service Client can successfully orchestrate its business logic and provide one asynchronous method that:
1) Initializes the native client API
2) Log into the Mobile Service through a selected provider
3) Perform a read operation (more on that later)
4) Perform a write operation (again, more in a bit)
5) Perform a callback, passing the list of fetched records.

Using these abstractions, I ensure that the core library is not dependent on anything else than what the core .NET libraries provide me. It’s worth pointing out that – at the time of writing this demo – a PCL version of AMS was not available. It is now, however that doesn’t help this particular scenario much, since we still need to compile our code with separate compilers.

So, why do we just read the entire ninja table from the service and then insert an arbitrary Ninja entity? Well, let me start off by saying that there’s more going on than meets the eye. An Azure Mobile Service is a service endpoint which act as an intermediary to the data we have chosen to store in the cloud. As such, we can intercept calls to its operations to make it act more like a service. Starting with the read operation, it is defined as such:

As can be seen above, the read operation only selects the entities whose group correspond to the requesting ninja’s group, thus enforcing the business rule that a ninja only are able to see ninjas in its own group.

Similarly, the write operation does more than just inserting an entry: .

The insert operation first adds a LastSeen field to the entry being inserted, that could be used for later housekeeping (removing all ninjas that haven’t been seen for a month or what-not). Then, it modifies the given group name, ensuring it’s always stored in upper-case (to make things easier for the select operation). Finally, if a ninja entry with the given user id already exists in the table, it is updated, rather than inserted anew.

OK, back to the world of C#!

How do we implement the ServiceClient and the UIDefinitions? I have chosen to implement the shared code into platform-specific libraries so that my native clients doesn’t have to worry about any details, but instead can focus on their user interface and interaction logic. Also, I have chosen to create links between the core library’s source file and the native libraries instead of binary references. This is because – although I have no external dependencies – the iOS-library (and app) still needs to be built using the MonoTouch/Xamarin.iOS toolchain. However, creating these links is easy and provides you with the same value, as far as code reuse is concerned, as a binary reference. You, simply, create a folder in your project (calling it “Core” in this case), right-click on it and choose to Add – Existing item and then create a link to your source file:




Adding a link means that there is only one source file in your project, but you have two entry points for them. In our case, it means that we can refer to pre-written code in our libraries. If you prefer, you can also ALT-drag files from one project to another, which creates the same links.

Back to the native implementations:

Starting off with the Windows Phone implementation of UIDefinitions, we can see, that all it does, is to simply convert its’ base class RGB-values to a Color instance:

Unsurprisingly, the iOS counter part does the same, but for Cocoa Touch:

Not much code in either of these, but that is also the main idea – the bulk of the code should reside in the core library, so that you – in essence – have one code base that you are able to test with one set of unit tests.

Moving on to the service client implementations, we see that they – too – are kept thin; basically being a wrapper around the Azure Mobile Services native client API:  

Although the mostly consist of similar code, note that how we in the iOS library need to pass a View Controller whose View is currently visible to the client API when we are calling the Login methods, so that the client library can properly display the required UI to the user.

The GetTable methods of the ServiceClient returns an IMobileServiceTable<T>. It is defined as such for Windows Phone:

… and as such for iOS: .

That’s it! Now, all we have to do, is to consume our respective libraries in our apps. Both the native libraries (NinjaLocator.WindowsPhone.Core and NinjaLocator.iOS.Core) and the apps themselves (NinjaLocator.WindowsPhone and NinjaLocator.iOS) both reference the Azure Mobile Services client library. In the case of Windows Phone, it was added using Nuget:



And in the case of iOS, it was added using Xamarin’s new Component Store:


Using the libraries we’ve written is as easy as setting the login provider, passing a constructed Ninja entity and then acting on the result set. In the Windows Phone case, we choose to utilize our library as a response to the user navigating to the Page featuring our map control: . We also bind the the foreground color of our Title styles to NinjaLocator.Core.UIDefinitions.ForegroundColor: 

Similarly, in the iOS case, we call on our library to retrieve graphics directives and to invoke the service client:

I hope this gives you an idea of how to think when writing cross-platform applications!

Microsoft joins Xamarin Evolve as Sole Platinum Sponsor

Something that has eluded many, is that there is actually an active cooperation between Xamarin – makers of MonoTouch and Mono for Android – and Microsoft. Some has felt, that the Xamarin initiative is a pure indie movement – something you cannot use in a commercial environment for some reason or another. Because of this, I was delighted to hear, that Microsoft is officially sponsoring Xamarin’s first worldwide developer conference – the Xamarin Evolve – that will take place Austin, Texas on April 14th 17th, 2013.

The fact of the matter is, that Xamarin and Microsoft has worked very closely together for the past year, to ensure the success of the .NET developer community. Partnering with the Visual Studio division and the Azure Mobile Services group, Xamarin was able to ship support for Android development in Visual Studio on launch day and ensure that the Azure Mobile Services worked on Xamarin’s supported platforms as well.

Adding to that, Xamarin’s latest announcement of extended support for iOS development in Visual Studio significantly lowers the barrier of entry for Windows developers that are already savvy in the mobile sphere, perhaps from having puttered with Windows Phone.

To quote Nat Friedman: “Together, Xamarin and Microsoft bring C# to 2.2 billion devices”. As a .NET developer, this is amazing! Your skills are current and valuable. Now, get coding!

You’re running out of excuses …

It has finally happened! Earlier today, Xamarin released Xamarin.iOS (formerly known as MonoTouch), supporting iOS development in Visual Studio 2010 and 2012! Letting you utilize a Mac on your local network as a build server and execution engine, Xamarin did the impossible and allowed for Windows to be a highly potent iOS development platform – something that was previously just out-of-reach, and something I know many of you have yearned for! If you’re sporting a Mac with virutalization software such as Parallells or VMWare, things get even easier! Installing the Xamarin Studio package (which in turn installs everything else you’d possibly need (thank you Xamarin!)) on both OSX and on Windows (through VMWare), developing iOS apps in Visual Studio 2012 is a breeze:




So, in essence, starting from today, you can add Visual Studio, ReSharper (I’m being presumptuous here, I know) & Nuget to your iOS toolset. Furthermore, managing your sources in an existing TFS infrastructure, should be dead-simple. Also, Xamarin is introducing its component store with this release, enabling you to purchase and install cross-platform components directly into your project! Early components include Microsoft’s Azure Mobile Services, Facebook authentication and much, much more:


So Windows developers? It’s time to broaden your skills and to learn a new platform! The red carpet has been rolled out. All you need to do, is to get onboard ;-) .

A sleeve of interesting articles

I’ve shamelessly added a sleeve of links from the most-recent Xamarin newsletter to the interesting articles menu on the site, but since I know many of you use RSS readers to consume this content, I thought I’d point them out in a post as well:


1 2 3  Scroll to top