mono

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.

Theming

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!

 

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:

Screenshot_3_30_13_9_43_AM-4

 

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:

Screenshot_3_30_13_10_02_AM-2

 

… 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:

Screenshot_3_30_13_10_44_AM

Screenshot_3_30_13_10_42_AM-2

 

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:

Screenshot_3_30_13_7_49_PM

 

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

Screenshot_3_30_13_7_54_PM

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!

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:

Enjoy!

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?

Image

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!

Learning things the hard way: ZIP your contributions, and the value of feedback

Last month, we were proud to announce AxCrypt for Mac, enabling the world for the first time to open – and create – .axx files on their Macs. However, it seems like some (all?) of you who have tried to actually use the program, have run into issues! Luckily for us, one user gave it more than a glance, and sent us feedback of his experiences, opening our eyes to the fact that something was wrong.

When our user, David, tried to run the app on his Mac, he got an error, saying “You can’t open the application “AxCrypt” because the Classic environment is no longer supported.”

As it turned out, the Mac stores information outside an .app-file itself, so by publishing the .app-file to a website (enabling others to download it), we actually stripped it of some of its information, effectively rendering it useless. With feedback, and the power of internet, however, we were able to rectify this by wrapping the .app-file into a ZIP container and re-publish it.

Thank you, David, for your feedback, and thank you, Rob Keniger at stackoverflow for identifying what was actually wrong.

The link in the article has now been updated.

Introducing AxCrypt for iOS!

It’s finally published! AxCrypt for iOS marks the third platform for the AxCrypt software, now ranging from the Windows Desktop to the Mac and now to iPhones, iPod Touches and iPads! So what does AxCrypt for iOS bring to the table? It lets you decrypt and consume confidential information on the go! Integrating with the host operating system, AxCrypt lets you receive encrypted documents, presentations and images via the built-in Mail app and then unlock and view these files right on your device!

AxCrypt for iOS is based on the same source code as the upcoming version 2.x for Windows, and is written using Mono – the open-source, cross-platform implementation of .NET – with the additional MonoTouch SDK. For usage information, please see the App’s Help & Support page, or watch the app in action below:

[youtube=http://www.youtube.com/watch?v=NrkpF68EIF0]

The app is available today on the iTunes App Store.

Book review: Learning MonoTouch – A Hands-On Guide to Building iOS Application with C# and .NET

Having worked with MonoTouch since the first private beta and now actively working as a part of the Xamarin documentation team, Michael Bluestein (blog, twitter, github) is in a great position of authoring this book. Michael was working on the iPhone platform before MonoTouch came around, a fact that shines-through a bit throughout the book, where he can offer us more insights into the underlying platform than previous literature I’ve read.

Starting out with a walk-through of how to get your development environment set up, Mike guides us through creating a basic MonoTouch app. He is good about pointing out what happens beneath the scenes too, giving us insight into what a .XIB file really is, how MonoTouch binds to the controls you lay out in Interface Builder (Xcode) and how to access the underlying fields, if needed be – all in the first chapter of the book!

In chapter 2 - iOS SDK via MonoTouch – Mike gives us the big picture of the iOS SDK, outlining its various components. Beyond that, he also compares the Objective-C and MonoTouch APIs, throwing the reader head-first into the deep-end, something that was left for the last chapter in the previous book I read. Now, this isn’t necessarilly a bad thing – you get hints of how to interoperate with the underlying API – but it would probably make more sense if you had an iOS background. What Mike succeeds in doing, however, is giving you a sense that Objective-C and C# isn’t that different – there are quirks, but there is still a common inheritance.

Chapter 3 walks us through the Model-View-Controller design pattern, which has heavily influenced the iOS (and OSX) SDK API design. Containing a lot of useful information, the chapter is very focused on the available tools – namely Interface Builder (Xcode) – which, unfortunately, has changed substantially since the book was released. Again, though, Mike is good about showing us what happens beneath the veneer, giving us a deeper understanding of how things really work. This chapter contains a fun code example that uses the onboard sensors – making our studies more attached to the real world – and finishes up with explaining how to create your own UIView (like a User-Drawn Control in Windows Forms) and interacting with touch events.

I really liked the book’s fourth chapter - Common iOS Classes – as Mike not only went through a bulk of the available controls (ViewControllers), but also showed how to customise a lot of them to your liking!

Following a chapter with a bulk of the available controls, chapter 5 focuses on tables and navigation – essential bits in any iOS application.

In chapter 6 - Graphics and Animation – we get introduced to Quartz2D and the fundamentals of drawing lines, figures, images and PDF files. As an added bonus, we get a gem in how to attaching a dynamically created PDF document to an outgoing e-mail. The chapter finishes up by introducing Core Animation, which you can get a glimpse of in this video:

[youtube=http://www.youtube.com/watch?v=6JePwHjVj6U&feature=plcp]

 

Chapter 7 introduces us to Core Location, but also gives us valuable insight into the Significant Location Changes API and the Region Monitoring API, making it highly valuable chapter, even if you’ve read about Core Location before.

After we have learned all about location monitoring, chapter 8 tells us about MapKit, including how to draw annotations (like drop pins) and custom overlays.

Connecting to Web Services is what chapter 9 is all about, doing a good job highlighting the different options available and also containing a nice discussion of when to use the .NET networking APIs contra the CocoaTouch HTTP classes. In the examples, the REST-based API calls are executed against Bing’s search API, making it feel like we are building something real. There are examples of having Bing return both XML (which is parsed with XmlDocument and LINQ-to-XML) and JSON (using System.Json). After walking through REST (being the preferred method whenever possible), we learn about Consuming SOAP-based Web Services using .NET 2.0 client proxies, followed by a section on WCF.

Chapter 10 was another great chapter, offering insights into the Bonjour networking services available on the iOS devices, including GameKit.

In chapter 11, we learn about the various storage APIs we have to our disposal, including SQLite, .NET serialisation against the file system and the application settings APIs.

As the final chapter, iPad Development tells us how to port our iPhone application to the iPad and which extra controls we have available on the bigger screen.

Summary

In summary, I found this book to be slightly harder to penetrate than the previous one I read, but on the flip side, I felt that this book contained more information. The book contains some highly valuable gems (ch 4, 7, 9, 10), which alone makes it worthwhile. As such, I can highly recommend it!

Introducing AxCrypt for Mac!

AxCrypt is a leading open source file encryption software for Windows, having more than 2.6m registered users worldwide. Using file-level encryption, AxCrypt is an ideal choice for attaching encrypted documents to your e-mails or for storing files onto your USB drives, for example.

As the Mac OSX is gaining in popularity, it’s getting increasingly more likely that AxCrypt’s users would like to be able to access their encrypted files from the MacBook or iMac too, which is what today’s good news is all about!

Using Mono & MonoMac, we have – in cooperation with Axantum – built an AxCrypt application that runs on your Mac! Being built from the same source as the upcoming 2.x version for Windows, it’s 100% compatible with your existing files, which means that you can start using it today.

The application was developed and tested on Mac OS X Mountain Lion and requires the Mono Runtime to execute. We are looking into bundling the necessary runtime into the app, but unfortunately, at the moment, the current toolset is giving us headaches.

As its older sibling, AxCrypt for Mac is open source.

Download app [Updated May 21st, 2013 to v2.0.2.0 - (read more about the latest version)]

Semantic Zoom in iOS

One of the exiting new developer opportunities in Windows 8, is the semantic zoom UI design pattern.

As outlined in the Guidelines for Semantic Zoom,

Semantic Zoom is a touch-optimized technique used by Windows Store apps in Windows 8 for presenting and navigating large sets of related data or content within a single view …

To further borrow from the guidelines, this is what a Messages application could look like:

Now, if we were to do something similar in an iOS-app, we could do something like this:

  1. Create a UIViewController whose View is a UIScrollView.
  2. Configure the scroll view with a small zoom threshold, letting the zoom events swap views.

Not so bad, huh? Let’s start with creating a new Solution in MonoDevelop:

As stated in our checklist above, we will start out by creating a root view controller that inherits UIViewController and whose View is a UIScrollView. First up: Creating the controller:

To set the ViewController’s view to a UIScrollView, double-click on the SemanticZoomViewController.xib file it in your Solution Pad to open it in Xcode and then head over to the Identity inspector to set its class to UIScrollView:

Having done that, we can return to MonoDevelop to create our example views. We need an overview and a details view. Now, these views are to here to illustrate this example, so I won’t go into details on them (and, in all honestly, they don’t do much). Let’s start with the overview:

Add -> New File -> iPad View Controller -> OverviewViewController:

Add -> New File -> iPad View Controller -> DetailViewController:

With our SemanticZoomViewController and our two child controllers, we can start binding them together. Returning to MonoDevelop, let us open the SemanticViewController and add a few private fields:

 

Then, with our fields in place, we can do our magic in the ViewDidLoad method:

 

 

 

The code in ViewDidLoad uses a few helper methods to get its job done:

 

 

Now, to swap in the new view, we bring it to front, reset its zoom scale (since we don’t want optical zoom) and animate its opacity to get a nice fade-in effect:

 

And that, my friends, is all that is to it.

For a quick demonstration, see my Youtube clip:

[youtube=http://www.youtube.com/watch?v=5QvRaPbyH3s]

1 2  Scroll to top