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



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!

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!

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:


AxCrypt for iOS, v1.1, is now available on the App Store! #monotouch #tretton37

Thanks to our friends at Apple, the 1.1 version of AxCrypt for iOS is now available, two weeks ahead of schedule!

The new version, empowers the 1.0 release by adding functionality to distribute the files you decrypt to other apps on your device. What does this mean? It essentially means, that you can e-mail documents you’ve received and decrypted, save photos to your camera roll, upload files to your cloud provider of choice and more!

On an iPhone 4s, for example, having a multitude of other apps installed, I can open a decrypted image in both Evernote and Skitch, attach it to a tweet or post it on Facebook:


With version 1.1 out the door, we’ve taken one step closer to offer a complete personal cryptography solution on your device.

Stay posted for updates!

Here, are the latest screen shots, taken from an iPhone 4s:








The Mac is now a first-class .NET platform! #mono #monomac

Yesterday, Xamarin published a new one-hour seminar, outlining the why and how of their fairly recent Xamarin.Mac product.

Xamarin.Mac enables .NET developers to re-use much of their existing skill-set to produce Mac App Store-ready applications in C#, thus complementing their previous offerings in the iOS and Android space.

The goal of the the new product, is to give C# developers all of the functionality in Apple’s Objective-C libraries plus access to the complete .NET framework, resulting in an impressive API surface!

What’s in the box?


If you have previous experience with MonoTouch, you will find that a lot of the classes above are those you have previously worked with, which enables an impressive amount of code-reuse!

How does it work?

Similar in spirit to what Microsoft has done with Windows RT, Xamarin we have created language bindings for (or “projected”, in a sense) the Apple Objective-C APIs to C#. As such, they have built a system where they can continually translate iOS APIs to .NET, enabling access to both Apple-provided APIs as well as third-party libraries.

Xamarin.Mac builds independent applications that have no dependencies on Mono being installed on the target platform. Just like their previous offerings, they intelligently strip out unnecessary code, creating a minimal package that only contains the classes are used. This is a big deal and a practice that is brought in from their iOS and Android platforms.

More information

Celebrating nearly 600 downloads of AxCrypt for iOS!

Since our initial release in November, nearly 600 customer have downloaded and installed our app on their iOS devices! We have also started to receive feature requests, prompting this post.

What’s next?

We are currently working on better integration with iOS for files that you have decrypted, enabling you to save pictures to your camera roll and opening documents in another app installed on your device. Estimating to publish during the week starting with January 14th, you will hopefully be able to download the update during early February.

Looking further on our roadmap (stick around!), we are looking into making it possible to use AxCrypt on your device to encrypt existing documents.

Thank you for using AxCrypt for iOS!

1 2  Scroll to top