monotouch

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!

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!

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.

Using AirPlay Mirroring to project your iOS UI to an external screen

Not only does MonoTouch allow you to write iOS apps using the ubiquitous and beautiful C# language, but did you know that it also let you control external peripherals?

Whenever a screen gets connected to your device – whether it’s connected through a cable (like TV-out) or through the wireless network (i.e. through AirPlay), an event is published onto the Notification Center. By listening to that event, you can hook that screen up to your app and start putting interesting things there – anything you’d put on your primary UI!

Before we move on, though, it’s important to understand that we as developers actually have no control over the activation of AirPlay Mirroring. Activation is completely up to the user:

Double-tap the home-button, swipe twice to the left and tap the AirPlay button: Image

in the list of available devices, pick your output device and turn the mirroring switch to on:

Image

As the user flicks the Mirroring switch to on, a notification is placed onto the Notification Centre which we can respond to:

CreateWindow then, you ask? It is responsible for hooking up an UIWindow to the external screen and resize it properly to fit its host. Once you have the window in your possession  you can use it like you’d use the default application window:

If your device is already connected to an external screen prior to executing your application, you can easily hook it up in your AppDelegate’s overload of FinishedLoading:

To incrementally test your multi-screen application, you can use the iOS Simulator’s TV-out feature, which is located at Hardware/TV Out:

Please note, however, that turning on the feature tends to shut your app down, why it’s paramount that you have that hook-up in FinishedLoading.

Have fun!

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!

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]

Book review: Professional iPhone Programming with MonoTouch and .NET/C#

The Professional iPhone Programming with MonoTouch and .NET/C# book, which was first released in 2010, is an excellent starting point for .NET developers wanting to wrap their head around the iOS-stack and really getting started with MonoTouch development.

To quote its introduction,

This book is for .NET developers that are interested in creating native iPhone applications written in .NET/C# … [and] is designed to help you get up to speed with the iPhone, not to really teach you about the .NET Framework or C# language, which we assume you already know.

Since the book presumes that you already know your .NET and C#, it quickly gets you where you want to be, starting you off with a brief product comparison (.NET Framework, Mono and MonoTouch), followed by a walk-through of MonoTouch’s major components and its top-level namespaces.

Chapter 2 introduces you to your prerequisites to start developing, i.e. which SDK:s you need to install in what order, an introduction to MonoDevelop and to Xcode. Now, seeing as the book is a couple of years old by now, you wouldn’t recognise yourself in Xcode (Interface Builder) after reading the introductory chapter. The concepts are the same, though, and the book does a very good job staying on such an altitude that I still feel that its a good read. After you’ve read the introductory chapter, you can supplement your newly acquired knowledge by reading my blog post on XCode and MonoDevelop from a Visual Studio developer’s point of view to get up to speed.

The succeeding two chapters deal with the iOS interfaces, patterns and controls in a digestible manner, showing a lot of code and its result. That goes to say for the entire book, really – it contains a near perfect mix of imagery and code, letting you enjoy the book even when you are far away from your computer. I read this book whilst away on vacation and felt that I learnt a lot without coding a single example during the length of the book.

Chapters 5 and 6 walks us through working with, and displaying, data, teaching us how to access the SQLite database system on the iPhone, connecting to various types of web services and then displaying this data in iPhone’s ubiquitous tables. Here, the author also brings up various strategies for upgrading your data storage during upgrades of your application.

After learning to work with data, chapter 7 introduces us to both iOS’ location and mapping libraries, followed by chapters on application settings, working with the device hardware and its multimedia capabilities.

Chapter 11 teaches us how to integrate with the existing software – such as initiating Skype calls – on the device and also how to integrate with third-party Objective-C libraries (yeah, MonoTouch allows you to do that too!).

Localizing for an International Audience (chapter 11), I found extra interesting as I had recently implemented localization into a Windows Phone 7 application framework and because localization is something often brought up in Sweden, where I live. Not only just showing off the available APIs, this chapter discusses the localization files’ format, various presentation concerns when internationalizing an application and how to utilize .NET’s excellent globalization features to format dates, times, numbers and currencies. After reading this chapter, I got inspired to create a translation community where developers everywhere to help each other localize their apps, simply by crowd-sourcing their localization files. The community is available at localizable.org.

In chapter 13, the book brings up device concerns and which extra controls are available when you are targeting the iPad. It also details how to interpret gestures and how to build an app that works on both the iPhone and the iPad (an universal app).

By this point, the authors hope that you are so comfortable with them, that you will not instantly push the book away on the thought of talking about Objective-C. Thus, chapter 14 attempts to give you just enough knowledge about the native programming APIs to be able to digest code examples found on the internet.

As you have fought your way through chapter 14, the final chapter of the book teaches you all about how the App Store works, and how you submit your apps to it. As a bonus feature, it also brings up how to promote your app, leaving your with a sense completeness.

Summary

I found the book very approachable and a good start for any .NET developer wanting to learn iOS development. It’s almost-perfect balance of descriptive text, code-examples and imagery explaining the concepts, makes it ideal to read away from your computer – for example when you commute, or on your vacation!

 Scroll to top