January 27, 2015 9:28 GMT

Crazy start of 2015. M.Sc., MVP and new apartment++

End of 2014 and this month have been a very busy time for me. I have been working very hard on finishing up my Masters Thesis, "Environmental Sensor Monitoring tablet application designed using cross-platform design patterns and frameworks", which in short terms concerns creating cross-platform applications using C#, Windows 8.1 SDK and the Xamarin SDK, using some design patterns and frameworks which help sharing code across the targeted platforms. The thesis was handed in the 19th of January and defended today 27th of January. I managed to get an A for the project, which I am super happy about.

Brüel & Kjær which I made the thesis in collaboration with and where I have been working part time the past 3.5 years also offered me a more permanent position last year, which I have accepted, which means I am starting full time from February, continuing creating cross-platform apps using Xamarin.

Alongside the thesis, I've been in the middle of buying an apartment, which is almost settled now. So the plan is that I am going to move 1st of March, which is going to be great. Right now I am living in a small dorm room, where I just have enough room for a desk, bed and some storage furniture. It is going to be great to get around 8 times the space of the dorm room.

Last but not least, I have been awarded a Xamarin Most Valuable Professional (MVP) award, which was announced a couple of days ago. I am really honored to get such an award and this is my first MVP award ever. Hopefully I will live up to the award and get a new one at the end of the year.

Looking forward to tackle this year and get the best out of it, get cracking at some code and provide answers to your questions on the community forums etc. I am planning on creating more tutorial videos, like I have done previously, which seem to be quite popular. If you have any topics you want covered related to Xamarin, do post a comment and I might just make a video on that.
January 27, 2015 7:17 GMT

Unified API Migration Example with the Dutch Spelling App

Earlier this month, I recorded a webinar showing an overview of what the new Unified API means for developers and how you can seamlessly migrate your existing apps to guarantee their longevity. As we approach Apple’s deadline for supporting 64-bit in new app submissions, iOS developers around the world are ensuring their apps will continue to be accepted into the App Store by making the necessary changes to enable the support. Xamarin developers will need to follow suit by making sure they’ve updated their apps to use the new Unified API, which replaces the Classic API.

During the webinar I demonstrated the migration process on an app I developed some time ago that needed to be migrated to the Unified API. The app in question is called Dutch Spelling, a language learning app originally built in just 2 hours! It’s available to download from GitHub in order for you to follow the guide I’ve created for you below.

screenshots

Dutch Spelling’s business logic is contained within a library that is referenced from the language specific project. This approach allows me to add new features and fix bugs in only one project, while maintaining the language based content of the app separate.

Migration to Unified.

The migration process from the Classic API to our new Unified API couldn’t be any simpler. If you’ve cloned Dutch Spelling onto your machines, you’ll notice that it currently has two branches. The master branch is our Unified API and the second branch uses the Classic API. I’ve taken this approach with my other iOS apps such as My StepCounter, as it allows you to see the differences in the solution before and after migration.

You’ll want to ensure you’re on the Classic-API branch before starting the migration. Open the project in your favorite IDE (in my case it’s Xamarin Studio) and double check that everything builds as expected. If it doesn’t, please create an issue on GitHub for me to investigate.

Migration Tool

Let’s select the ‘Dutch Spelling’ project and click ‘Project’ > ‘Migrate to Xamarin.iOS Unified API’. You’ll be presented with a dialog explaining what the migration tool will do to your project. You will want to click ‘Migrate to Unified API’.

Xamarin Studio

Visual Studio
Screen Shot 2015-01-26 at 10.15.58 AM

With this, your project will now reference Xamarin.iOS instead of MonoTouch and our Spelling.Core project will be marked as incompatible. This project is now using the Unified API and we don’t need to touch it again, however, we will now need to run the same process on Spelling.Core, and then we’re done.

If the migration tool doesn’t successfully migrate your project, or you’ve got a complex situation, you can manually migrate to the Unified API. Our documentation team has written a fantastic step-by-step migration guide.

Learn More

To learn more about the Unified API be sure to read through the full documentation. To see a full migration of Dutch Spelling in action, check out my Unified API Webinar recording online.

January 26, 2015 2:30 GMT

Episode 22: Designing and Consuming Modern APIs with Darrel Miller

When it comes to designing and consuming APIs there is no shortage of approaches out there. In this episode we talk to Darrel Miller about many of these approaches, and ways to design both sides in a modern way to help keep things maintainable and evolvable over time.

Hosts: Greg Shackles, Jon Dick

Guest: Darrel Miller

Links:

Thanks to our Sponsors!

Raygun.io

Raygun.io – Exceptional Error Tracking Raygun.io is the fastest and easiest way to track your application’s errors and get the level of detail you need to fix crashes quickly. Notifications are delivered right to your inbox and presented on a beautiful dashboard.

January 26, 2015 1:37 GMT

Xamarin and iOS 8: New APIs Training

Url: http://www.learnnowonline.com/course/i8x2/xamarin-and-ios-8-new-apis

Course description

In this course, we will look at how to create an App Extension. Specifically, we will create a today app extensions that shows hot to create an app extensions with a countdown. Then we’ll look at how to use the TouchID to provide local authentication. This is useful for an app where people are buying things. Next we’ll look at several new features of working with images and the camera. We’ll look at manual camera controls as well as photokit. To close this course we’ll look at storing and saving health data using healthkit.

App Extensions (17:33)
  • Introduction (00:16)
  • App Extensions (01:06)
  • Types of App Extensions (02:25)
  • Overview (01:04)
  • Limitations (01:00)
  • Distribute, Install, & Run (00:58)
  • Extension Lifecycle (02:00)
  • Demo: Today Extension (04:25)
  • Demo: Controller (03:48)
  • Summary (00:26)
Touch ID (11:04)
  • Introduction (00:14)
  • TouchID Authentication (01:46)
  • Keychain (01:23)
  • Secure Enclave (00:55)
  • Strategies (00:57)
  • Demo: Touch ID (05:33)
  • Summary (00:15)
Images (22:33)
  • Introduction (00:16)
  • Image Detection (00:44)
  • CIDetector Class (01:11)
  • Demo: Rectangle Detector (02:15)
  • Pre0iOS 8 Camera (01:17)
  • Manual Camera Controls (01:38)
  • Process (00:58)
  • Manual Controls Provided (01:27)
  • General AV Capture Setup (01:27)
  • Demo: Manual Camera Controls (05:18)
  • Resources (00:10)
  • PhotoKit (00:12)
  • PhotoKit Objects/Methods (01:47)
  • Demo: PhotoKit (03:32)
  • Summary (00:14)
Health Kit (15:36)
  • Introduction (00:09)
  • Health Kit (00:59)
  • Creating and Provisioning (00:38)
  • Entitlements.plist (00:47)
  • Programming Health Kit (01:29)
  • Types (01:11)
  • HKSampleType (00:46)
  • Requesting Permission (00:56)
  • Permissions - AppDelegate.cs (02:18)
  • Demo: Health Kit (06:12)
  • Summary (00:07)

 

January 26, 2015 1:00 GMT

Xamarin Forms StackLayout Recipe

Xamarin Forms StackLayout Pancakes

Does the Xamarin Forms StackLayout remind you of pancakes? Asking for a friend!

The easiest and most useful layout in Xamarin Forms is the Xamarin Forms StackLayout. It’s a managed layout which means the height and width of the items placed into the layout are adjusted by the layout automatically. This feature is really helpful because you are not forced to do this work yourself. Child objects placed into the layout can request to be a certain size but it’s ultimately the StackLayout’s call.

 Xamarin Forms StackLayout Orientation

The StackLayout has two options for orientation, you can choose vertical like pancakes or horizontal like slices in a loaf of bread. By default, StackLayout will be in the vertical pancake orientation.

StackLayout {
	Orientation = StackOrientation.Horizontal,
	Children = {
		new Label {
			Text = "Welcome to Orientation"
		}
	}
}

Xamarin Forms StackLayout Orientation

 

Xamarin Forms StackLayout Children

Adding new controls to the StackLayout couldn’t be easier. All you have to do is add your control to the StackLayout’s Children property. Unlike pancakes the first one is at the top not placed at the bottom. This is a first in first drawn system. In vertical (pancake) mode, the first item will be on the top and the second one will be placed underneath the first.

StackLayout {
	Children = {
		new Label {
			Text = "Hello StackLayout!"
		}
	}
}

Other StackLayouts with children can be nested or added as a child in another StackLayout. I commonly do this with lists of details. Each detail has a label and a value in a horizontal orientation and then they are stacked into a vertical StackLayout.

Xamarin Forms StackLayout Children

 

Xamarin Forms StackLayout Padding

The StackLayout inherits from Xamarin.Forms.Layout and has a Padding property that gives you the ability to surround your layout with some space. Just adding a Thickness structure to this property is all you have to do to get some space between your stackLayout and other controls.

StackLayout {
	Padding = new Thickness(10),
	Children = {
		new Label {
			Text = "Pad all the things!"
		}
	}
}

Xamarin Forms StackLayout Padding

 

Xamarin Forms StackLayout Spacing

Do you like butter on your pancakes? I do, but not just on the top. I like to have butter in-between each pancake so that I get maximum butter coverage. Please, don’t judge me. Just like pancakes you might want some space between your items in your StackLayout. Each StackLayout has a Spacing property that you can increase or decrease to separate your stack items.

You don’t have to worry about setting this all the time. The Xamarin Forms StackLayout spacing is set to 6 pixels by default. I hardly ever override this property.

Xamarin Forms StackLayout Spacing

Besides pancakes, the Xamarin Forms StackLayout also reminds me of the HTML Table with a single row or a single column. And the nesting of StackLayouts brings me back to when we thought that was a good idea on the web. Today in Xamarin Forms, the StackLayout is integral to many of my applications and I even nest them without feeling bad about it.

The post Xamarin Forms StackLayout Recipe appeared first on Syntax is my UI.

January 25, 2015 7:00 GMT

App Spotlight: Graphium Health

Danny Dura of Graphium Health talked to us about how his company is working to create better care for patients by bringing data and analytics into the peri-operative (surgical) healthcare space via mobile technology.

The Graphium Health app offers a better experience for both patients and providers by creating effective ways for providers to use the mobile devices they already have in their pockets to track patient data and analytics. Used by doctors, nurses, and other medical staff in hospitals nationwide, the app replaces paper charting with a more secure, accurate, and efficient way to keep track of patient information in an easy, usable format that doesn’t distract from providing top-notch care.

To understand the how the app streamlines care for both doctors and patients, we took a walk through the app with Danny:

I love that Graphium worked to make the app accessible and intuitive for health professionals, while increasing the efficiency and security of the process.

Learn More

To learn more about Graphium Health, or request a free trial, you can visit their website here.

To get started developing with the Xamarin platform, check out our developer documentation, or get live online training with Xamarin University.

January 23, 2015 2:30 GMT

Xamarin MVPs Expand with More Awesome!

Since the introductionXamarin MVP of the Xamarin MVP program in 2013, our MVPs have been busy sharing their love and understanding of mobile app development with a growing community of more than than 880,000 Xamarin developers worldwide. Supporting this growth are amazing community members who show their passion for all things C# and F# by sharing their experience and knowledge with the world.

Xamarin MVPs have earned recognition for significant contributions to the community, including:

  • Writing great articles, books, and blog posts
  • Speaking in public and online
  • Sharing and building amazing libraries
  • Helping developers online in our forums, on Twitter, Stack Overflow, and other communities
  • Shipping awesome apps

Today, we’re extremely excited to recognize and welcome our latest Xamarin MVPs, below, for their remarkable contributions to the community!

enrique Enrique Aguilar Laurent Bugnion laurent
cheesebaron Tomasz Cielecki Jesse Liberty liberty
lipsky Jon Lipsky Roger Peters roger
rachel Rachel Reese Brent Schooley brent
snider Ed Snider Michael Stonis stonis
alec Alec Tucker

If you know of an outstanding developer who would make a great Xamarin MVP, please nominate him or her here.

January 23, 2015 2:09 GMT

Xamarin Weekly Newsletter Issue #24

Introducing the Xamarin WatchKit Preview
Miguel de Icaza, from Xamarin Inc., is happy to announce the WatchKit preview.
Watch Kit Preview Docs.

Xamarin.Forms Kickstarter
Falko Schindler, from Perpetual Mobile, has put a Xamarin Forms startup reference together, check it out.

Contest: Show Us Your App!
Jayme Singleton, from Xamarin Inc., is looking for Xamarin built apps.

Contacts Plugin for Xamarin and Windows
James Montemagno, from Xamarin Inc., has another Plugin for Xamarin. This time it’s contacts.

Xamarin Forms – A light status bar for iOS
Morgan Skinner flips the dark on light to light on dark.

Fixing activatedBackgroundIndicator in AppCompat Navigation Drawer
James Montemagno, from Xamarin Inc., fixes his Android navigation draw.

Infographic: Build Right, Shift Left
Cori Hemmah’s info graphic tries to get you to test early and often.

Programming WatchKit with F#
Larry O’Brien hacks together (his words) F# and Watch Kit.

Authenticate Xamarin Mobile Apps Using Azure Active Directory
Mayur Tendulkar shows what the Xamarin.Auth component can do.

A Couple of Tips Migrating to 64 Bit
David Bolton gives you some tips for converting your iOS app to 64-Bit.

Who is a Customer Success Engineer?
Valentin Polushkin, from Xamarin Inc., explains what his job title means and what he does.

Dealing with Spotty Network Coverage in Xamarin
Jim Wilson gives you his advise for how to handle questionable networks.

Watch out, we support WatchKit!
Mike James is very excited to see Xamarin support WatchKit.

Apple Watch Kit programming with C# (and Xamarin)
Craig Dunn converts his Xamarin.Forms magic 8 Ball to run on his wrist.

Xamarin Insights
Gain insights to how your users are using your application.

SQLite error with Xamarin.iOS Unified API
Alec Tucker gives his advise to iOS developers having issues with SQLite.

Migrating Apps to the Unified API and 64-Bit
Watch the webinar  recording for converting your iOS apps to the unified API.

NuGet Support in Xamarin Studio 5.7
Matt Ward goes over the new Nuget features in Xamarin Studio 5.7.

Help wanted: Beta test the new Nearest Bus
Nic Wise is looking for beta testers in Auckland and London.

Presenters in MvvmCross: Navigating Android with Fragments
Greg Shackles has another MvvmCross post. This time it’s Navigation in Android.

Xamarin Forms–Using background images on iOS
Morgan Skinner goes full screen with his background images.

New Birmingham Xamarin Mobile Cross Platform User Group
Dave Evans is starting a new user group in the UK. Check out the lineup of great mobile topics. I wish I lived closer.

The post Xamarin Weekly Newsletter Issue #24 appeared first on Syntax is my UI.

January 22, 2015 5:42 GMT

Fixing activatedBackgroundIndicator in AppCompat Navigation Drawer

I was overly excited when I got news that our amazing component team had finished the latest binding for AppCompat v7 rev 21! This was exciting to me because this meant that any developer could now introduce material design to their Android app and target older devices all the way back to API 7 (although you should just target API 15). I got busy migrating Bike Now over to AppCompat since it used the navigation drawer and seemed like the perfect candidate. The theming changes were pretty simple, however I ran into a big issue with the navigation drawer when using a ListView. The issue is that I was using a TextView to display my menu items and setting the background to:

android:background=”?android:attr/activatedBackgroundIndicator”

While this is correct, it leaves my items with different colors on different versions of Android. To top it off, none of them look correct. For instance here is what it looks like on API 19:



This is not great, and on API 21 it will have the apps accent color, which makes no sense at all. What we really want is a nice gray accent like the Google Play Store:



Let’s fix this!

The Drawable State List


The main change is to actually replace the activatedBackgroundIndicator completely with our own drawable. The first thing to do is to specify the color we want to use as our highlight in our colors.xml file:



Then create a new xml in the drawable folder named activatedbackground.xml with the follow state list:



Update Your Theme!


The trick here is that we can completely replace the activatedBackgroundIndicator used throughout our application by overriding it in our base theme with this attribute:



Here is what my full theme looks like:



Update your Item Layout


That should be enough to actually get you up and running, however in Bike Now I actually use an image on the left side of my TextView. If I set the background now to the activatedBackgroundIndicator my items will be very upset with me, so I must wrap the TextView in a FrameLayout with it’s background set to the activatedBackgorundIndicator:



And there you have it, a beautiful state list for your items to match your new material design:



Take a look at my full Bike Now project on GitHub and switch to the lollipop branch to see the code in action.
January 22, 2015 4:58 GMT

Infographic: Build Right, Shift Left

You’re at the end of your mobile development cycle and just need to test your app before submitting to the app store. After testing on a handful of devices, you find several showstopper bugs that push your ship date out to weeks past your deadline. Is there a better alternative to this “build then test” workflow that slows your time to market, forces rework, causes bugs, and costs you money?

Download this infographic to learn why shifting your testing processes “left” in the development cycle to the start of your mobile project makes it faster and easier to find bugs before your users do.

Build Right, Shift Left infographic

January 21, 2015 5:52 GMT

Authenticate Xamarin Mobile Apps Using Azure Active Directory

When developing mobile apps, you often run into an instance where your app needs some kind of authentication mechanism to protect its contents. iPhone Active DirectorySome mobile app developers choose to create their own repository to create a username/password based solution. Others choose a social media authentication provider such as Facebook, Twitter, or LinkedIn. Using Xamarin.Auth makes authenticating to services such as these extremely simple to implement.

However, in the case of enterprise apps, people don’t want to remember ‘yet another’ username/password combo and social media authentication is the least expected solution. Users expect their organization account to allow them to use different resources and apps within their system. Welcome to the world of Azure Active Directory (or Azure AD for simplicity).

Azure AD allows developers to secure resources such as files, links, and Web APIs using the same organizational account that employees use to sign in to their systems or check their emails. This should sound a bit familiar, as it is the same authentication mechanism behind Office 365.

Let’s take a look at how to integrate Azure AD into your mobile app with two simple steps.

Step 1: Registering the application with Azure AD

  1. First navigate to https://manage.windowsazure.com and log in with your Microsoft Account or Organization Account in the Azure Portal. If you don’t have an Azure Subscription, you can get a trial from http://www.azure.com
  2. After signing in, go to your Active Directory (1) and select the Active Directory where you want to register the application (2)
    01. Active Directory in Azure Portal
  3. After selecting the desired Active Directory, ‘Add‘ a new application by either clicking the link at front or at the bottom. Then select ‘Add an application my organization is developing
    02. Add New Application
  4. On the next screen, give your app a name. In my case it is ‘XAM-DEMO‘. On this screen, make sure you select ‘Native Client Application‘ as the type of application.
    03. App Name
  5. On the final screen, provide a ‘Redirect URI‘, which is unique to your application as it will return to this URI when authentication is complete.
    04. App Redirect URI
  6. Once the app is created, navigate to the ‘Configure‘ tab. Write down the ‘Client ID’, which we’ll use in our application later. Also, on this screen you can give your mobile application access to Active Directory or add another application like Web API, which can be used by mobile application once authentication is complete.
    05. Configure Application

Step 2: Authenticating the application with Azure AD

In your application, add a reference to Azure Active Directory Authentication Library (Azure ADAL) using the NuGet Package Manager in Visual Studio or Xamarin Studio. Make sure you select ‘Show pre-release packages’ to include this package, as it is still in preview.

Note: Azure ADAL 3.0 is currently a preview and there may be breaking changes before the final version is released. I have included references at the end of this post where you can find more information on Azure ADAL.

06. ADAL NuGet Package

In your application, you will now need to add the following class level variables that are required for the authentication flow.

//Client ID from from step 1. point 6
public static string clientId = "25927d3c-.....-63f2304b90de";
public static string commonAuthority = "https://login.windows.net/common"
//Redirect URI from step 1. point 5<br />
public static Uri returnUri = new Uri("http://xam-demo-redirect");
//Graph URI if you've given permission to Azure Active Directory in step 1. point 6
const string graphResourceUri = "https://graph.windows.net";
public static string graphApiVersion = "2013-11-08";
//AuthenticationResult will hold the result after authentication completes
AuthenticationResult authResult = null;

One thing to note here is commonAuthority. When the authentication endpoint is ‘common’, your app becomes ‘multi-tenant’, which means any user can use login with his Active Directory credentials. After authentication, that user will work on the context of his own Active Directory – i.e. he will see details related to his Active Directory.

At this time, you can modify the default button.Click event from the default Android application (or create your own flow to start the authentication). This will start the authentication and upon completion assign the result in authResult

button.Click += async (sender, args) => {
  var authContext = new AuthenticationContext(commonAuthority);
  if (authContext.TokenCache.ReadItems().Count() == 0)
    authContext = new AuthenticationContext(authContext.TokenCache.ReadItems().First().Authority);
  authResult = await authContext.AcquireTokenAsync(graphResourceUri, clientId, returnUri, new AuthorizationParameters(this));
}

In the above code, the AuthenticationContext is responsible for the authentication with commonAuthority. It has an AcquireTokenAsync method, which take parameters as a resource which needs to be accessed, in this case graphResourceUri, client ID, return URI. The app will return to the returnUri when authentication completes. This code will remain the same for all platforms, however, the last parameter, AuthorizationParameters, will be different on different platforms and is responsible for governing the authentication flow.

In the case of Android or iOS, we pass ‘this’ parameter to AuthorizationParameters(this) to share the context, whereas in the case of Windows, it is passed without any parameter as new AuthorizationParameters().

Along with it, we also need to override the OnActivityResult method in Android to resume the application.

protected override void OnActivityResult(int requestCode, Result resultCode, Intent data)
{
  base.OnActivityResult(requestCode, resultCode, data);<br />
  AuthenticationAgentContinuationHelper.SetAuthenticationAgentContinuationEventArgs(requestCode, resultCode, data);<br />
}

For Windows Phone, modify the OnActivated method in the app.xaml.cs file with the below code:

protected override void OnActivated(IActivatedEventArgs args)
{
#if WINDOWS_PHONE_APP
  if (args is IWebAuthenticationBrokerContinuationEventArgs)
  {
     WebAuthenticationBrokerContinuationHelper.SetWebAuthenticationBrokerContinuationEventArgs(args as IWebAuthenticationBrokerContinuationEventArgs);
  }
#endif
  base.OnActivated(args);
}

Now if you run the application, you should see an authentication dialog. Upon successful authentication, it will ask your permissions to access the resources (in our case Graph API).
08. Authentication-Flow
If authentication is successful and you’ve authorized the app to access the resources, you should get an AccessToken and RefreshToken combo in authResult. These tokens are required for further API calls and for authorization with Azure AD behind the scenes.
07. Access_Token For Authentication

For example, the code below allows you to get a user list from Active Directory. You can replace the Web API URL with your Web API which is protected by Azure AD.

var client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Get, "https://graph.windows.net/tendulkar.onmicrosoft.com/users?api-version=2013-04-05");
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", authResult.AccessToken);
var response = await client.SendAsync(request);
var content = await response.Content.ReadAsStringAsync();

This way you can authenticate your mobile apps against Microsoft Azure Active Directory. ADAL makes it much easier with fewer lines of code, while keeping most of the code the same and thus making it shareable across platforms.

Learn More:

  • Azure ADAL is in preview. So, there can and most likely will be changes before the final release. Follow Vittorio Bertocci’s blog for more details and changes to the library.
  • The Azure Team has shared a complete example with Azure ADAL for each platform. Download it from here.
January 21, 2015 2:00 GMT

Programming WatchKit with F#

Disclaimer: This is just a hack. I’m not in any position to make announcements about stuff, but Xamarin loves F# and I’m sure that better solutions than this are forthcoming. But this was fun to get running, so…

Xamarin just released it’s Preview of Watch Kit support and naturally, I had to see if it was possible to use F# to program the forthcoming Apple Watch. Yes, it is.

As always with Watch Kit Apps, the Xamarin solution consists of three projects:

  1. A Parent app that is a normal iOS app;
  2. An Extension that runs on a connected iPhone and executes the program logic; and
  3. A Watch App that runs on the Watch and is essentially a remote display for the Extension App

You can read much more about this at Xamarin’s Watch Kit Documentation site.

To create an F# Watch solution, first create an F#-based Parent App. Then, add the Extension project to that app, an F#-based Custom Keyboard Extension. Finally, add a Watch App from the C#/iOS/Unified/Apple Watch solution template.

The Watch App consists only of a storyboard and resources. It doesn’t actually have any C# (or F#) code in it.

Follow these instructions to [set project references and identifiers].

Switching the Extension from Custom Keyboard to Watch Kit

You will have to manually edit the info.plist of the Watch Extension:

  • In NSExtension, switch the NSExtensionPointIdentifier to com.apple.watchkit; and
  • Under NSExtensionAttributes, add a WKAppBundleIdentifier key to the identifier of your Watch App (e.g., com.xamarin.FWatch1.watchkitapp)

Screenshot 2015-01-21 15.02.07

Now you can get rid of the template F# code and replace it with something like this:

namespace WatchX

open System
open UIKit
open Foundation
open WatchKit

type InterfaceController(ip : IntPtr) =
    inherit WKInterfaceController(ip)

override this.Awake (context) =
    System.Console.WriteLine("Hello F#")
    this.myLabel.SetText("F# |> I ♡")

Again, this is covered in much more detail in Xamarin’s docs, but every scene in the Watch App’s storyboard is backed by a subtype of WKInterfaceController. Since it’s loaded from a Storyboard, it uses the constructor that takes an IntPtr. The Awake method is called when the controller is instantiated.

The Hacky Part

Xamarin has not yet released designer support for Watch Kit, so for now, you need to edit your Watch App’s Storyboard in XCode Interface Builder.

That’s not the hacky part.

Once you’ve designed your UI, you have to hand-edit the Storyboard XML, adding connections elements that define your outlets (properties) and actions (event-handlers). You have to set the destination attribute to refer to the id of the associated control:

Screenshot 2015-01-21 15.37.52

But really, that’s the only ugly part! ;-)

Back in your Extension app, you now have to use attributes to link up your F# code with elements within the Storyboard. The RegisterAttribute on your WKInterfaceController links to the customClass attribute of the controller element, and the name of your OutletAttribute properties must correspond to the property attribute of the outlet elements. Finally, the selector attribute of your action elements must have a corresponding ActionAttribute :

    namespace WatchX

    open System
    open UIKit
    open Foundation
    open WatchKit

    [<register ("InterfaceController")>]
    type InterfaceController(ip : IntPtr) = 
        inherit WKInterfaceController(ip)

        let mutable label : WKInterfaceLabel = null
        let mutable button : WKInterfaceButton = null

        let mutable clickCount = 0
       
        [<outlet>]
        member this.myLabel with get() = label
        member this.myLabel with set(v) = label < - v

        [<Outlet>]
        member this.myButton with get() = button
        member this.myButton with set(v) = button < - v

        [<Action("OnButtonPress")>]
        member this.OnButtonPush () =
            clickCount < - clickCount + 1
            sprintf "Pressed %d times" clickCount 
            |> this.myLabel.SetText 


        override this.Awake (context) = 
            System.Console.WriteLine("Hello F#")
            this.myLabel.SetText("F# |> I ♡")

And that’s really all there is to putting F# on your wrist!

Github project

January 21, 2015 7:22 GMT

Who is a Customer Success Engineer?

I often get quizzical looks when I tell people my title. What does a Xamarin Customer Succcess Engineer do exactly?

Xamarin's mission statement is to make it fast, easy and fun to create apps. A CSE needs to wear a lot of hats to help make that happen: developer, consultant, trainer, advocate.

I don't know the exact percentage of how much time I get to spend coding, but I try to do it everyday. The majority of my developpement is split between learning new APIs and SDKs, like the recently released WatchKit, and writing sample code for our community.

For a lot of developers, Xamarin is their first foray into mobile developement. The CSEs try to reach as many customers as possible to find out what they are building and provide tailored recommendations. A good portion of my day is also spent answering technical questions via email; those range from specific "How do I do so-and-so using Xamarin?" to strategic "How should we approach Mobile"?

Late last year, our team started recording webinars on topics such as Xamarin Test Cloud and Xamarin.Forms. Our goal, this year, is to offer several monthly webinars that any Xamarin developer can watch and participate in.

Finally, the CSE is the customer's voice inside the company. Alongside our colleagues in Support, we are acutely aware of the challenges our customers are running into. We regularly share feedback from the trenches with our Product and Engineering teams in order for them to know where the major pain points are.

Ultimately, it's about helping and equipping Xamarin developers to build awesome apps.

If you're a developer with a passion for helping others and you think that a Customer Success Engineer position might be good fit, I'd love to chat with you about joining our team.

You can reach me at val@xamarin.com or via Twitter.

January 20, 2015 3:57 GMT

Apple Watch Kit programming with C# (and Xamarin)

For my "Your First Xamarin.Forms App" talk at Evolve this year I built a very simple version of the classic "Magic Eight Ball" fortune-telling app. Seemed like a perfect example to adapt for my First Apple Watch App. It's built in C# using Xamarin (of course); Xamarin's Watch Kit Preview came out today!

Here is the finished app: a simple display that answers any question you ask ;-) Force Touch on the screen to pop-up the menu to ask another question (Shake), or simply say "Thanks". Grab the code from Github.
^ watch frame screenshots generated with Bezel thanks to the fine folks at infinitapps.

Apple Watch Projects

The solution structure for watch apps consists of three projects (notice that watch apps are split in two parts):
  • an iPhone app which delivers the watch app to the user (and is also obviously a regular iPhone app),
  • an Watch Kit Extension where the code for the watch app runs (on the iPhone, but separate to the iPhone app),
  • a Watch app which is only the storyboard and image resources that go to the watch itself.

Storyboard User Interface

After creating the three projects in a new solution, the first step is to draw the user interface in Interface Builder. Right-click on the Interface.storyboard (already in the template) and open in Xcode.

I did the following:
  • gave the interface controller a Title: 8Ball
  • dragged a Label and centered it
  • Ctrl + dragged an outlet from the label into the header file called result
  • dragged a Menu onto the scene (this is triggered by Force Touch)
  • added and named the two MenuItems: Shake & Back
  • Ctrl + dragged an action from the first menu item called shake
Remember: the storyboard (and any image resources) are the the only things that get installed on the watch itself.

WatchKit C# Code

With the user interface defined in the storyboard, I just needed to wire-up the outlet and action I created in C# to make the app work. The C# code will run in the Watch Kit Extension - on the iPhone itself, not on the CPU of the watch.

First I copied the Magic Eight Ball responses from my Xamarin.Forms app (it's a simple string array, called options) and then I started to implement methods in the InterfaceController.

The Awake method is called when the scene is created, so this is where the code selects its first random response to show the user. I store it in a local variable lastResult and also in NSUserDefaults (for the Glance, explained later).

public override void Awake (NSObject context)
{
base.Awake (context);
var rnd = new System.Random();
lastResult = options[rnd.Next(0, options.Length - 1)];
NSUserDefaults.StandardUserDefaults.SetString
(lastResult, "lastResult");
}

Then in WillActivate I set the label's text to the random value:

public override void WillActivate ()
{
result.SetText (lastResult);
}
Finally, the menu's Shake button should choose a new random response, so the action is implemented to generate new new answer, set the local lastResult variable, the NSUserDefault, and also the label's text.

partial void shake () {
var rnd = new System.Random();
lastResult = options[rnd.Next(0, options.Length - 1)];
result.SetText (lastResult);
NSUserDefaults.StandardUserDefaults.SetString
(lastResult, "lastResult");
}

That's all the code required to get the app running! I did a couple more things, however, to demonstrate how to programmatically modify the Menu...

In the Awake method I add another menu item called Thanks:

AddMenuItem (WKMenuItemIcon.Accept, "Thanks", new ObjCRuntime.Selector ("tapped"));
The Selector is implemented as shown - notice the [Export] is required:
[Export("tapped")]
void MenuItemTapped () {
result.SetText ("You're welcome!");
}

Glance Mode

I also implemented Glance mode, which simply displays the last response generated by the app.

The watch app template already includes a GlanceInterfaceController so I just had to drag a couple of Labels onto it, and Ctrl + drag an outlet for one, so I could change the text programmatically.



Because I always store a generated result in NSUserDefaults the GlanceInterfaceController, the code for the glance is really simple:
var r = NSUserDefaults.StandardUserDefaults.StringForKey("lastResult");
lastResult.SetText (r);


Currently you cannot test Glances from within Xamarin Studio, but it's easy to trigger it using Terminal and the following command (make sure you update path to match your app):

/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/mtouch --sdkroot=/Applications/Xcode-Beta.app/Contents/Developer/ --device=:v2:runtime=com.apple.CoreSimulator.SimRuntime.iOS-8-2,devicetype=com.apple.CoreSimulator.SimDeviceType.iPhone-6 --launchsimwatch=/Users/craigdunn/Projects/Watch8Ball/Watch8Ball/bin/iPhoneSimulator/Debug/Watch8Ball.app --watchlaunchmode=Glance

The finished glance display looks like this:

And that's it! Around 10 lines of C# code to build an Apple Watch app.

Download the Xamarin Watch Kit Preview, get the code from Github and try it for yourself!
January 20, 2015 11:14 GMT

Watch out, we support WatchKit!

Screen Shot 2015-01-17 at 22.25.41

 

Xamarin have just announced preview support for Apple Watch and I can’t express how excited I was over the weekend playing with our internal preview build. At this moment time, getting started with Apple Watch can be little confusing, what with the need for 3 different project types to get a hello world sample running! You can see this in the below screenshot of Xamarin Studio. This complexity increases the learning curve so I’ve done my best to try and help.

I’ve created a simple Hello World Apple Watch sample solution which you can download from my GitHub blow:

Xamarin Apple Watch Hello World

One Solution – Three Projects – One Watch App!

Even a basic Apple Watch app requires 1 part App Extension, 1 part Watch App and finally 1 part Unified iOS App. When combined with the correct Bundle Identifiers, you’ve got yourself the beginnings of Apple Watch support. At this moment in time, you’ll need to be editing your storyboard in Xcode rather than Xamarin Studio or Visual Studio. I believe our engineers are hard at work on integrating Apple Watch UI storyboard support in VS and XS much like we have for iPhone and iPad.

Screen Shot 2015-01-19 at 16.37.23 Learn more with some awesome documentation!

Xamarin has some excellent documentation on Apple Watch which I highly recommend you thoroughly read. You an find these below:

Xamarin Documentation

The post Watch out, we support WatchKit! appeared first on Mike James.

January 20, 2015 11:00 GMT

Introducing the Xamarin WatchKit Preview

Today, we are are happy to announce the release of our WatchKit Preview for Xamarin Studio, enabling you to build, run, and test your Apple Watch apps directly from Xamarin Studio.

frontpic_bezel

WatchKit Templates

We’ve added new templates for Watch apps and Watch extensions inside Xamarin Studio. Start with a new or existing iOS app, add a Watch App to house your interface, and then add a Watch extension to power the interaction. Xamarin Studio does all of the heavy lifting for you.

projects

Test in the Simulator

Get started testing your applications in the simulator so you can be ready when devices hit the market. Xamarin Studio has support for building, running, and debugging your Watch apps in app mode. You can also test your app in Glance and Notifications mode from the command line.

simulator

Get Started Today

You can download the bits for WatchKit Preview directly from the Xamarin Developer site. To get started with WatchKit, check out the WatchKit Preview guide.

Please note that this release is a Preview. It is not available on the Stable, Beta, or Alpha channels and is a separate install. We are working hard on adding even more features for WatchKit, including support for the Xamarin Designer for iOS and Visual Studio, in future releases.

Very Important: Since this release is missing our designer support, you must follow the steps outlined in the WatchKit Preview guide to build your UIs.

See everything that WatchKit support has to offer by running the WatchKit Catalog sample from our sample gallery.

January 20, 2015 12:01 GMT

SQLite error with Xamarin.iOS Unified API

If you're using Xamarin.iOS and are working with the Unified API (which you should be!) you may be having issues with the current SQLite NuGet packages. There's an issue that you may have already worked around, but in case you haven't and are seeing the error below when trying to install the SQLite.Net.Platform.XamarinIOS into your Xamarin.iOS project, read on.

 

Attempting to resolve dependency 'SQLite.Net-PCL'.
Installing 'SQLite.Net.Platform.XamarinIOS 2.4.1'.
Successfully installed 'SQLite.Net.Platform.XamarinIOS 2.4.1'.
Adding 'SQLite.Net.Platform.XamarinIOS 2.4.1' to TemplateV1.iOS.
Uninstalling 'SQLite.Net.Platform.XamarinIOS 2.4.1'.
Successfully uninstalled 'SQLite.Net.Platform.XamarinIOS 2.4.1'.
Install failed. Rolling back...
Could not install package 'SQLite.Net.Platform.XamarinIOS 2.4.1'. You are trying to install this package into a project that targets 'Xamarin.iOS,Version=v1.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

 

The current package does not contain elements which are compatible with the Unified API. Your options are:

 

1. Go back to the Classic API

Not really an option, given the 1st of Feb deadline imposed by Apple

 

2. Wait for an updated NuGet package

Maybe an option, but it's cutting it fine

 

3. Download the source and build the binaries yourself

The source is available here: https://github.com/oysteinkrog/SQLite.Net-PCL

You'll see an already existing project for the Unified API here: https://github.com/oysteinkrog/SQLite.Net-PCL/tree/master/src/SQLite.Net.Platform.XamarinIOS.Unified

Download the repo and build SQLite.Net (Portable), followed by  SQLite.Net.Platform.XamarinIOS.Unified

Take the resulting  SQLite.Net.dll and  SQLite.Net.Platform.XamarinIOS.Unified.dll  and reference them manually in your iOS project.

 

January 19, 2015 3:00 GMT

Webinar Recording: Migrating Apps to the Unified API and 64-Bit

Earlier this month we announced that Xamarin.iOS 8.6, featuring the Unified API, is available in the stable channel. This release comes perfectly timed for Apple’s February 1st deadline for new iOS app submissions and June 1st deadline for all new and existing iOS app submissions or updates to include 64-bit support.

In this webinar recording, Xamarin Evangelist Mike James provides an overview on how to make sure your libraries and apps are 64-bit ready by Apple’s deadlines, including how to migrate apps to the Unified API. In addition to the Q&A at the end of the video, we have also included an extended Q&A, below, covering more of the many questions asked during the webinar.

Additional Resources

The sample used in the demo can be found here.

If you’d like to learn more about the Unified API and 64-bit, our documentation has everything you need to get started here. You can also read our blog posts on the Unified API here and here.

Q&A

General

Do we need 64-bit versions of portable libraries coming as NuGet packages to use in a ‘unified’ project?

Library creators will need to update to the new Unified API, and we’ve got some excellent documentation about this here.

Why does the compiler not decide to use int or nint for us? This does not seem to be very “.NET like”.

In a 32-bit world, NSInteger could very easily be mapped to the System.Int32 (short: int) and it worked very well. With NSInteger now being both 32-bit and 64-bit (depending on the underlying architecture of the platform), this approach no longer works.

We’ve gone through all of our iOS and Mac API’s and found every instance of the Objective-C API using NSInteger that originally was mapped to int and these now take an nint.

You can learn more about our decisions behind nint here.

What is a Type Registrar?

On startup, Xamarin.iOS will registered managed classes (which include the [Register] attribute) and methods (which include the [Export] attribute) with the Objective-C runtime. This allows managed classes to be created and managed methods to be called from Objective-C. This is how methods and properties are linked between the C# and Objective-C worlds.

You can learn more here.

How should we handle the new “n” types in shared code?

The new native types found in the Unified API should only be shared in iOS and Mac projects. When creating libraries for consumption outside of these platforms (PCL, Share libraries, etc.) you should be using Int for 32-bit values and Long for 64-bit values.

Learn more about the new type here.

So with non-64-bit devices, will we have to do something different or will it just work?

When you build your Unified API based app, it will by default build dual 32/64-bit binaries transparently.

You alluded to new garbage collection; please elaborate.

We now have a garbage collector called sgen, which is now the default (as opposed to Boehm) which was used for the Classic iOS apps. We’ve also shipped support for our new reference counting system, which helps solves a number of problems that caused apps to crash. Another benefit of the change means your app consumes less memory. (The new reference counting can also be enabled in the Classic API from the project settings)

Learn more here.

Xamarin.Forms

Should I migrate my UI shared project on Xamarin.Forms? Or just the iOS Project?

You will only need to update the iOS project rather than the shared project. You can find our documentation on Xamarin.Forms migration here.

What about migration of an existing Plugin for Xamarin.Forms? How do we keep compatibility with existing apps that might be using our control and also provide the 64-bit support?

You simply need to upgrade your plugins to 1.3.1 and add a unified Library. I have already updated mine on GitHub. You can also check out other examples here and here.

Discuss this blog post in the Xamarin Forums

January 18, 2015 12:00 GMT

NuGet Support in Xamarin Studio 5.7

Changes

  • NuGet menus renamed to make them easier to discover
  • Solution window icons made consistent
  • Fix build errors after MSBuild target restored for package
  • Fix types imported by MSBuild target not recognised after NuGet package installed
  • Fix Solution window cannot be opened when access to NuGet.Config is denied
  • Fix updating all packages not updating dependencies
  • Fix pre-release NuGet package being downgraded on update

More information on all the new features and changes in Xamarin Studio 5.7 can be found in the release notes.

NuGet menus renamed

The menus have been changed so they now include the word NuGet to make them easier to discover.

Project menu

NuGet menu items in the main Project menu

Solution context menu

NuGet menu items in the Solution context menu

Project context menu

NuGet menu items in the Project context menu

Solution Window

The warning icon used in the Solution window has been changed so it is consistent with other Solution window items.

Package not restored

Solution Window - NuGet package not restored

Solution Window - NuGet package not restored with tooltip

A new warning icon is used for packages that are not restored, the text is greyed out and hovering over the warning icon shows information about the warning.

Package installing

Solution Window - NuGet package installing

When a package is being installed the text is greyed out to indicate that the package is not currently available in the project and the text shows (installing) to distinguish between a package being installed and a package that is not restored.

Package needs retargeting

Solution Window - NuGet package needs retargeting

A new warning icon is used for packages that need retargeting. The package id text has changed to black text instead of orange. Hovering over warning icon shows a message that the package needs retargeting.

Bug Fixes

Build errors after MSBuild target restored for package

If a NuGet package had an MSBuild target that added extra references to the project then on restoring the NuGet package those references were still unavailable and the build would still fail.

This problem occurs with the MonoGame.Binaries NuGet package. The MonoGame.Binaries NuGet package has a custom MSBuild .targets file that adds extra references:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Reference Include="MonoGame.Framework">
      <HintPath>$(MSBuildThisFileDirectory)\MonoGame.Framework.dll</HintPath>
    </Reference>
    <Reference Include="Tao.Sdl">
      <HintPath>$(MSBuildThisFileDirectory)\Tao.Sdl.dll</HintPath>
    </Reference>
    <Reference Include="OpenTK">
      <HintPath>$(MSBuildThisFileDirectory)\OpenTK.dll</HintPath>
    </Reference>
  </ItemGroup>
</Project>

If the MonoGame.Binaries NuGet package is not available on opening the project in Xamarin Studio the project will fail to build after restoring the NuGet package since the references in the MSBuild targets file were not being refreshed.

Now after a NuGet package restore the MSBuild host used by Xamarin Studio is refreshed which allows the references in the MSBuild targets file to be found and the project to compile without any build errors.

Types imported by MSBuild target not recognised after NuGet package installed

If a NuGet package had an MSBuild target that added extra references to the project then on installing the NuGet package the types from those references were still unavailable to Xamarin Studio and would be highlighted in red in the text editor. To fix this the solution had to be closed and re-opened. This problem occurs with the MonoGame.Binaries NuGet package.

Now after a NuGet package is installed and it contains a MSBuild targets file then Xamarin Studio’s type system will be refreshed for that project. The types will then be known by Xamarin Studio and no longer be highlighted in red in the text editor.

Solution window cannot be opened when access to NuGet.Config is denied

If the NuGet directory containing the NuGet.Config file cannot be created or read by NuGet then an exception is thrown. This exception was not being handled by Xamarin Studio and would prevent the solution window from opening.

Now if there is any error creating this directory, or trying to load the NuGet.Config file, then the exception is caught which allows the Solution window to open. If the NuGet directory containing the NuGet.Config file cannot be created then it will not be possible to use NuGet in Xamarin Studio but it will not prevent the solution pad from being used.

Updating all packages not updating dependencies

Updating NuGet packages for the entire solution would not install the Xamarin.Android.Support.v13 NuGet package which was added as a new dependency to the Xamarin.Android.Support.v4 NuGet package.

The problem was that the NuGet package update was not configured to update any NuGet package dependencies when updating all packages in the solution. Updating all packages in the project or the NuGet package individually would update package dependencies correctly.

Note that this fix has introduced a bug where Xamarin Studio will show updates as available even though the updates have just been installed for the solution. This new bug should be fixed in Xamarin Studio 5.8.

Pre-release NuGet package being downgraded on update

When a pre-release NuGet package was installed that was newer than the latest stable NuGet package available then updating the package would install the stable version even though it was a lower version. Now an explicit check is made to ensure that an older NuGet package is not being installed.

January 17, 2015 7:05 GMT

Microsoft Band: the end

I had a lot of fun with the Band initially.

Then after literally two seconds in the shower after a long run, it died. I doubt it got that wet - I literally stepped into the shower, noticed the Band was still on my wrist, then took it off and placed it out to dry.

But that was enough to kill it. The screen went all crazy and illegible. It was dead.




I had paid the $20 'extended warranty' fee, so the guys at the Microsoft Store grudgingly replaced it. I say grudgingly because one staff member really didn't seem sure about it; luckily another guy got involved and was more than happy to help me. They made it clear that if I hadn't paid for the extended warranty, they would not be replacing it at all.

Then they asked for another $20. To cover this Band with extended warranty. I was very annoyed by this. I didn't pay. But now I'm too scared to use the Band. What if, while running outdoors, it rains? The Band apparently will die at the slightest hint of water, and next time Microsoft promised they would NOT be replacing it unless I paid the additional $20.

So now I hardly wear it. It's in a drawer somewhere. So long, Microsoft Band, I hardly knew yea...

Microsoft: if you put a GPS in a fitness device, you're saying it's okay to use it outdoors. If that same device fails in the slightest mist of rain, the device itself is a failure.
January 16, 2015 8:56 GMT

Help wanted: Beta test the new Nearest Bus

I've been doing a bit of work on Nearest Bus recently, mostly as it's my simplest and most popular (in terms of users) app.

I decided on a full rewrite, as the app is now quite old and bit creaky, plus in it's current state, I'm not using it on a daily basis, as I don't live in London anymore.

So, it's about ready to beta test. More techie info below, but if you live in London (UK) or Auckland (NZ) - it now works in BOTH cities! - and want to try it out for me, fill this form out and go grab the TestFlight app from Apple and I'll add you into the beta. (does it still need to be said that email addresses will only be used for this beta? Really?)

Only requirements are:

  • You live in London or Auckland
  • You use Buses (both cities) and/or Ferries and Trains (Auckland only)
  • You have an iOS8 running device. This app now requires iOS8.

The main changes are:

  • Supports Auckland, as well as London
  • Today Extension showing your nearest favourites! (that was the main reason for the rewrite)
  • A cleaner UI, inspired by Googles Material Design.
  • And: my word the old code was crufty. Yuck.

From a technical standpoint, the app has gone from code-only layout, to using storyboards (which I'm mostly enjoying using). That reduced the codebase by maybe 50%, not to mention made it a lot quicker to write. The architecture of the app has changed to fall more inline with what I think a modern app should be - decoupling the data source from the UI, message passing and dependancy injection allowing for communication between the "layers", that kind of thing. To put it mildly, the old app was a mess, written in a hurry. Things have moved on in 3 years.

I plan to blog about it later, once the app is out.

Anyway, if you want to help out (not a requirement, even if you sign up), please do! Thanks!

January 16, 2015 2:48 GMT

Xamarin Weekly Newsletter Issue #23

customLogo

New Xamarin Profiler Preview
Nina V, from Xamarin Inc., shows off the new and improved Xamarin Profiler.

Azure Mobile Services for Client Apps
Sara Silva has assembled an awesome curation of links and articles about accessing and using Azure Mobile Service for mobile apps.

Azure Mobile Services Guide
Sara Silva does it again and makes an Azure Mobile Services backend curation for .Net and JavaScript backends.

Creating a Xamarin Forms App Part 12 : Extending the User Interface.
Jonathan Yates finishes off his 12 part blog series and ends with extending the interface. This is one of the most popular series on Xamarin Weekly. Check it out.

Major Enhancements to Xamarin.Forms
James Montemagno, from Xamarin Inc., announces the release of serveral major features of Xamarin.Forms.

Resilient network services with mobile Xamarin apps
Rob Gibbens, from Xamarin Inc., is back on the newsetter! Check out all the awesome Nuget packages he uses to make his app more resilient.

Xamarin.Forms Navigation Page
I (Adam) get pushy and pop my stack using the Navigation Page.

Xamarin Forms – Adopting early, 97% shared code and the gotchas
Lee Mallon, from Rarely Impossible, goes over why they are early adopters of  Xamarin.Forms.

ModernHttpClient Pro Edition
Paul Betts announced a pro edition of ModernHttpClient that can use self signed certs.

How to WIN with Xamarin.Forms
Michael Ridland clears up some misconceptions about Xamarin and Xamarin.Forms.

Xamarin Forms 1.3 Triggers Bug
Jonathan Yates finds some bugs in the newly released Xamarin Forms Triggers.

Xamarin.iOS Unified API with 64-bit Support
Miguel de Icaza, from Xamarin Inc., announced Xamarin.iOS 8.6 with the Unified API and 64-bit support.

Presenters in MvvmCross: Controlling the Back Stack
Greg Shackles adds another post to his MvvmCross presenter series. This time he is controlling the back stack.

Xamarin Forms 1.3 Behavior Binding Bug
Jonathan Yates finds another bug in Xamarin.Forms 1.3 this time it’s in the Behavior Binding.

Load More Items at End of ListView in Xamarin.Forms
James Montemagno, from Xamarin Inc., is rescued by the ItemAppearing event and loads more items onto his ListView.

Xamarin Test Cloud Video Series: Uploading Test Scripts and Viewing Mobile Test Results
Steven Yi, from Xamarin Inc., adds another video to the Test Cloud Series.

 

Don’t miss out! Subscribe Today

Do you blog about Xamarin? Get your blog in the newsletter.
Email me at adam [at] XamarinWeekly.com.

The post Xamarin Weekly Newsletter Issue #23 appeared first on Syntax is my UI.

January 16, 2015 1:30 GMT

Contest: Show Us Your App!

Have you created a beautiful app with Xamarin? Here’s your chance to show the world what you’ve built!

In this contest, you will create a short video showing us the app you have created, how it works, and any other fun details about the development process while building your mobile application.

blog phone pic 2

How to Enter:

  1. Record a short video demoing your Xamarin app
  2. Post your video to the Show Us Your App forum thread
  3. Tweet your video with the hashtags #Xamarin #BuiltWithXamarin

Here is a sample from our own James Montemagno, demoing his Android app “Bike Now”:

Prize:

  • Best App: $100 App Store / Google Play credit to help promote your app!
  • Best Video: $100 App Store / Google Play credit to help promote your app!

All submissions must be made by Monday, February 2nd at 12pm EST. We will evaluate each video and choose the winner based on concept, video quality, and originality. A valid entry consists of a tweet and forum post with a demo video of your personal app. Contestants should follow @XamarinHQ to enable us to DM you for private follow-up. There is no purchase necessary to enter the Show Us Your App Video contest.

January 16, 2015 12:44 GMT

Presenters in MvvmCross: Navigating Android with Fragments

In my last couple posts on this subject I've mentioned using fragments on Android for navigation. By default MvvmCross will use activities on Android, but as I hope you've learned by now, you can use presenters to customize this sort of thing as much as you'd like. I've found it very difficult (or impossible) to properly achieve the types of fine-grained navigation control I want in my apps by using activities for all my views, which is one of several reasons I've switched to using fragments for everything.

Ultimately what this ends up looking like is somewhat similar to a Single Page Application on the web: a single container activity with a fragment stack containing the actual views of the app. You can mix and match here if you'd like too, as I'll show later in my sample presenter.

Views and View Models

First let's quickly set up the basic app essentials here, starting with the view models:

using Cirrious.MvvmCross.ViewModels;

namespace PresenterDemo.Core.ViewModels  
{
    public class FirstViewModel : MvxViewModel
    {
        public IMvxCommand NavigateCommand
        {
            get { return new MvxCommand(() => ShowViewModel<SecondViewModel> ()); }
        }
    }

    public class SecondViewModel : MvxViewModel
    {
    }
}

Nothing crazy here, just a view model that can navigate to a second view model. Next we'll define the view markup, starting with FirstView.axml:

<?xml version="1.0" encoding="utf-8"?>  
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"  
    xmlns:local="http://schemas.android.com/apk/res-auto"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <Button
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Navigate"
        local:MvxBind="Click NavigateCommand" />
</LinearLayout>  

and SecondView.axml:

<?xml version="1.0" encoding="utf-8"?>  
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"  
    xmlns:local="http://schemas.android.com/apk/res-auto"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Second view" />
</LinearLayout>  

As I mentioned earlier, the app will use a single activity that hosts the fragments, so we'll also define a layout named Container.axml:

<?xml version="1.0" encoding="utf-8"?>  
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"  
    xmlns:local="http://schemas.android.com/apk/res-auto"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    <FrameLayout
        android:id="@+id/contentFrame"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />
</LinearLayout>  

Finally we need our fragments:

using Android.OS;  
using Android.Views;  
using Cirrious.MvvmCross.Binding.Droid.BindingContext;  
using Cirrious.MvvmCross.Droid.FullFragging.Fragments;

namespace PresenterDemo.Droid  
{
    public class InitialFragment : MvxFragment
    {
        public override View OnCreateView (LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
        {
            base.OnCreateView(inflater, container, savedInstanceState);

            return this.BindingInflate(Resource.Layout.FirstView, null);
        }
    }

    public class SecondView : MvxFragment
    {
        public override View OnCreateView (LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
        {
            base.OnCreateView(inflater, container, savedInstanceState);

            return this.BindingInflate(Resource.Layout.SecondView, null);
        }
    }
}

I'll get back to the activity itself a little later.

Fragment Lookup

As with most things there are an endless number of ways you can implement this sort of thing, but in this example we're going to create a class that scans the assembly for fragment views and create a mapping that can be used to match them up with view models by name. This will follow the standard convention of matching a FooViewModel view model with a view named FooView.

using System;  
using System.Collections.Generic;  
using System.Linq;  
using Cirrious.CrossCore.IoC;  
using Cirrious.MvvmCross.Droid.FullFragging.Fragments;

namespace PresenterDemo.Droid  
{
    public interface IFragmentTypeLookup
    {
        bool TryGetFragmentType(Type viewModelType, out Type fragmentType);
    }

    public class FragmentTypeLookup : IFragmentTypeLookup
    {
        private readonly IDictionary<string, Type> _fragmentLookup = new Dictionary<string, Type>(); 

        public FragmentTypeLookup()
        {
            _fragmentLookup = 
                (from type in GetType().Assembly.ExceptionSafeGetTypes ()
                 where !type.IsAbstract 
                    && !type.IsInterface 
                    && typeof(MvxFragment).IsAssignableFrom(type)
                    && type.Name.EndsWith("View")
                 select type).ToDictionary(getStrippedName);
        }

        public bool TryGetFragmentType(Type viewModelType, out Type fragmentType)
        {
            var strippedName = getStrippedName(viewModelType);

            if (!_fragmentLookup.ContainsKey(strippedName))
            {
                fragmentType = null;

                return false;
            }

            fragmentType = _fragmentLookup[strippedName];

            return true;
        }

        private string getStrippedName(Type type)
        {
            return type.Name
                       .TrimEnd("View".ToCharArray())
                       .TrimEnd("ViewModel".ToCharArray());
        }
    }
}

The Presenter

With that mapping implemented, now we can actually work on the presenter itself. This implementation will keep things simple, but you could easily extend it with fancier navigation patterns like the ones shown in previous posts here. Let's start with the basic outline for the class:

using System;  
using Android.App;  
using Cirrious.MvvmCross.Droid.FullFragging.Fragments;  
using Cirrious.MvvmCross.Droid.Views;  
using Cirrious.MvvmCross.ViewModels;

namespace PresenterDemo.Droid  
{
    public class DroidPresenter : MvxAndroidViewPresenter
    {
        private readonly IMvxViewModelLoader _viewModelLoader;
        private readonly IFragmentTypeLookup _fragmentTypeLookup;
        private FragmentManager _fragmentManager;

        public DroidPresenter(IMvxViewModelLoader viewModelLoader, IFragmentTypeLookup fragmentTypeLookup)
        {
            _fragmentTypeLookup = fragmentTypeLookup;
            _viewModelLoader = viewModelLoader;
        }
    }
}

The presenter takes in the fragment mapping and a view model loader as dependencies, which can be used later during navigation to inflate the proper fragments.

Now, this next part is the one thing here that feels somewhat dirty, but its scope is pretty limited. Since the container activity is what is going to be started initially, we'll make it so that activity has some knowledge of the presenter, and registers its fragment manager and an initial fragment to show with the presenter:

public void RegisterFragmentManager(FragmentManager fragmentManager, MvxFragment initialFragment)  
{
    _fragmentManager = fragmentManager;

    showFragment(initialFragment, false);
}

This isn't quite as clean of a separation as you get on iOS, but it's not bad. Next we'll handle when a new view model request comes in:

public override void Show(MvxViewModelRequest request)  
{
    Type fragmentType;
    if (_fragmentManager == null || !_fragmentTypeLookup.TryGetFragmentType(request.ViewModelType, out fragmentType))
    {
        base.Show(request);

        return;
    }

    var fragment = (MvxFragment)Activator.CreateInstance(fragmentType);
    fragment.ViewModel = _viewModelLoader.LoadViewModel(request, null);

    showFragment(fragment, true);
}

The main thing to notice here is that if no corresponding fragment is found in the map, we fall back to the base presenter's implementation. This means that if a request comes in for ThirdViewModel, it will actually go look for an activity named ThirdView, since it won't match anything in the fragment type map. This allows you to switch between activities and fragments if you wish.

Both of these last two methods call a private method to actually show the fragment:

private void showFragment(MvxFragment fragment, bool addToBackStack)  
{
    var transaction = _fragmentManager.BeginTransaction();

    if (addToBackStack)
        transaction.AddToBackStack(fragment.GetType().Name);

    transaction
        .Replace(Resource.Id.contentFrame, fragment)
        .Commit();
}

For the initial fragment we don't want to add it to the backstack, because then you'd be able to hit back on the initial view and see an empty screen, rather than back out of the app as expected. This is also where you could add things like transition animations if you wanted.

Finally, we need to handle when Close requests come in:

public override void Close(IMvxViewModel viewModel)  
{
    var currentFragment = _fragmentManager.FindFragmentById(Resource.Id.contentFrame) as MvxFragment;
    if (currentFragment != null && currentFragment.ViewModel == viewModel)
    {
        _fragmentManager.PopBackStackImmediate();

        return;
    }

    base.Close(viewModel);
}

Again, this implementation allows for mixing fragments and activities. If the request comes in from the current fragment it will be popped off the stack, but if not it will defer to the base implementation to close the view model.

Wiring It Up

Now all that's left is to wire up our dependencies and connect the activity to the presenter:

using Android.Content;  
using Cirrious.CrossCore;  
using Cirrious.MvvmCross.Droid.Platform;  
using Cirrious.MvvmCross.Droid.Views;  
using Cirrious.MvvmCross.ViewModels;

namespace PresenterDemo.Droid  
{
    public class Setup : MvxAndroidSetup
    {
        public Setup(Context applicationContext) : base(applicationContext)
        {
        }

        protected override IMvxApplication CreateApp()
        {
            return new Core.App();
        }

        protected override IMvxAndroidViewPresenter CreateViewPresenter()
        {
            var presenter = Mvx.IocConstruct<DroidPresenter>();

            Mvx.RegisterSingleton<IMvxAndroidViewPresenter>(presenter);

            return presenter;
        }

        protected override void InitializeIoC()
        {
            base.InitializeIoC();

            Mvx.ConstructAndRegisterSingleton<IFragmentTypeLookup, FragmentTypeLookup>();
        }
    }
}

With that in place we can create our container activity and connect the presenter:

using Android.App;  
using Android.OS;  
using Cirrious.CrossCore;  
using Cirrious.MvvmCross.Droid.Views;

namespace PresenterDemo.Droid.Views  
{
    [Activity(Label = "Presenter Demo", 
              MainLauncher = true,
              Icon = "@drawable/icon")]
    public class FirstView : MvxActivity
    {
        protected override void OnCreate(Bundle bundle)
        {
            base.OnCreate(bundle);

            SetContentView(Resource.Layout.Container);

            var presenter = (DroidPresenter)Mvx.Resolve<IMvxAndroidViewPresenter>();
            var initialFragment = new InitialFragment { ViewModel = ViewModel };

            presenter.RegisterFragmentManager(FragmentManager, initialFragment);
        }
    }
}

In this example we simply pass the view model from the activity into the first fragment, but you could customize this as necessary of course.

That's all you need to set up basic fragment-based navigation in your Android apps. I highly recommend using fragments when possible, both for the flexibility around navigation and also just for the ability for reuse in different layout configurations. There are a number of different approaches to fragment presenters out there, but I wanted to share one approach I've found that has worked very well in my apps and has given me a lot of flexibility.

January 15, 2015 10:27 GMT

How to WIN with Xamarin.Forms

‘Xamarin is not ready’ a statement I heard recently. What do you think?

Anyone that’s experienced in Xamarin knows this is an inaccurate statement, there’s been a huge amount of successful Native applications built with Xamarin including apps like RDIO, Storyo and iCircuit and apps from large corporations like Banks, Tesco and Microsoft. You probably already know I’m a Xamarin lover, but in this blog I’m going to give you a real honest view.

While the statement is inaccurate I can also understand how someone could come to this conclusion, especially if their first experience is with Forms and even more so if they’ve had Native app development experience before. The reason for this is that 1) Xamarin.Forms is still only months old (some argue it’s still beta quality), to be perfectly honest when Xamarin.Forms was released it did kind of match the promises but it was buggy and lacking features so it was basically a beta release (when compared with Microsoft products). 2) When you come from a experienced App development background there’s certain ways you want an app to work and with Forms it can be difficult to break out of the standard API and do you own thing. Initially I struggled with this and was a little frustrated. I eventually learnt to ‘not to fight the framework’ As Xamarin.Forms is a abstract API which means certain there’s ways it works and strengths/weaknesses, it’s a trade off.

The first thing you need to understand is that Xamarin is not Xamarin.Forms, the core of what made Xamarin famous is ‘Xamarin  Traditional’ eg Xamarin.iOS and Xamarin.Android. ‘Xamarin Traditional’ is absolutely rock solid, when you develop an app in ‘Xamarin Traditional’ it can be as fast, stable and functional as any Native app.

While there’s issues with Forms, I’ve adopted it in the majority of apps. Why? Because even though it kinda sucks, it sucks less than all the other options like 1) building/coding it on all platforms 2) a clunky PhoneGap app. If you know how to harness it’s goods part and avoid the bad parts then it’s actually very powerful, especially how you can jump in/out of Native Code/Bind Native libraries and even use HybridWebViews. Over the past 6 months I’ve delivered many Forms apps for clients so below I’m going to give some tips on how you can WIN with Xamarin.Forms.

Understand what the Framework can and can’t do

Xamarin.Forms is an abstraction on the top of Xamarin.iOS and Xamarin.Android it’s major advantage is that you can program to a single api(with Databinding) and have it render natively, but there’s a bunch of caveats for example 1) ListView performance isn’t great, so it’s not recommended for super large lists of data 2) Sometimes renderering of pages with many controls is slow. Now both these issues can be worked around, in both these cases you can use a custom renderer.

Don’t fight the Framework

This is a big one others have also commented on this. This one become especially challenging for people experienced in native apps/xamarin traditional as normally they(like me) bring in certain expectations and ways they want things to work. In Xamarin.Forms you need to let go any preconceptions of how you want something to work, you need to learn the Xamarin.Forms way to do it. If you try to treat Xamarin.Forms like a iOS API then it’s going to be painful.

Use the Forums

One of the great places to keep updated and have questions answered is the Xamarin forums, it’s the most active place for Xamarin.Forms even more active than StackOverflow. I definitely recommend spending some time in the forums, new releases and updates are notified on these forums. The address is forums.xamarin.com.

Learn from github

As most developers know the best way to learn code is to read and write code. When learning Xamarin.Forms I found the github the most useful resource, James and Craig from Xamarin have some great github repos and there’s also the official one from Xamarin.

Xamarin.Forms Xaml is not WPF

WPF is Xaml and so it Xamarin.Forms so it makes logical sense that if your good at WPF you’ll be good at Forms, but this far from the truth now and probably into the future. WPF was built for a single platform and built by the creators of that platform(Microsoft) with a huge amount of resources, so even on v1 it was very functional and stable. Xamarin.Forms is very different for a few reasons 1) it was built for multiple platforms 2) it was built by a small team and released very early 2)  it still suffers low-common dominator issues. As it stands if you’re building a serious app with Xamarin.Forms it’s likely you’ll hit the limits of Forms in the first few days and you’ll end up spending a lot of time in custom renders programming the Native API. Which isn’t a problem really, as the native API’s are great, it’s only a problem if you think you whole app is going to be Xaml and a WPF developer is going to rock at it.

Use it on the correct app

Using Xamarin.Forms is a trade off, the advantage of Forms is that you’ve got a single API which maps to native controls but the disadvantage is that it’s a abstract API and your bound to the API unless you want to do custom renderers. Taking the RunKeeper app for an example, as it stands in Jan 2015 in Xamarin.Forms you definitely wouldn’t be able to pull off the RunKeeper app and the best option is to use Xamarin.Traditional.

Dig into the source

In Xamarin Studio your able to look at the source for Xamarin.Forms using the built in Assembly viewer and there’s also products that allow you to decompile source such as reflector or ILSpy.

In a normal work day on Xamarin.Forms I’ll dig into a custom renderers code at least once. I found this insanely useful as it allows me to understand what’s going on underneath the surface in Xamarin.Forms and work around issues or come up with creative solutions to issues.

Some bonus places to keep upto date with Xamarin.Forms

Xamarin Weekly Newsletter - always manages to find some blogs that I’ve missed.

Xamarin Documentation – it’s a bit behind the githubs/forums but it’s still good

Planet Xamarin - this is the compiled blogs of many Xamarin Guru’s

Sydney Xamarin Guy – can’t forget my blog of course

Hopefully this blog post has giving you some insights into Xamarin.Forms and how to be productive with Xamarin.Forms.

Thanks

Michael

 

 

 

 

The post How to WIN with Xamarin.Forms appeared first on Michael Ridland.

January 15, 2015 8:00 GMT

Xamarin Event: TechDays 2015 in Paris

Join Xamarin at Microsoft TechDays 2015 in Paris, France from February 10-12. Key members from Team Xamarin will be available all three days to answer your questions, discuss your apps and projects, and catch you up on our incredible 2015 roadmap.

Xamarin at TechDays 2015

Mike James, Xamarin Developer Evangelist, will speak about cross-platform development with Xamarin and Xamarin.Forms on Wednesday, February 11th at 11:00am.

Visit us at Booth S67, or schedule a dedicated time to speak with one of our team members.

À bientôt!

January 14, 2015 2:00 GMT

New Xamarin Profiler Preview

A new Xamarin Profiler preview is available for download today. This release focuses on boosting performance and improving usability. Here’s a rundown of some of our favorite features:

Time Range Selection

Screen Shot 2015-01-08 at 5.38.46 PM

Time range selection lets you highlight an interesting area in the instrument chart and limit the profiling data to a specific time period. Use it to explore a sudden peak in memory usage, keep tabs on performance while your app is running a particular task, or just limit your scope to a manageable amount of data.

Screenshot 2015-01-08 16.44.18

Better Snapshots

Snapshot automation allows you to set the profiler to take snapshots at regular intervals during your profiling session. The snapshots panel also supports rough snapshot comparison, so you can see when memory usage dropped between snapshots (marked in red).

Before memory fix:

Screen Shot 2015-01-09 at 5.18.37 PM

After memory fix:

Screen Shot 2015-01-09 at 5.18.22 PM

And More!

Xamarin.Mac Support – We’ve added initial support for profiling desktop applications built with Xamarin.Mac. Now, your Mac desktop apps can be just as polished as your mobile apps!

Preferences Panel – You can set all your preferences for sampling, snapshots, and more in one place.

Screen Shot 2015-01-09 at 4.25.09 PM

Drag & Drop for Windows – One of our favorite new features is the addition of drag & drop to the Windows version of the Xamarin Profiler. You can load saved files of previous runs by simply dragging and dropping them into the Profiler interface.

Screenshot 2015-01-08 16.44.46

Get it Now

The new Profiler preview is available for download from the Profiler landing page. In addition to the new features, we’ve addressed many customer-reported bugs, issues, and requests. A full list of improvements is captured in the release notes.

Get in touch with our team on the Xamarin Forums and let us know what you think of the new features!

January 13, 2015 5:35 GMT

Resilient network services with mobile Xamarin apps

Sample code is available at my Github repo

For most of our computing history, our machines and our applications sat on a desk and never moved. We could count on a constant supply of power, resources, and network access. Developers didn't spend a lot of time planning for interruptions or failures with those resources. It was even common to have applications that worked completely locally, where we never had to think about the network.

We live in a mobile world

We take our devices with us everywhere. We have them at home, at work, and on vacation. They are with us whether we have gigabit wifi or when we are on 4g cell connections. They need to work when we are traveling through tunnels, on trains, in cars, flying at 30,000 feet, and when we have no network connection at all. As developers, we have to not only expect these requirements, we need to plan for them in the initial design and architecture of our mobile apps.

Current approach

When we first start writing our Xamarin apps, we probably take the easiest approach in writing our networking code. Maybe we just use Microsoft's HttpClient library to make a call, and then Json.net to deserialize the resulting json. Maybe we go a step further and include some additional libraries as well. You can see this approach in my previous post End to End Mvvm with Xamarin where I show a simple implementation of a service client.

namespace DtoToVM.Services  
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Net.Http;
    using System.Net.Http.Headers;
    using System.Threading.Tasks;
    using AutoMapper;
    using Newtonsoft.Json;
    using DtoToVM.Dtos;
    using DtoToVM.Models;

    public class TekConfClient
    {
        public async Task<List<Conference>> GetConferences ()
        {
            IEnumerable<ConferenceDto> conferenceDtos = Enumerable.Empty<ConferenceDto>();
            IEnumerable<Conference> conferences = Enumerable.Empty<Conference> ();

            using (var httpClient = CreateClient ()) {
                var response = await httpClient.GetAsync ("conferences").ConfigureAwait(false);
                if (response.IsSuccessStatusCode) {
                    var json = await response.Content.ReadAsStringAsync ().ConfigureAwait(false);
                    if (!string.IsNullOrWhiteSpace (json)) {
                        conferenceDtos = await Task.Run (() => 
                            JsonConvert.DeserializeObject<IEnumerable<ConferenceDto>>(json)
                        ).ConfigureAwait(false);

                        conferences = await Task.Run(() => 
                            Mapper.Map<IEnumerable<Conference>> (conferenceDtos)
                        ).ConfigureAwait(false);
                    }
                }
            }

            return conferences.ToList();
        }

        private const string ApiBaseAddress = "http://api.tekconf.com/v1/";
        private HttpClient CreateClient ()
        {
            var httpClient = new HttpClient 
            { 
                BaseAddress = new Uri(ApiBaseAddress)
            };

            httpClient.DefaultRequestHeaders.Accept.Clear();
            httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

            return httpClient;
        }
    }
}

This code works just fine, but it does not take any network failures into account. If the network was down, or the service was not responding, or we got any type of exception then the entire application will terminate. Obviously this is suboptimal.

Goals

Our goals for our apps should include, but not be limited to, the following:

  • Easy access to restful services
  • Fast response for our users
  • Work offline
  • Handle errors

Secondary goals include:

  • Fast development time
  • Easy maintenence
  • Reuse existing libraries

Let's address those goals one at a time, and see how we can improve the state of our networked app. As usual, I'll be using a conference app based on TekConf.

Easy access to restful services

Refit

Install-Package Refit

The first thing that we're going to need is a way to access our services. We could use HttpClient + Json.net as we did in the previous example. We can make this simpler though. Again, a secondary goal is to reuse existing libraries. The first one that we're going to pull in is Refit. Refit allows us to define an interface that describes the API that we're calling, and the Refit framework handles making the call to the service and deserializing the return.

In our case, the interface will look like this:

[Headers("Accept: application/json")]
public interface ITekConfApi  
{
    [Get("/conferences")]
    Task<List<ConferenceDto>> GetConferences();

    [Get("/conferences/{slug}")]
    Task<ConferenceDto> GetConference(string slug);
}

Here we are declaring that our remote api will return json, and there are two "methods" (resources) that we can call. The first method is an HTTP GET call to the /conferences endpoint. The second method is also an HTTP GET, and it passes an argument as part of the url to get a single conference.

Once we have the interface defined, using it is as easy as this:

var tekconfApi = RestService.For<ITekConfApi>("http://api.tekconf.com/v1");

var conferences = await tekconfApi.GetConferences();

var codemash = await tekconfApi.GetConference("codemash-2016");  

Fast response for our users

Akavache

Install-Package Akavache

Now that we have an easy way to access the service, we can concentrate on the user experience. The performance of a mobile app, from a user's perspective, is critical. It doesn't even necessarily matter if your app IS fast, just that the user THINKS it's fast.

The best way to speed up a network call is to simply not make the network call in the first place. Loading data from our local device is exponentially faster than calling out over a network, especially when we're on a mobile device connecting through slow cellular connections. Here, we can use the common technique of caching our data. When the page loads and requests the data to display, we want to immediately load the cached data from our device and return it to the page. From the user's perspective, the page will render instantly. In the meantime, we want to call out to the remote service, get the data, and cache it. Since the user is no longer waiting for this call to return, we can execute it at our leisure and buy ourselves some extra time for processing.

While we could possibly write all of this caching logic ourselves, we will instead add a Nuget package named Akavache. From the Akavache site:

Akavache is an asynchronous, persistent (i.e. writes to disk) key-value store created for writing desktop and mobile applications in C#, based on SQLite3. Akavache is great for both storing important data (i.e. user settings) as well as cached local data that expires.

public async Task<List<ConferenceDto>> GetConferences()  
{
    var cache = BlobCache.LocalMachine;
    var cachedConferences = cache.GetAndFetchLatest("conferences", GetRemoteConferencesAsync,
        offset =>
        {
            TimeSpan elapsed = DateTimeOffset.Now - offset;
            return elapsed > new TimeSpan(hours: 0, minutes: 30, seconds: 0);
        });

    var conferences = await cachedConferences.FirstOrDefaultAsync();
    return conferences;
}

We can use the Akavache method GetAndFetchLatest to immediately return our cached conferences, if there are any. At the same time, we set up a call to our GetRemoteConferencesAsync method, which will actually make the call to the remote service if the specified expiration TimeSpan has elapsed.

ModernHttpClient

Install-Package ModernHttpClient

Although we'd like to always get our data from the cache, we will of course still need to call the remote service at some point. On the Xamarin stack, we run into an issue though. By default, Mono (and therefore Xamarin) uses the Mono networking stack. This works, but Apple and Google have spent a lot of time optimizing the networking stack on their respective platforms, and when we use HttpClient we're bypassing those optimazations completely. We can fix this by adding ModernHttpClient

This library brings the latest platform-specific networking libraries to Xamarin applications via a custom HttpClient handler. Write your app using System.Net.Http, but drop this library in and it will go drastically faster.

var client = new HttpClient(new NativeMessageHandler())  
{
    BaseAddress = new Uri(apiBaseAddress)
};

return RestService.For<ITekConfApi>(client);  

By passing NativeMessageHandler into the constructor of HttpClient, we will automatically use the appropriate stack on each platform.

Fusillade

Install-Package Fusillade

From the user's perspective, not every network request is equal. Requests that are initiated from a user action should have a higher priority than requests that the app decides to kick off. Remember that our goal is to make the user feel like the app is responding quickly.

Fusillade is another Nuget package that we're going to use to provide the following features.

  • Auto-deduplication of requests
  • Request Limiting
  • Request Prioritization
  • Speculative requests
public class ApiService : IApiService  
{
    public const string ApiBaseAddress = "http://api.tekconf.com/v1";

    public ApiService(string apiBaseAddress = null)
    {
        Func<HttpMessageHandler, ITekConfApi> createClient = messageHandler =>
        {
            var client = new HttpClient(messageHandler)
            {
                BaseAddress = new Uri(apiBaseAddress ?? ApiBaseAddress)
            };

            return RestService.For<ITekConfApi>(client);
        };

        _background = new Lazy<ITekConfApi>(() => createClient(
            new RateLimitedHttpMessageHandler(new NativeMessageHandler(), Priority.Background)));

        _userInitiated = new Lazy<ITekConfApi>(() => createClient(
            new RateLimitedHttpMessageHandler(new NativeMessageHandler(), Priority.UserInitiated)));

        _speculative = new Lazy<ITekConfApi>(() => createClient(
            new RateLimitedHttpMessageHandler(new NativeMessageHandler(), Priority.Speculative)));
    }

    private readonly Lazy<ITekConfApi> _background;
    private readonly Lazy<ITekConfApi> _userInitiated;
    private readonly Lazy<ITekConfApi> _speculative;

    public ITekConfApi Background
    {
        get { return _background.Value; }
    }

    public ITekConfApi UserInitiated
    {
        get { return _userInitiated.Value; }
    }

    public ITekConfApi Speculative
    {
        get { return _speculative.Value; }
    }
}

Now, instead of just using the HttpClient, we have an ApiService class which will have three instances of the Refit api, for UserInitiated, Background, and Speculative requests.

When the page first loads, we will automatically try to get the conference data. Because the user did not initiate this call, we can prioritize this request to run in the background.

var conferences = await _conferencesService  
                        .GetConferences(Priority.Background)
                        .ConfigureAwait(false);

If the user chooses to click the refresh button, then we could run this same call with a different priority.

var conferences = await _conferencesService  
                        .GetConferences(Priority.UserInitiated)
                        .ConfigureAwait(false);

When the conferences return, we might assume that the user will probably click on one of the conferences in the list to see the details of that conference. Since we are just guessing that this might occur, we can schedule a request to get the conference details using the speculative priority.

foreach (var slug in conferences.Select(x => x.Slug))  
{
    _conferencesService.GetConference(Priority.Speculative, slug);
}

A side note from Paul Betts : "If you use the Speculative priority, you need to call ResetLimit on mobile to reset the 5MB data fetch limit when you navigate pages (this isn’t a strict rule, but it’s a good approximation - basically when you know the user is “Starting A New Session”). Speculative is definitely one thing that many apps won’t need - think a Reddit app where you could try to fetch every item on the page, but you don’t actually want to do that, just maybe make a guess as to what the user might read. Then the dev can be lazy and just be like “Fetch it all, Yolo” and Fusillade will cut them off automatically based on the content size itself."

Work offline

Unlike desktop applications, our mobile apps are expected to have some functionality while disconnected from the network. The worst thing that we could do is to crash when we try to make a network request. The best thing that we could do is to continue working so that the user didn't even notice that the network was down.

Connectivity

Install-Package Xam.Plugin.Connectivity

If we want to make sure that we don't cause an exception by making a request when the network is disconnected, then we need a way of checking the status of the connection. Each platform has its own way of performing this check, but we want to use this in a cross platform way in our PCL classes.

Connectivity is a Xamarin plugin that let's us do just that.

Simple cross platform plugin to check connection status of mobile device, gather connection type, bandwidths, and more.

Before making a network request, we can just check if the device is connected.

if (CrossConnectivity.Current.IsConnected)  
{
    conferences = await _apiService.Background.GetConferences();
}
return conferences;  

Akavache

We've already seen how Akavache allows us to continue working while offline by caching the results of the requests locally. By combining Akavache and Fusillade's speculative calls, we can proactively cache as much data as possible while connected. If the network is disconnected, the app will continue to function in a read only manner.

Handle errors

In a perfect world, our code would work correctly all the time, every time. It's not a perfect world. Networks go down. Services throw errors. Code crashes. Some of these errors are permanent, but a large number are transient errors. Cell networks are notoriously flaky, and APIs have intermittent errors for a wide range of reasons.

Polly

Install-Package Polly

Polly is one of the most useful libraries I've used in a while. From the website:

Polly is a .NET 3.5 / 4.0 / 4.5 / PCL library that allows developers to express transient exception handling policies such as Retry, Retry Forever, Wait and Retry or Circuit Breaker in a fluent manner.

Polly allows us to very easily handle these types of errors in a consistent and coherent fashion. In this example, we will try connecting to our service five times, with an exponential wait of 2, 4, 8, 16, and 32 seconds between tries. This should give the device a chance to reestablish its network connection and continue the request to the api.

conferences = await Policy  
      .Handle<WebException>()
      .WaitAndRetry
      (
        retryCount:5, 
        sleepDurationProvider: retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))
      )
      .ExecuteAsync(async () => await getConferencesTask);

AsyncErrorHandler

Install-Package AsyncErrorHandler.Fody

Even with all the caching, retrying, and planning that we've put into the code, it will still fail at some point. We still want to make sure that when that happens, we handle it in a graceful manner.

In our mobile apps, it's imperative that we use async/await as much as possible to ensure that we're not blocking the UI thread while we do things like make network requests. Handling exceptions from async methods can be tricky.

Adding AsyncErrorHandler allows us to handle these exceptions in a global way, to ensure that they don't terminate our app.

More

We could go even further in architecting our code to handle our network requests. We would want to register each call as a BackgroundTask in iOS, or as a Service in Android to give each request the opportunity to complete even when the app gets sent to the background. We could introduce a queue, or some data syncronization component to allow us to update data while offline and sync with the server when a connection is reestablished. How far you want to go is up to you.

Fundamentally, mobile development introduces some issues that we haven't needed to really worry about in desktop development before. A mobile app that doesn't use remote services is an island with limited usefulness. A mobile app that uses remote services, but crashes when trying to access those services is useless. By using some really great libraries, we can ensure that our apps give our users the very best experience.

Thanks

In order to get any of this to work, I leveraged the hard work of other developers. Standing on the shoulders of giants.

Thanks to James Montemagno (Blog, Github) for the Connectivity Plugin.

Thanks to Michael Wolfenden (Github) for the amazing Polly framework.

Thanks to Simon Cropp (Github) for Fody and the AsyncErrorHandler

Thanks to Geoffrey Huntley (Blog, Github) for the code and inspiration for the ApiService with Fusillade and Refit

Many, many thanks to Paul Betts (Blog, Github) for his tremendous contributions to the Xamarin open source community, including Refit, Akavache, Fusillade, and ModernHttpClient.

Source Code

You can find a complete sample on my Github repo.

January 13, 2015 3:49 GMT

Xamarin.Forms Navigation Page

Besides the MasterDetail Page and TabbedPage, the Xamarin.Forms Navigation Page is the simplest of the three navigation aware pages in Xamarin.Forms. The Navigation Page makes it very easy to create a web browser like stack of pages for your cross-platform mobile app.

When a ContentPage is nested within a NavigationPage, the content page’s navigation property lights up or becomes not null. With access to the INavigation interface, our page can do things like push and pop new pages on the stack, push and pop modal pages, reshuffle the stack of pages or remove everything from the stack except the root page.

New Xamarin.Forms Navigation Page

To start the navigation stack all we have to do is pass a ContentPage into the NavigationPage constructor. The first page added to the Navigation Page is called the RootPage of the navigation stack.
new Xamarin.Forms Navigation Page

Push It

To add more pages, like clicking links in your browser all you have to do is push pages onto the stack of pages. With each successive push, the stack will get taller and taller. To add pages just call the current pages Navigation Properties PushAsync method with the new page.

Push Xamarin.Forms Navigation Page

Pop It

Clicking on the navigation pages back button will pop the current page from the stack revealing the page beneath it. Once you get all the way down to the root page the back button will not be available. You cannot pop the root page off the stack. The INavigation interface has a pop to root method that will remove all the pages of the stack except the root page.

Pop Xamarin.Forms Navigation Page

The Xamarin.Forms Navigation Page is implemented differently on the three platforms. On Android, the page just adds or removes content to or from a single activity. Performance and memory problems could occur if your stack is too tall.

The Windows Phone platform has a built in Navigation system. Therefore, you don’t need to use the NavigationPage. Lucky, Windows Phone.

The Navigation Page is the most used and the most familiar to our mobile application users. Developers that choose Navigation Page as a navigation mechanism will give their users a very familiar interface. Try out the Xamarin.Forms Navigation Page in your next app.

The post Xamarin.Forms Navigation Page appeared first on Syntax is my UI.

January 13, 2015 5:13 GMT

ModernHttpClient Pro Edition

For Enterprises, a paid version of ModernHttpClient is now available, which enables using ModernHttpClient with self-signed TLS/SSL certificates. You can find this version in the Xamarin Component Store.

Download ModernHttpClient Pro


How do I use this?

ModernHttpClient Pro works exactly the same as the Free version, with an additional method to enable untrusted certificates:

var handler = new NativeMessageHandler();  
handler.EnableUntrustedCertificates();  
var httpClient = new HttpClient(handler);  

What about the free version?

The free version of ModernHttpClient will always continue to be developed, and in fact, have all of the features available to the paid version, with the exception of the ability to use self-signed TLS certificates; the only reason to use the paid version is because you are not using properly signed certificates on your servers (or if you want to contribute to ModernHttpClient development monetarily).

FAQ:

  • Do I need the Pro Edition for development?

No, you can use HTTP for development, or host your service on a machine with a correctly configured certificate

  • Aren't TLS certificates expensive?

No, you can get them for as little as $10/yr, and many DNS providers and site hosts offer them for free, including Heroku.

  • What about my internal domain? I can't get a cert for that!

Not true, you can set up your own Root CA / Public Key Infrastructure, and issue and revoke certificates in a secure way for your internal organization.

January 12, 2015 4:10 GMT

Episode 21: Learning iOS with Reinder de Vries

Learning to write iOS apps can be a daunting task, especially if you’ve never written any code before. In this episode we’re joined by Reinder de Vries to talk about his approach to teaching people how to write iOS apps, and his experiences along the way.

Hosts: Greg Shackles, Jon Dick

Guests: Reinder de Vries

Links:

Thanks to our Sponsors!

Raygun.io

Raygun.io – Exceptional Error Tracking Raygun.io is the fastest and easiest way to track your application’s errors and get the level of detail you need to fix crashes quickly. Notifications are delivered right to your inbox and presented on a beautiful dashboard.

January 12, 2015 2:15 GMT

Building Your iOS User Interface with Xamarin and C#

Url: http://visualstudiomagazine.com/articles/2014/12/01/designing-uis.aspx

In September, Apple released the most recent version of iOS, iOS 8, and since then the iOS 8.1. The company also released two new phones -- the iPhone 6 with a 4.7-inch screen, and iPhone 6 Plus with a 5.5-inch screen -- and refreshed the iPad line with new versions of the iPad Air and iPad Mini. And those iPads, interestingly, have different screen resolutions and pixel densities than the iPhone. At the same time, Apple continues to sell older versions of its devices.

For developers, all these new releases represent the dreaded OS fragmentation that developers fear. How are developers going to handle the variations in old and new devices and screen sizes? Thankfully, Apple and Xamarin have thought this through and have created some flexible UI tools that I'll look at.

January 12, 2015 5:00 GMT

New and Improved Xamarin Studio Launcher

UPDATE - Jan 12, 2015: Thanks to the wonderful @Vaclav, Xamarin Studio Launcher now has a proper icon! Please download the much prettier v4 at the end of this post!

Awhile back I made a quick little AppleScript based app called Xamarin Studio Launcher to help launch multiple instances of Xamarin Studio (it had a pretty little icon that you could keep in your dock to open new instances - which I recently updated to the newer Xamarin look).

Xamarin Studio Launcher

While it was cute, and relatively functional, as a recovering ex-Windows user, I found myself still constantly opening .sln files from finder, which would cause them to open in an existing instance of Xamarin Studio, closing whatever current solution happened to be open in that instance.

Now I know about the ability to open multiple solutions in the same Xamarin Studio instance, and generally I’m pretty good about forcing myself into learning the nuances of the platform I’m working on, however, having multiple instances of Visual Studio open was something I grew so accustomed to that I just couldn’t shake the habit of being on a Mac!

Not sure why it took me so long to make this, but here it is, finally!

Xamarin Studio Launcher v3

This new launcher app works first and foremost exactly like the previous Xamarin Studio Launcher I released. You can put it in your dock, and when you open it, it will launch a new, blank instance of Xamarin Studio.

The new feature is that it can now handle opening .sln files. If you choose to open a .sln file with this app, it will open that .sln file in a new instance of Xamarin Studio.

This means you can set Finder to open all .sln files with Xamarin Studio Launcher so any time you double click or otherwise open a .sln file from Finder, it will open in its own instance of Xamarin Studio!

How to set this as the default app for .sln files

Xamarin Studio Launcher

  1. Find a .sln file in Finder
  2. Right click the .sln file and Get Info (or highlight the file and cmd + i
  3. Under the Open With section, click the drop-down list and click Choose
  4. Navigate to and select Xamarin Studio Launcher
  5. Click Change All

Download

Here’s the .zip file containing Xamarin Studio Launcher.app:

Download Xamarin Studio Launcher v4

January 11, 2015 7:45 GMT

Presenters in MvvmCross: Controlling the Back Stack

In my last presenter post I showed how you can use presentation hints to tell the presenter to clear the view stack prior to showing the next view. That is probably the most common custom navigation pattern I've seen used in MvvmCross apps, but I also wanted to note another similar pattern I've used as well.

When I'm mapping out the navigation paths through my apps, I try to be very conscious of the state of the back stack at any given time. Often navigation through an app is pretty linear which makes this a non-issue, but it's also easy to come across scenarios that are more problematic. Using our apps as an example, once you have a basket in progress the app will show you a persistent shortcut in the top bar that will bring you back to it from anywhere in the app. Once you do so, you end up on a screen that lets you perform some different actions, one of which is the option to return to the menu to add more items. During the initial flow through the app this would simply mean going back one screen in the stack, but if the user just jumped here from somewhere else, that view doesn't exist on the stack.

To solve this we introduced the presentation concept of navigating "back or in place". This tells the presenter to start by checking the back stack for the existence of a view of the same type we're navigating to. If found, it rewinds the stack back to that view. If not found, it pops the current view, then creates and navigates to the destination view. This allows us to map out any paths we want through the app without needing to sorry about showing the other views first.

Navigating with this mode is handled the same way shown in the last post:

var presentationBundle = new MvxBundle(new Dictionary<string, string> { { "NavigationMode", "BackOrInPlace" } });

ShowViewModel<MyViewModelType>(presentationBundle: presentationBundle);  

iOS

Here's what the implementation on iOS might look like:

public override void Show(MvxViewModelRequest request)  
{
    if (request.PresentationValues != null)
    {
        if (request.PresentationValues.ContainsKey("NavigationMode") && request.PresentationValues["NavigationMode"] == "BackOrInPlace")
        {
            var nextViewController = (UIViewController)_viewCreator.Value.CreateView(request);
            var existingViewController = MasterNavigationController.ViewControllers.FirstOrDefault(vc => vc.GetType() == nextViewController.GetType() && vc != CurrentTopViewController);

            if (existingViewController != null)
            {
                MasterNavigationController.PopToViewController(existingViewController, true);
            }
            else
            {
                var transition = new CATransition
                {
                    Duration = 0.3,
                    Type = CAAnimation.TransitionPush,
                    Subtype = CAAnimation.TransitionFade
                };

                MasterNavigationController.PopViewControllerAnimated(false);
                MasterNavigationController.View.Layer.AddAnimation (transition, null);
                MasterNavigationController.PushViewController(nextViewController, false);
            }

            return;
        }
    }

    base.Show(request);
}

In cases where the target view isn't already in the stack, this will provide a little fade transition into the new view, rather than making it look like a normal navigation push. I find this to be a nice visual cue to the user on what happened, and avoid the expectation that the previous view is still there on the back stack.

Android

The implementation looks pretty similar on Android, except that again we're using fragments to give us finer control over the stack:

public override void Show(MvxViewModelRequest request)  
{
    if (vmRequest.PresentationValues != null)
    {
        if (request.PresentationValues.ContainsKey("NavigationMode") && request.PresentationValues["NavigationMode"] == "BackOrInPlace")
        {
            var hasFragmentTypeInStack = 
                Enumerable.Range(0, _fragmentManager.BackStackEntryCount - 1)
                          .Reverse()
                          .Any(index => _fragmentManager.GetBackStackEntryAt(index).Name == fragmentType.Name);

            if (hasFragmentTypeInStack)
            {
                while (CurrentFragment.GetType() != fragmentType)
                    _fragmentManager.PopBackStackImmediate();

                return;
            }

            _fragmentManager.PopBackStackImmediate();
        }
    }

    // ...
}

This is just one example of what you might want to do with the back stack in your apps. I encourage you to think about the state of the stack as you build up navigation flows through your apps, in order to provide the most sensible experience possible for users.

January 09, 2015 8:20 GMT

Load More Items at End of ListView in Xamarin.Forms

I recently published a few blogs on how to add pull to refresh to your Xamarin.Forms iOS and Android applications. This sparked a question from another developer as to if you could swipe to load more at the bottom of the ListView. My feedback here is that a swipe to load more isn’t normal in mobile applications. A quick work around is to have a button as the final cell that is pressed to load more, but even better would be to detect when you user has hit the bottom of the screen and then load more items. So let’s do it!

ItemAppearing to the Rescue


In Xamarin.Forms it is actually extremely easy if you just subscribe to the ItemAppearing event in your code and check to see if the item that was visible is the last item in the list. I prefer to have a unique Id on each item that I would be checking here, but for this sample I will just check the string which is unique.





If you are looking to implement this in a traditional apps it is pretty simple as well. On iOS you already have the DataSource that you can look into when GetCell is called. On Android you can actually tie into the scroll events like I do in Meetup Manager.
January 09, 2015 3:20 GMT

Xamarin Insights : Unobtrusive mobile analytics

At the Xamarin Evolve 2014 conference, Xamarin announced their new mobile analytics solution, Xamarin Insights. When you add Insights to your mobile application, you can start tracking exceptions, crashes, user identities, and application events.

One of the best features of Insights is the ability to track the user's actions through the app to be able to trace the conditions that led to an exception. All too often, users will experience an error or, even worse, an app crash. Rarely, these users will email the developer and tell them about the crash, but don't remember any useful information that would help to recreate the exception. By adding calls Xamarin.Insights.Track() to our methods, we can track the events leading up to a particular crash.

Typical Usage

public async Task GetData ()  
{
    Xamarin.Insights.Track ("Enter GetData");

    /* Implement Method */

    Xamarin.Insights.Track ("Exit GetData");
}

private async Task GetLocalData ()  
{
    Xamarin.Insights.Track ("Enter GetLocalData");

    /* Implement Method */

    Xamarin.Insights.Track ("Exit GetLocalData");
}

private async Task GetRemoteData ()  
{
    Xamarin.Insights.Track ("Enter GetRemoteData");

    /* Implement Method */

    Xamarin.Insights.Track ("Exit GetRemoteData");
}

While this does work, it adds a lot of unnecessary noise to the code. Instead of adding line after line of analytics tracking to every method, I prefer to get that boilerplate code out of the way, and let the code focus on the problem at hand.

As I've shown before, I get a lot of use out of Fody in my mobile apps. Fody allows us to control the build time compilation and change the outputted assembly. In this case, we can use Fody's MethodDecorator package to move the Insights tracking logic into a method attribute.

Adding Fody

We'll base our custom attribute on Fody's MethodDecorator attribute, which we can add to our project from Nuget.

Install-Package MethodDecoratorEx.Fody

NOTE : There are two Fody MethodDecorators on Nuget. I'm using MethodDecoratorEx

You'll need to add the declaration to the FodyWeavers.xml file as well.

<?xml version="1.0" encoding="utf-8" ?>  
<Weavers>  
    <MethodDecoratorEx />
</Weavers>  

I wrote up instructions on using Fody with Xamarin Studio

Create Attribute

Next, we'll create a custom attribute to wrap up the Insights code. Each time we enter or leave a method, we'll make a call to Xamarin.Insights.Track().

using System;  
using System.Reflection;  
using MethodDecoratorInterfaces;  
using ArtekSoftware.Demos;  
using Xamarin;

[module: Insights]

namespace ArtekSoftware.Demos  
{
    [AttributeUsage (
            AttributeTargets.Method 
            | AttributeTargets.Constructor 
            | AttributeTargets.Assembly 
            | AttributeTargets.Module)]
    public class InsightsAttribute : Attribute, IMethodDecorator
    {
        private string _methodName;

        public void Init (object instance, MethodBase method, object[] args)
        {
            _methodName = method.DeclaringType.FullName + "." + method.Name;
        }

        public void OnEntry ()
        {
            var message = string.Format ("OnEntry: {0}", _methodName);
            Insights.Track (message);
        }

        public void OnExit ()
        {
            var message = string.Format ("OnExit: {0}", _methodName);
            Insights.Track (message);
        }

        public void OnException (Exception exception)
        {
            Insights.Report (exception);
        }
    }
}

Add Attribute to Methods

Once the attribute is defined, all we need to do is decorate the methods that we want to track. Notice that the implementation of each method is focused simply on the method's logic and not Insights tracking.

[Insights]
public async Task GetData ()  
{
    /* Implement Method */
}

[Insights]
private async Task GetLocalData ()  
{
    /* Implement Method */
}

[Insights]
private async Task GetRemoteData ()  
{
    /* Implement Method */
}

Performance

This may seem like a lot of extra overhead, especially since we're calling out to a remote server. I asked the Xamarin Insights team about this, and got the following answers.

  • When does Insights send its data?
    • If Insights detects a wifi connection then generally we feel free to send data as often as we like, if we are on a Cellular connection we wait a very long time before sending data
  • Does Insights.Track immediately call the server, or are the calls batched up?
    • All data is batched up for a few seconds before sending out to the server
  • Do Insights.Track and Insights.Report call the server asynchronously, or are these blocking calls?
    • All API calls are essentially async, any Insights activity happens in a background thread
  • If queued, does the queue persist across restarts of the app? Restarts of the device?
    • All insights data is journaled to disk, this means track/identify/report/crashes/everything is persistent across restarts. We send out the old data whenever we have a good opportunity to do so, usually after we send out some new data successfully.

Results

The end result of this is that we get really detailed tracking of the events that lead to an exception. This will make finding and fixing errors in our apps faster and more efficient. We get the details of constant tracking without littering our code with tracking calls.

January 09, 2015 3:20 GMT

Clean ViewModels with Xamarin.Forms

I like to keep my view models focused on just the code needed for a particular view, and to keep as much plumbing and infrastructure code out of the view model as possible. I've already covered how to use Fody to implement INotifyPropertyChanged and use auto properties in our view models. Now I want to cover how to connect the ViewModel to the View automatically.

The most straight forward way to access our view model would be to simply instantiate it in the constructor of our view.

using Xamarin.Forms;

namespace CleanViewModels
{    
    public partial class UserPage : ContentPage
    {   
        UserViewModel _viewModel;
        public UserPage ()
        {
            InitializeComponent ();
            _viewModel = new UserViewModel ();
            BindingContext = _viewModel;
        }
    }
}

This technique requires us to add this bit of code to every view that uses a view model though. I'd prefer to have that handled automatically for each view.

View Model

Let's begin by creating a marker interface for our view model. At its simplest, this interface is just used to constrain the generic type later.

namespace CleanViewModels  
{
    public interface IViewModel {}
}

Each of our view models will need to implement our marker interface.

using PropertyChanged;
using System.Windows.Input;
using Xamarin.Forms;

namespace CleanViewModels
{
    [ImplementPropertyChanged]
    public class UserViewModel : IViewModel
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }

        public ICommand LoadUser {
            get {
                return new Command (async () => {
                    this.FirstName = "John";
                    this.LastName = "Doe";
                });
            }
        }
    }
}

View Page

Now that we have the ViewModel defined, we can wire it up to the View. We'll create a new class, named ViewPage.cs. This will be our base class for each view. We will derive ViewPage from ContentPage and pass in the type of our view model. In the constructor, we will create a new instance of the requested ViewModel and set the view's BindingContext to the current ViewModel. We also provide a read only property to be able to access the view model in the page, if needed.

using Xamarin.Forms;

namespace CleanViewModels
{
    public class ViewPage<T> : ContentPage where T:IViewModel, new()
    {
        readonly T _viewModel; 

        public T ViewModel
        {
            get {
                return _viewModel;
            }
        }

        public ViewPage ()
        {
            _viewModel = new T ();
            BindingContext = _viewModel;
        }
    }
}

View

When using XAML in Xamarin.Forms, I was not able to set the root to use ViewPage<T> directly. Instead, we will create a wrapper class that defines the parameter for us, so that we can use the wrapper class in XAML.

namespace CleanViewModels
{    
    public class UserPageBase :  ViewPage<UserViewModel> {}

    public partial class UserPage : UserPageBase
    {   
        public UserPage ()
        {
            InitializeComponent ();
        }
    }
}

Once the code behind is defined, we can add our xml namespace local: and create our view in XAML as UserPageBase

<?xml version="1.0" encoding="UTF-8"?>  
<local:UserPageBase  
    xmlns="http://xamarin.com/schemas/2014/forms" 
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" 
    x:Class="CleanViewModels.UserPage" 
    xmlns:local="clr-namespace:CleanViewModels;assembly=CleanViewModels">

    <ContentPage.Padding>
        <OnPlatform 
            x:TypeArguments="Thickness" 
            iOS="5,20,5,5" 
            Android="5,0,5,5" 
            WinPhone="5,0,5,5" />
    </ContentPage.Padding>

    <StackLayout>
        <Entry Text="{ Binding FirstName, Mode=TwoWay }" />
        <Entry Text="{ Binding LastName, Mode=TwoWay }" />

        <Button 
          Text="Load User"
          Command="{Binding LoadUser}"></Button>
    </StackLayout>
</local:UserPageBase>  

By using a base view page, along with Fody, we are able to keep our view models clean and focused only on the properties and commands that are needed for the view, thereby increasing the readability of the code.

Check out the sample project on my Github repo.

January 09, 2015 3:20 GMT

Adding a Windows Phone Project to an Existing Xamarin.Forms Solution

So, you've fired up Xamarin Studio, created a new Xamarin.Forms app for iOS and Android and your app is super successful. Now that the two major platforms are coded and deployed to their respective app stores, you'd like to add Windows Phone as well.

This is where Xamarin and particularly Xamarin.Forms really shines. It's possible to have your app running on a whole new platform in a matter of minutes.

Xamarin Studio does not support Windows Phone projects, so in order to create a new Windows Phone project, we will need to be using Xamarin Business Edition in Visual Studio on Windows. The .sln file is exactly the same between Xamarin Studio and Visual Studio and can be opened in either IDE. Simply commit your solution to source control on your Mac, pull it down on Windows, and open it in Visual Studio.

Add Windows Phone Project

Add Project -> Blank App (Windows Phone Silverlight)

At this point, we will only have iOS and Android projects so the first step is to add a Windows Phone project.

Right click on the solution and choose Add New Project. From the dialog, choose Visual C# -> Store Apps -> Windows Phone Apps -> Blank App (Windows Phone Silverlight)

Create the project in the existing solution folder, and give the project the extension .WinPhone (this is optional, but adheres to what the Xamarin.Forms wizard would have created).

Next, we'll get a wizard dialog asking which version of the Windows Phone SDK we want to use. The Xamarin.Forms wizard creates a Windows Phone 8.0 project, so we'll choose that same version here.

This will create the Windows Phone project for us and add it to the solution.

Add Xamarin.Forms

Now that the project is created, all we need to do is connect the Windows Phone project to our Xamarin.Forms app. This has two steps. First, we need to add the Xamarin.Forms Nuget packages to our Windows Phone project. When the Nuget package is installed, it creates a new folder named Toolkit.Content. We need to make sure that the files in this folder are set to Content/Copy Always.

Install-Package Xamarin.Forms

Next, we need to add a reference to our shared code project, which will be either a PCL or a Shared Project. This will allow us to access all of the Xamarin.Forms UI that we have already created.

Edit MainPage.xaml

The last task that we need to do is to change the XAML and the C# that was generated by default. With Xamarin.Forms, we won't be defining our UI in the platform specific projects, but we do need the MainPage to initialize the Xamarin.Forms framework for us.

All we need in the MainPage.xaml file is the following XAML.

<phone:PhoneApplicationPage  
    x:Class="SuperSuccessfulApp.WinPhone.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
    xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    FontFamily="{StaticResource PhoneFontFamilyNormal}"
    FontSize="{StaticResource PhoneFontSizeNormal}"
    Foreground="{StaticResource PhoneForegroundBrush}"
    SupportedOrientations="Portrait" Orientation="Portrait"
    shell:SystemTray.IsVisible="True">
</phone:PhoneApplicationPage>  

Note : Be sure to change the x:Class attribute to your namespace

In the MainPage.xaml.cs file, add the following C#.

using Microsoft.Phone.Controls;  
using Xamarin.Forms;

namespace SuperSuccessfulApp.WinPhone  
{
    public partial class MainPage : PhoneApplicationPage
    {
        public MainPage()
        {
            InitializeComponent();

            Forms.Init();
            Content = SuperSuccessfulApp.App.GetMainPage().ConvertPageToUIElement(this);
        }
    }
}

Note : Be sure to change the relevant namespaces

At this point, we have a funtioning Windows Phone app, leveraging all of the work that we previously did for iOS and Android. The only remaining tasks would be to implement any custom renderers and/or platform specific interfaces, and add the appropriate icons and images.

January 09, 2015 3:20 GMT

Android's Built-in List Item Layouts

Android's List View allows us to iterate over an enumerable collection and display each piece of data in a list item. The list view works in conjunction with an adapter to loop over the data and display the data in a layout. We could, and often do, create our own layouts for this purpose. Customizing the layout allows us to match the list view's look and feel to the rest of our app, and to tailor the fields and controls that are shown.

For the times where we just want to display some simple data on the screen though, Android does include some built-in list item layouts. I was having a hard time finding any good documentation of these built-in layouts, so I have created a sample app displaying as many of the layouts as I could figure out. The app is written using Xamarin.Android.

All of the code is available from my Github repo

ArrayAdapter with SimpleListItem1

The simplest adapter to use is the built-in ArrayAdapter, using the built-in Android.Resource.Layout.SimpleListItem1 layout. This layout contains a single TextView, allowing display of a single piece of text.

using System;  
using Android.App;  
using Android.OS;  
using Android.Widget;

namespace ListViewDemo  
{
    [Activity (Label = "ExampleActivity")]
    public class ExampleActivity : ListActivity
    {
        protected override void OnCreate (Bundle savedInstanceState)
        {
            base.OnCreate (savedInstanceState);

            var kittens = new [] { "Fluffy", "Muffy", "Tuffy" };

            var adapter = new ArrayAdapter (
                                this, //Context, typically the Activity
                                Android.Resource.Layout.SimpleListItem1, //The layout. How the data will be presented 
                                kittens //The enumerable data
                            );

            this.ListAdapter = adapter;
        }
    }
}

The other layouts include (with the controls available)

Android.Resource.Layout.ActivityListItem

  • 1 ImageView (Android.Resource.Id.Icon)
  • 1 TextView (Android.Resource.Id.Text1)

Android.Resource.Layout.SimpleListItem1

  • 1 TextView (Android.Resource.Id.Text1)

Android.Resource.Layout.SimpleListItem2

  • 1 TextView/Title (Android.Resource.Id.Text1)
  • 1 TextView/Subtitle (Android.Resource.Id.Text2)

Android.Resource.Layout.SimpleListItemActivated1

  • 1 TextView (Android.Resource.Id.Text1)
  • Note : Set choice mode to multiple or single
  this.ListView.ChoiceMode = ChoiceMode.Multiple;

Android.Resource.Layout.SimpleListItemActivated2

  • 1 TextView (Android.Resource.Id.Text1)
  • 1 TextView/Subtitle (Android.Resource.Id.Text2)
  • Note : Set choice mode to multiple or single
  this.ListView.ChoiceMode = ChoiceMode.Multiple;

Android.Resource.Layout.SimpleListItemChecked

  • 1 TextView (Android.Resource.Id.Text1)
  • Note : Set choice mode to multiple or single
  this.ListView.ChoiceMode = ChoiceMode.Multiple;

Android.Resource.Layout.SimpleListItemMultipleChoice

  • 1 TextView (Android.Resource.Id.Text1)
  • Note : Set choice mode to multiple or single
  this.ListView.ChoiceMode = ChoiceMode.Multiple;

Android.Resource.Layout.SimpleListItemSingleChoice

  • 1 TextView (Android.Resource.Id.Text1)
  • Note : Set choice mode to single
  this.ListView.ChoiceMode = ChoiceMode.Single;

Android.Resource.Layout.TestListItem

  • 1 TextView (Android.Resource.Id.Text1)

Android.Resource.Layout.TwoLineListItem

  • 1 TextView/Title (Android.Resource.Id.Text1)
  • 1 TextView/Subtitle (Android.Resource.Id.Text2)

Again, checkout the Xamarin.Android sample app on my Github repo to see these list view layouts in action.

January 09, 2015 3:19 GMT

Gesture Recognizers with Xamarin.Forms

iOS and Android apps both provide a way to wire up a UI control to listen for specific touch events. These events are called gestures. Typically, we would use this to listen for a tap (click) gesture, or maybe a swipe or fling gesture.

In a native Xamarin.iOS or Xamarin.Android app, wiring up these events is fairly straight forward. As of this writing though (July, 2014), Xamarin.Forms only has cross platform support for the tap gesture. Just because all of the gesture recognizers aren't wrapped for Xamarin.Forms does not mean that we can not use them though. By using custom renderers, we are able to get access to the native controls and wire up our gesture recognizer just as we would in a native Xamarin app.

I have created a sample app in my Github repo to demonstrate how we can use the simplicity of Xamarin.Forms and still have the power of built in gesture recognizers.

Sample App

We'll start with a new Xamarin.Forms app. This can be a Shared Project or a Portable project (the sample app is a Shared Project). For this sample, we're going to wire up a Label control to listen for the touch events.

To be able to use a custom renderer, we'll need to subclass Label in our shared code.

using Xamarin.Forms;

namespace XamarinFormsGestureRecognizers  
{
    public class FancyLabel : Label {}
}

In our App.cs we'll set the Content of our Page to a new FancyLabel. Since the TapGestureRecognizer is already built in to Xamarin.Forms, we'll wire that one up here in our shared code.

using Xamarin.Forms;  
using System;

namespace XamarinFormsGestureRecognizers  
{
    public static class App
    {
        public static Page GetMainPage ()
        {   
            var fancyLabel = new FancyLabel {
                Text = "Hello, Forms!",
                VerticalOptions = LayoutOptions.CenterAndExpand,
                HorizontalOptions = LayoutOptions.CenterAndExpand,
            };

            var tapGestureRecognizer = new TapGestureRecognizer ();
            tapGestureRecognizer.Tapped += (sender, e) => Console.WriteLine ("Tapped");
            fancyLabel.GestureRecognizers.Add (tapGestureRecognizer);

            return new ContentPage { 
                Content = fancyLabel
            };
        }
    }
}

Now we need to implement our custom renderers for each platform.

iOS

We'll add a new file named FancyIosLabelRenderer.cs to the iOS project and add a class derived from Xamarin.Forms' LabelRenderer.

using Xamarin.Forms;  
using Xamarin.Forms.Platform.iOS;  
using MonoTouch.UIKit;  
using System;  
using XamarinFormsGestureRecognizers;  
using XamarinFormsGestureRecognizers.iOS;

namespace XamarinFormsGestureRecognizers.iOS  
{
    public class FancyIosLabelRenderer : LabelRenderer
    {
        protected override void OnElementChanged (ElementChangedEventArgs<Label> e)
        {
            base.OnElementChanged (e);
        }
    }
}

The renderer class itself is a view that wraps the native control. While we could wire up the recognizer to the control itself, it's better to simply wire it up to the renderer's view. Since the renderers can be reused, we also need to be sure to only create the gesture recognizers if the OldElement is null (when we're not reusing the control).

public class FancyIosLabelRenderer : LabelRenderer  
    {
        UILongPressGestureRecognizer longPressGestureRecognizer;
        UIPinchGestureRecognizer pinchGestureRecognizer;
        UIPanGestureRecognizer panGestureRecognizer;
        UISwipeGestureRecognizer swipeGestureRecognizer;
        UIRotationGestureRecognizer rotationGestureRecognizer;

        protected override void OnElementChanged (ElementChangedEventArgs<Label> e)
        {
            base.OnElementChanged (e);

            longPressGestureRecognizer = new UILongPressGestureRecognizer (() => Console.WriteLine ("Long Press"));
            pinchGestureRecognizer = new UIPinchGestureRecognizer (() => Console.WriteLine ("Pinch"));
            panGestureRecognizer = new UIPanGestureRecognizer (() => Console.WriteLine ("Pan"));
            swipeGestureRecognizer = new UISwipeGestureRecognizer (() => Console.WriteLine ("Swipe"));
            rotationGestureRecognizer = new UIRotationGestureRecognizer (() => Console.WriteLine ("Rotation"));

            if (e.NewElement == null) {
                if (longPressGestureRecognizer != null) {
                    this.RemoveGestureRecognizer (longPressGestureRecognizer);
                }
                if (pinchGestureRecognizer != null) {
                    this.RemoveGestureRecognizer (pinchGestureRecognizer);
                }
                if (panGestureRecognizer != null) {
                    this.RemoveGestureRecognizer (panGestureRecognizer);
                }
                if (swipeGestureRecognizer != null) {
                    this.RemoveGestureRecognizer (swipeGestureRecognizer);
                }
                if (rotationGestureRecognizer != null) {
                    this.RemoveGestureRecognizer (rotationGestureRecognizer);
                }
            }

            if (e.OldElement == null) {
                this.AddGestureRecognizer (longPressGestureRecognizer);
                this.AddGestureRecognizer (pinchGestureRecognizer);
                this.AddGestureRecognizer (panGestureRecognizer);
                this.AddGestureRecognizer (swipeGestureRecognizer);
                this.AddGestureRecognizer (rotationGestureRecognizer);
            }
        }
    }

Lastly, we need to be sure that we wire up the custom renderer to look for instances of the FancyLabel class.

[assembly: ExportRenderer (typeof(FancyLabel), typeof(FancyIosLabelRenderer))]

Android

Using the gesture recognizers in Android will be similar, but with a bit more work. Xamarin's documentation explains how to use a GestureDetector in an Android app, which is what we'll do here.

Once again, we'll add a new file called FancyAndroidLabelRenderer.cs to hold our custom renderer.

using Xamarin.Forms.Platform.Android;  
using Xamarin.Forms;  
using XamarinFormsGestureRecognizers;  
using XamarinFormsGestureRecognizers.Droid;  
using Android.Views;

namespace XamarinFormsGestureRecognizers.Droid  
{
    public class FancyAndroidLabelRenderer : LabelRenderer
    {
        public FancyAndroidLabelRenderer ()
        {
        }

        protected override void OnElementChanged (ElementChangedEventArgs<Label> e)
        {
            base.OnElementChanged (e);
        }
    }
}

We'll also add a class named FancyGestureListener.cs and we'll add gesture listener. Here we'll subclass the built in SimpleOnGestureListener to provide most of the functionality.

using Android.Views;  
using System;

namespace XamarinFormsGestureRecognizers.Droid  
{
    public class FancyGestureListener : GestureDetector.SimpleOnGestureListener
    {
        public override void OnLongPress (MotionEvent e)
        {
            Console.WriteLine ("OnLongPress");
            base.OnLongPress (e);
        }

        public override bool OnDoubleTap (MotionEvent e)
        {
            Console.WriteLine ("OnDoubleTap");
            return base.OnDoubleTap (e);
        }

        public override bool OnDoubleTapEvent (MotionEvent e)
        {
            Console.WriteLine ("OnDoubleTapEvent");
            return base.OnDoubleTapEvent (e);
        }

        public override bool OnSingleTapUp (MotionEvent e)
        {
            Console.WriteLine ("OnSingleTapUp");
            return base.OnSingleTapUp (e);
        }

        public override bool OnDown (MotionEvent e)
        {
            Console.WriteLine ("OnDown");
            return base.OnDown (e);
        }

        public override bool OnFling (MotionEvent e1, MotionEvent e2, float velocityX, float velocityY)
        {
            Console.WriteLine ("OnFling");
            return base.OnFling (e1, e2, velocityX, velocityY);
        }

        public override bool OnScroll (MotionEvent e1, MotionEvent e2, float distanceX, float distanceY)
        {
            Console.WriteLine ("OnScroll");
            return base.OnScroll (e1, e2, distanceX, distanceY);
        }

        public override void OnShowPress (MotionEvent e)
        {
            Console.WriteLine ("OnShowPress");
            base.OnShowPress (e);
        }

        public override bool OnSingleTapConfirmed (MotionEvent e)
        {
            Console.WriteLine ("OnSingleTapConfirmed");
            return base.OnSingleTapConfirmed (e);
        }
    }
}

Then, we need to wire up this listener to our renderer, and include the ExportRenderer attribute.

using Xamarin.Forms.Platform.Android;  
using Xamarin.Forms;  
using XamarinFormsGestureRecognizers;  
using XamarinFormsGestureRecognizers.Droid;  
using Android.Views;

[assembly: ExportRenderer (typeof(FancyLabel), typeof(FancyAndroidLabelRenderer))]

namespace XamarinFormsGestureRecognizers.Droid  
{
    public class FancyAndroidLabelRenderer : LabelRenderer
    {
        private readonly FancyGestureListener _listener;
        private readonly GestureDetector _detector;

        public FancyAndroidLabelRenderer ()
        {
            _listener = new FancyGestureListener ();
            _detector = new GestureDetector (_listener);

        }

        protected override void OnElementChanged (ElementChangedEventArgs<Label> e)
        {
            base.OnElementChanged (e);

            if (e.NewElement == null) {
                if (this.GenericMotion != null) {
                    this.GenericMotion -= HandleGenericMotion;
                }
                if (this.Touch != null) {
                    this.Touch -= HandleTouch;
                }
            }

            if (e.OldElement == null) {
                this.GenericMotion += HandleGenericMotion;
                this.Touch += HandleTouch;
            }
        }

        void HandleTouch (object sender, TouchEventArgs e)
        {
            _detector.OnTouchEvent (e.Event);
        }

        void HandleGenericMotion (object sender, GenericMotionEventArgs e)
        {
            _detector.OnTouchEvent (e.Event);
        }
    }   
}

Checkout the sample app on my Github repo to get started with Xamarin.Forms and gestures.

January 09, 2015 3:19 GMT

IoC Containers with Xamarin

When writing cross platform apps with Xamarin, our goal is share as close to 100% of our code across all the platforms. While this is an admirable goal to aim for, it is not realistic. Very often, we find ourselves needing to access a platform specific feature from our shared code. We have multiple options in this case. We could use a Shared Project with compiler directives, class mirroring, or partial classes and access the platform code alongside our shared code. Alternatively we could use an abstraction for the functionality in our shared code, and pass an implementation of the abstraction into our shared code. In this way, our shared code only needs to know about the abstraction, typically an interface. This strategy, known as Inversion of Control or IoC, works especially well when using Portable Class Libraries (PCL) for our shared code.

Even when using IoC, manually managing all of our dependencies, including instantiating the dependency tree for an object, can be tedious at best. This is where we turn to a host of existing IoC containers. The .net ecosystem has long had a wealth of choices in IoC containers. Some of the more popular ones include StructureMap, Castle Windsor, Ninject, Unity, and Autofac. These are by no means the only choices, up to and including rolling our own.

Not all of these containers are able to run in limitations imposed by mobile devices though. Phones and tablets have constrained cpu and memory, and iOS devices forbid JIT compiling and certain uses of reflection. Additionally, the library authors have to specifically compile for Xamarin.iOS and Xamarin.Android, either individually or as part of a PCL.

I decided to put together some sample code showing how the Xamarin-compatible IoC containers work. As of this writing (July, 2014) I have limited the comparison only to IoC containers that 1) I could get to work successfully and 2) had an available Nuget package for easy installation. I did not want to go through the process of pulling individual repositories and building the source from scratch, although that is a valid option. This excluded some options that I do want to mention as alternatives.

  • Xamarin.Forms Dependency Service. This is really more of a Service Locator than it is an IoC container. Also, it is only available as part of Xamarin.Forms.
  • OpenNetCF. There is no nuget package for this library. Also, it requires custom attributes be added to the shared code, diminishing the usefulness.
  • XPlatUtils. There is no nuget package for this library.

The libraries that I focused on were Autofac, MvvmCross, Ninject, TinyIoc, and Unity.

All of the code is available from my Github Repo

Sample Project

In the sample project, we have a single IoCDemo.Core project. This project contains the interface abstractions for our platform specific projects (ISettings and IPlatform) and a concrete ViewModel (MainViewModel) which takes the two interfaces as constructor dependencies. For each library, I created an iOS and an Android project to demonstrate wiring up the dependencies to platform specific implementations and creating the view model. Each container will be wired up in an App.cs file in each platform.

Some of the IoC containers have the ability to scan your assemblies and automatically wire up your dependecies. I chose not to use this ability. In a mobile app, every bit of cpu power is precious. I would rather spend the extra few seconds to write the code to wire up the dependency once at development time than have the app scan the assemblies every single time it is started.

Autofac

Install-Package Autofac

Wiring up the container

using Autofac;  
using IoCDemo.Core;

namespace AutoFacDemo.iOS  
{
    public class App
    {
        public static IContainer Container { get; set; }

        public static void Initialize()
        {
            var builder = new ContainerBuilder();

            builder.RegisterInstance(new ApplePlatform()).As<IPlatform>();
            builder.RegisterInstance(new AppleSettings()).As<ISettings>();
            builder.RegisterType<MainViewModel> ();

            App.Container = builder.Build ();
        }
    }
}

Resolving the view model

MainViewModel viewModel = null;

using (var scope = App.Container.BeginLifetimeScope ()) {  
    viewModel = App.Container.Resolve<MainViewModel> ();
}

MvvmCross

Install-Package MvvmCross.HotTuna.CrossCore

Wiring up the container

using Cirrious.CrossCore;  
using IoCDemo.Core;  
using Cirrious.CrossCore.IoC;

namespace MvvmCrossDemo.iOS  
{
    public static class App
    {
        public static void Initialize ()
        {
            MvxSimpleIoCContainer.Initialize ();
            Mvx.RegisterType<IPlatform, ApplePlatform> ();
            Mvx.RegisterType<ISettings, AppleSettings> ();
        }
    }
}

Resolving the view model

var viewModel = Mvx.IocConstruct<MainViewModel> ();  

Ninject

Install-Package Portable.Ninject

Wiring up the container

using Ninject;

namespace NinjectDemo.iOS  
{
    public static class App
    {
        public static StandardKernel Container { get; set; }

        public static void Initialize()
        {
            var kernel = new Ninject.StandardKernel(new NinjectDemoModule());           

            App.Container = kernel;
        }
    }
}

Resolving the view model

var viewModel = App.Container.Get<MainViewModel> ();  

TinyIoc

Install-Package TinyIoc

Wiring up the container

using TinyIoC;  
using IoCDemo.Core;

namespace TinyIoCDemo.iOS  
{
    public static class App
    {
        public static void Initialize ()
        {
            var container = TinyIoCContainer.Current;

            container.Register<IPlatform, ApplePlatform> ();
            container.Register<ISettings, AppleSettings> ();
        }
    }
}

Resolving the view model

var viewModel = TinyIoC.TinyIoCContainer.Current.Resolve<MainViewModel> ();  

Unity

Install-Package Unity

Wiring up the container

using Microsoft.Practices.Unity;  
using IoCDemo.Core;

namespace UnityDemo.iOS  
{
    public class App
    {
        public static UnityContainer Container { get; set; }

        public static void Initialize()
        {
            App.Container = new UnityContainer();
            App.Container.RegisterType<IPlatform, ApplePlatform> ();
            App.Container.RegisterType<ISettings, AppleSettings> ();
        }
    }
}

Resolving the view model

var viewModel = App.Container.Resolve (typeof(MainViewModel), "mainViewModel") as MainViewModel;  

Again, checkout the sample app on my Github repo to compare our IoC container choices for Xamarin.

January 09, 2015 3:19 GMT

Custom UITableViewCells with Xamarin and XIBs

Sometimes when we are creating an iOS app with Xamarin, we choose to forego using the Storyboard designer, and simply create the user interface in C#. This works fine, but when using a UITableView, there are times when we want to design the UITableViewCell with the designer. Luckily, this is easy enough to do using a single .xib file in Xamarin Studio.

I have created a sample project in my Github repo to demonstrate using a .xib file to design our cell.

Create the project

For this sample, we will start off with the Empty Project template.

File -> New Solution -> iOS -> iPhone -> Empty Project

Create the table view

Next, add a new class for the UITableViewController, cleverly named MyTableViewController.cs. In the AppDelegate.cs, set the RootViewController to our new class. In MyTableViewController, we'll load our data and wire the TableView.Source to MyTableViewSource.

public override void ViewDidLoad ()  
{
    base.ViewDidLoad ();

    var conferences = ConferenceRepository.GetConferences ();

    TableView.Source = new MyTableViewSource (conferences);
}

Create the cell

At this point, we have not used a designer for any of our UI. In fact, we don't even have a .storyboard or .xib in our project. In order to design our table view cell, we're going to add one now. We'll add a new file using the iPhone Table View Cell template, and name it MyCustomCell.xib.

Add -> New File -> iOS -> iPhone Table View Cell

Xamarin Studio does not support designing .xib files, but double clicking on the file will open it in Xcode and allow us to design the cell.

As we drag our controls on to the design surface, we have to make sure that we wire up the Outlet in the header file. In Xcode, we do this by ctrl-click-dragging the control into the header file. Without the Outlets, we wouldn't be able to access the controls in our C# code.

Save the .xib and quit Xcode. Xamarin Studio will detect the change, and update the MyCustomCell.designer.cs file with the new Outlets.

using MonoTouch.Foundation;  
using System.CodeDom.Compiler;

namespace XibTableCellDesign  
{
    [Register ("MyCustomCell")]
    partial class MyCustomCell
    {
        [Outlet]
        MonoTouch.UIKit.UILabel ConferenceDescription { get; set; }

        [Outlet]
        MonoTouch.UIKit.UILabel ConferenceName { get; set; }

        [Outlet]
        MonoTouch.UIKit.UILabel ConferenceStart { get; set; }

        void ReleaseDesignerOutlets ()
        {
            if (ConferenceDescription != null) {
                ConferenceDescription.Dispose ();
                ConferenceDescription = null;
            }

            if (ConferenceName != null) {
                ConferenceName.Dispose ();
                ConferenceName = null;
            }

            if (ConferenceStart != null) {
                ConferenceStart.Dispose ();
                ConferenceStart = null;
            }
        }
    }
}

Add the model

Notice that these Outlets are private. We will not be able to access the controls from our UITableViewSource GetCell method, which is where we normally set our control properties, such as label.Text = value. We can get around this by adding a public property in the custom cell to set with our model data.

public partial class MyCustomCell : UITableViewCell  
{
    public Conference Model { get; set; }
}

Then, in the LayoutSubviews method of our custom cell, we can set the control properties to the model object's properties.

public override void LayoutSubviews ()  
{
    base.LayoutSubviews ();

    this.ConferenceName.Text = Model.Name;
    this.ConferenceStart.Text = Model.StartDate.ToShortDateString ();
    this.ConferenceDescription.Text = Model.Description;
}

Use the cell

The last step is to create and use the cell in our table view source's GetCell method.

public override UITableViewCell GetCell (UITableView tableView, NSIndexPath indexPath)  
{
    var conference = _conferences [indexPath.Row];
    var cell = (MyCustomCell)tableView.DequeueReusableCell (MyCustomCell.Key);
    if (cell == null) {
        cell = MyCustomCell.Create ();
    }
    cell.Model = conference;

    return cell;
}

Checkout the sample app on my Github repo for an example of designing a table view cell with Xamarin Studio and .xib files.

January 09, 2015 3:18 GMT

End to End Mvvm with Xamarin

As a Xamarin University instructor, I am occassionally asked how I would put together a typical MVVM based app while connecting to a remote service. This is not the only way to architect our apps, and may not be the best for your app. Your mileage may vary.

Our goal is to connect to a remote service api, download the data, convert into a model that we control, and bind it to our ui. We'll connect to a remote service to download technical conference information, and we'll utilize a handful of useful open source .net libraries to speed things along and make our code cleaner.

We'll be using Xamarin Studio 5 (although Visual Studio will work just fine), and we'll use Xamarin.Forms for our user interface. All of the code is available from my Github Repo

Create Solution

Start by creating a new solution. We'll be using the "Blank App (Xamarin.Forms Portable)" template under the "Mobile Apps" node. I prefer PCLs over Shared Projects, but that's just me. Shared Projects will work also. I'll name the solution "DtoToVm" This template will create a core Portable Class Library as well as an Android and an iOS project (and a Windows Phone app if you're using Visual Studio on Windows). We'll be putting almost all of our code in the shared PCL.

File -> New Solution -> Blank App (Xamarin.Forms Portable)

Remote Third Party API (JSON)

Let's take a look at the api that we'll be working with. For this example, I'll be using api.tekconf.com/v1/conferences an open source conference management system (written by me). When performing a GET request on the conferences uri, we're given a list of all of the active conferences in the system.

[
  {
    slug: "codestock-2014",
    name: "CodeStock 2014",
    start: "/Date(1405036800000)/",
    end: "/Date(1405123200000)/",
    callForSpeakersOpens: "/Date(1391619909000)/",
    callForSpeakersCloses: "/Date(1391619909000)/",
    registrationOpens: "/Date(1391619909000)/",
    registrationCloses: "/Date(1405036800000)/",
    description: "CodeStock is a two day event (July 11th & July 12th of 2014) for technology and information exchange. Created by the community, for the community – this is not an industry trade show pushing the latest in marketing as technology, but a gathering of working professionals sharing knowledge and experience. Join us at CodeStock 2014 and move into the future.",
    lastUpdated: "/Date(1392149694455)/",
    address: {
      streetNumber: 0,
      city: "Knoxville",
      state: "TN",
      postalArea: "US"
    },
    imageUrl: "http://tekconf.blob.core.windows.net/images/conferences/codestock-2014.png",
    imageUrlSquare: "http://tekconf.blob.core.windows.net/images/conferences/codestock-2014-square.jpg",
    isLive: true,
    homepageUrl: "http://www.codestock.org/",
    position: [
      -83.9207392,
      35.9606384
    ],
    defaultTalkLength: 60,
    rooms: [ ],
    sessionTypes: [ ],
    subjects: [ ],
    tags: [ ],
    sessions: [ ],
    numberOfSessions: 0,
    isAddedToSchedule: false,
    isOnline: false,
    dateRange: "July 11 - 12, 2014",
    formattedAddress: "Knoxville, TN"
  }
]

Service Client

In order to connect to this service, we'll use Microsoft's HttpClient library. This is a cross platform nuget package that works well with PCLs and provides a nice async interface for accessing remote web endpoints. TekConf may not be the only service that we connect to though, so we'll wrap the access to the site in a client. This segregates the TekConf service to a small corner of our apps and allows the app code to focus on the app.

Add Class to PCL -> Services/TekConfClient.cs

namespace DtoToVM.Services  
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Net.Http;
    using System.Net.Http.Headers;
    using System.Threading.Tasks;
    using AutoMapper;
    using Newtonsoft.Json;
    using DtoToVM.Dtos;
    using DtoToVM.Models;

    public class TekConfClient
    {
        public async Task<List<Conference>> GetConferences ()
        {
            IEnumerable<ConferenceDto> conferenceDtos = Enumerable.Empty<ConferenceDto>();
            IEnumerable<Conference> conferences = Enumerable.Empty<Conference> ();

            using (var httpClient = CreateClient ()) {
                var response = await httpClient.GetAsync ("conferences").ConfigureAwait(false);
                if (response.IsSuccessStatusCode) {
                    var json = await response.Content.ReadAsStringAsync ().ConfigureAwait(false);
                    if (!string.IsNullOrWhiteSpace (json)) {
                        conferenceDtos = await Task.Run (() => 
                            JsonConvert.DeserializeObject<IEnumerable<ConferenceDto>>(json)
                        ).ConfigureAwait(false);

                        conferences = await Task.Run(() => 
                            Mapper.Map<IEnumerable<Conference>> (conferenceDtos)
                        ).ConfigureAwait(false);
                    }
                }
            }

            return conferences.ToList();
        }

        private const string ApiBaseAddress = "http://api.tekconf.com/v1/";
        private HttpClient CreateClient ()
        {
            var httpClient = new HttpClient 
            { 
                BaseAddress = new Uri(ApiBaseAddress)
            };

            httpClient.DefaultRequestHeaders.Accept.Clear();
            httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

            return httpClient;
        }
    }
}

Data Transfer Object (DTO)

Notice that we're introducing two new classes here, the DTO and the Model. We're creating a DTO so that we can deserialize the JSON string from the api into strongly typed C# objects. We'll use the Newtonsoft JSON.net nuget package for the deserialization. This DTO will match the remote json, and therefore be in the format and naming dictated by the remote, possibly third party service.

Add Class to PCL -> Dtos/ConferenceDto.cs

namespace DtoToVM.Dtos  
{
    using System;
    public class ConferenceDto
    {
        public string Slug { get; set; }
        public string Name { get; set; }
        public DateTime Start { get; set; }
        public double[] Position { get; set; }
    }
}

Model

The model class will be in the shape and structure that we want to deal with in our app. The DTO and the model very likely will be different. In our case, the DTO has an array of doubles named position to hold the geographic location of the conference, while our Conference model has two individual properties named Latitude and Longitude, which will be easier to store in our local SQLite database.

Add Class to PCL -> Models/Conference.cs

namespace DtoToVM.Models  
{
    using System;
    using SQLite.Net.Attributes;
    public class Conference
    {
        [PrimaryKey, AutoIncrement, Column ("_id")]
        public int Id { get; set; }
        [Unique]
        public string Slug { get; set; }
        public string Name { get; set; }
        public DateTime Start { get; set; }
        public double Latitude { get; set; }
        public double Longitude { get; set; }
    }
}

Map DTO to Model

To convert from the externally defined DTO to our model, we'll use AutoMapper, which provides us an easy way to map two different objects and copy the data from one to another.

Add Class to PCL -> Bootstrapper.cs

namespace DtoToVM  
{
    using AutoMapper;
    using DtoToVM.Dtos;
    using DtoToVM.Models;

    public class Bootstrapper
    {
        public void Automapper()
        {
            Mapper.CreateMap<ConferenceDto, Conference> ()
                .ForMember(dest => dest.Latitude, opt => opt.ResolveUsing<LatitudeResolver>())
                .ForMember(dest => dest.Longitude, opt => opt.ResolveUsing<LongitudeResolver>());
        }
    }

    public class LatitudeResolver : ValueResolver<ConferenceDto, double>
    {
        protected override double ResolveCore(ConferenceDto source)
        {
            return source.Position[0];
        }
    }

    public class LongitudeResolver : ValueResolver<ConferenceDto, double>
    {
        protected override double ResolveCore(ConferenceDto source)
        {
            return source.Position[1];
        }
    }
}

View Model

At this point, we're downloading the conference data from the remote site, and transforming it into our C# model. Next, we want to create some user interface to display that data. Xamarin.Forms shines for an app like this, where we want the same UI across three platforms, and we're not going to be customizing the UI very much. In order to simplify databinding, we'll create a View Model class for the list of conferences. The View Model will implement the INotifyPropertyChanged interface to relay change events to our UI. We'll using Fody.PropertyChanged to implement the interface for us, removing the boilerplate code. See my previous post Fody.PropertyChanged + Xamarin Studio = Easy Mvvm for more information about this library.

The View Model will use the TekConfClient class to download the Conference information. It will then save the list of Conference models to a local SQLite database. Lastly, it will set the Conferences property, which our UI will bind to.

Add Class to PCL -> ViewModels/ConferencesViewModel.cs

namespace DtoToVM.ViewModels  
{
    using System.Collections.Generic;
    using System.Linq;
    using System.Threading.Tasks;
    using PropertyChanged;
    using DtoToVM.Data;
    using DtoToVM.Models;
    using DtoToVM.Services;

    [ImplementPropertyChanged]
    public class ConferencesViewModel
    {
        readonly SQLiteClient _db;

        public ConferencesViewModel ()
        {
            _db = new SQLiteClient ();
        }

        public List<Conference> Conferences { get; set; }

        public async Task GetConferences ()
        {
            await GetLocalConferences ();
            await GetRemoteConferences ();
            await GetLocalConferences ();
        }

        private async Task GetLocalConferences()
        {
            var conferences = await _db.GetConferencesAsync ();
            this.Conferences = conferences.OrderBy(x => x.Name).ToList();
        }

        private async Task GetRemoteConferences()
        {
            var remoteClient = new TekConfClient ();
            var conferences = await remoteClient.GetConferences ().ConfigureAwait(false);
            await _db.SaveAll (conferences).ConfigureAwait(false);
        }
    }
}

Save to Database

Once we download the remote conference information, we'll cache it in a local SQLite database. By using the SQLite.Net PCL, the SQLite.Net Async PCL, and the SQLite Android and SQLite iOS libraries, we are able to easily save our Conference model to a local database. The SQLite PCL enables us to write almost all of our database code in our PCL and share it across all the different platforms that we're supporting. The one piece that is not shared though is the database connection. For that, we'll create an ISQLite interface, and we'll use Xamarin.Forms DependencyService to resolve the platform specific implementation of the SQLite connection.

Add Class to PCL -> Data/SQLiteClient.cs

namespace DtoToVM.Data  
{
    using SQLite.Net.Async;

    public interface ISQLite {
        SQLiteAsyncConnection GetConnection();
    }

    using System.Collections.Generic;
    using System.Threading.Tasks;
    using SQLite.Net.Async;
    using Xamarin.Forms;
    using DtoToVM.Data;
    using DtoToVM.Models;

    public class SQLiteClient
    {
        private static readonly AsyncLock Mutex = new AsyncLock ();
        private readonly SQLiteAsyncConnection _connection;

        public SQLiteClient ()
        {
            _connection = DependencyService.Get<ISQLite> ().GetConnection ();
            CreateDatabaseAsync ();
        }

        public async Task CreateDatabaseAsync ()
        {
            using (await Mutex.LockAsync ().ConfigureAwait (false)) {
                await _connection.CreateTableAsync<Conference> ().ConfigureAwait (false);
            }
        }

        public async Task<List<Conference>> GetConferencesAsync ()
        {
            List<Conference> conferences = new List<Conference> ();
            using (await Mutex.LockAsync ().ConfigureAwait (false)) {
                conferences = await _connection.Table<Conference> ().ToListAsync ().ConfigureAwait (false);
            }

            return conferences;
        }

        public async Task Save (Conference conference)
        {
            using (await Mutex.LockAsync ().ConfigureAwait (false)) {
                // Because our conference model is being mapped from the dto,
                // we need to check the database by name, not id
                var existingConference = await _connection.Table<Conference> ()
                        .Where (x => x.Slug == conference.Slug)
                        .FirstOrDefaultAsync ();

                if (existingConference == null) {
                    await _connection.InsertAsync (conference).ConfigureAwait (false);
                } else {
                    conference.Id = existingConference.Id;
                    await _connection.UpdateAsync (conference).ConfigureAwait (false);
                }
            }
        }

        public async Task SaveAll (IEnumerable<Conference> conferences)
        {
            foreach (var conference in conferences) {
                await Save (conference);
            }
        }
    }
}

Note : Find the AsyncLock class on Scott Hanselman's Blog

SQLite Implementations

Add Class to iOS Project -> Data/SQLiteClient.cs

using Xamarin.Forms;  
using DtoToVM.iOS.Data;

[assembly: Dependency (typeof(SQLiteClient))]
namespace DtoToVM.iOS.Data  
{
    using System;
    using DtoToVM.Data;
    using SQLite.Net.Async;
    using System.IO;
    using SQLite.Net.Platform.XamarinIOS;
    using SQLite.Net;

    public class SQLiteClient : ISQLite
    {
        public SQLiteAsyncConnection GetConnection ()
        {
            var sqliteFilename = "Conferences.db3";
            var documentsPath = Environment.GetFolderPath (Environment.SpecialFolder.Personal);
            var libraryPath = Path.Combine (documentsPath, "..", "Library");
            var path = Path.Combine (libraryPath, sqliteFilename);

            var platform = new SQLitePlatformIOS ();

            var connectionWithLock = new SQLiteConnectionWithLock (
                                          platform,
                                          new SQLiteConnectionString (path, true));

            var connection = new SQLiteAsyncConnection (() => connectionWithLock);

            return connection;
        }
    }
}

Add Class to Android Project -> Data/SQLiteClient.cs

using Xamarin.Forms;  
using DtoToVM.Android.Data;

[assembly: Dependency (typeof(SQLiteClient))]
namespace DtoToVM.Android.Data  
{
    using System;
    using DtoToVM.Data;
    using SQLite.Net.Async;
    using System.IO;
    using SQLite.Net.Platform.XamarinAndroid;
    using SQLite.Net;

    public class SQLiteClient : ISQLite
    {
        public SQLiteAsyncConnection GetConnection ()
        {
            var sqliteFilename = "Conferences.db3";
            var documentsPath = Environment.GetFolderPath (Environment.SpecialFolder.Personal);

            var path = Path.Combine (documentsPath, sqliteFilename);

            var platform = new SQLitePlatformAndroid ();

            var connectionWithLock = new SQLiteConnectionWithLock (
                                         platform,
                                         new SQLiteConnectionString (path, true));

            var connection = new SQLiteAsyncConnection (() => connectionWithLock);

            return connection;
        }
    }
}

Notice the use of

[assembly: Dependency (typeof(SQLiteClient))]

on each class. This will register the class in the DependencyService, and allow our PCL to resolve the dependency. Also note that on iOS, we are specifying the database path differently, so that the db3 database file is not backed up into iCloud.

Xamarin.Forms UI

The last part of the project is to create the user interface and wire everything up. We can use Xamarin.Forms to quickly create a cross platform UI and bind our list of conferences to a ListView control. Here, we'll create an instance of our ConferencesViewModel class, set the databinding to the ListView's cell template, and load the data. The key is setting the ListView's ItemsSource property to our ViewModel's Conferences property, which is implmenting the INotifyPropertyChanged events.

_conferencesListView.ItemsSource = viewModel.Conferences;  

Add Class to PCL -> Pages/ConferencesPage.cs

namespace DtoToVM.Pages  
{
    using System.Threading.Tasks;
    using Xamarin.Forms;
    using DtoToVM.ViewModels;

    public class ConferencesPage : ContentPage
    {
        ListView _conferencesListView;

        public ConferencesPage ()
        {
            this.Content = new Label { 
                HorizontalOptions = LayoutOptions.CenterAndExpand,
                VerticalOptions = LayoutOptions.CenterAndExpand
            };

            Init ();
        }

        private async Task Init ()
        {
            _conferencesListView = new ListView { 
                HorizontalOptions = LayoutOptions.FillAndExpand,
                VerticalOptions = LayoutOptions.FillAndExpand,
            };

            var cell = new DataTemplate (typeof(TextCell));
            cell.SetBinding (TextCell.TextProperty, "Name");
            cell.SetBinding (TextCell.DetailProperty, new Binding (path: "Start", stringFormat: "{0:MM/dd/yyyy}"));

            _conferencesListView.ItemTemplate = cell;

            var viewModel = new ConferencesViewModel ();
            await viewModel.GetConferences ();
            _conferencesListView.ItemsSource = viewModel.Conferences;

            this.Content = new StackLayout {
                VerticalOptions = LayoutOptions.FillAndExpand,
                Padding = new Thickness (
                    left: 0, 
                    right: 0, 
                    bottom: 0, 
                    top: Device.OnPlatform (iOS: 20, Android: 0, WinPhone: 0)),
                Children = { 
                    _conferencesListView 
                }
            };
        }
    }
}

In just a few lines of code we were able to create a fully native app for three different platforms. We leveraged the wealth of fantastic open source PCL libraries available on Nuget to quickly connect to a remote service, download json data, convert it to a model for our app, and save it to a local database. We then wired everything up and bound the data to our UI.

This is not the only solution available to you, but it's my preferred approach and is just one of the reasons I find working with C# and Xamarin such a joy.

View the code on Github

January 09, 2015 3:18 GMT

Fody.PropertyChanged + Xamarin Studio = Easy Mvvm

Model-View-ViewModel (Mvvm) is a fantastic pattern when designing cross platform mobile applications. With Mvvm, we can write our ViewModels in shared code and target Xamarin.iOS, Xamarin.Android, Windows Phone, and Windows Store apps. Libraries such as Xamarin.Forms, MvvmCross, and ReactiveUI provide excellent databinding and commanding functionality.

One thing that bothers me with Mvvm is the amount of boilerplate code that is required to implement the INotifyPropertyChanged interface, which powers our databinding engine.

INotifyPropertyChanged Implementation

    using System.Runtime.CompilerServices;
    using System.ComponentModel;

    public class UserViewModel : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;

        private string _firstName;
        public string FirstName {
            get { 
                return _firstName; 
            }
            set {
                if (value != _firstName) {
                    _firstName = value;
                    NotifyPropertyChanged ();
                }
            }
        }

        private string _lastName;
        public string LastName {
            get { 
                return _lastName; 
            }
            set {
                if (value != _lastName) {
                    _lastName = value;
                    NotifyPropertyChanged ();
                }
            }
        }

        private void NotifyPropertyChanged ([CallerMemberName] string propertyName = "")
        {
            if (PropertyChanged != null) {
                PropertyChanged (this, new PropertyChangedEventArgs (propertyName));
            }
        }
    }

That's a lot of boilerplate cluttering up our code, making it harder to read and understand what this class is really trying to accomplish. The code required by the notification/databinding engine isn't adding any value to our view model and it isn't related to our application or our business logic. Ideally, we'd like to remove that boilerplate code and focus on our app.

Clean ViewModel with Auto Properties

    public class UserViewModel
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
    }

Luckily, there is an amazing library named Fody.PropertyChanged that we can leverage that will allow us to write only the code that we need, but rewrite the resulting assembly to implement INotifyPropertyChanged for us. All we need to do is add the PropertyChanged.Fody Nuget Package to our project, and add an attribute to our ViewModel.

ViewModel + Fody.PropertyChanged

    using PropertyChanged;

    [ImplementPropertyChanged]
    public class UserViewModel
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
    }

Out of the box, this all works just fine using Visual Studio on Windows. There are a few problems currently with Xamarin Studio though. Adding the Nuget package is successful, but the project fails to compile. Fixing these issues is easy though.

  • Add the PropertyChanged.Fody package via Nuget

    Install-Package PropertyChanged.Fody
    
  • The Nuget package adds a FodyWeavers.xml file to the project, but leaves it empty

    • Add <PropertyChanged /> to FodyWeavers.xml
<?xml version="1.0" encoding="utf-8" ?>  
<Weavers>  
    <PropertyChanged />
</Weavers>  
  • Set FodyWeavers.xml to Build Action -> Content
  • Set FodyWeavers.xml to Quick Properties -> Copy to Output Directory
  • Build

Viewing the resulting assembly in Xamarin Studio's Show Disassembly window gives the follwing result

Disassembled Code with Fody

    using System;
    using System.ComponentModel;
    using System.Runtime.CompilerServices;

    namespace TestFody
    {
        public class UserViewModelWithFody : INotifyPropertyChanged
        {
            //
            // Properties
            //
            public string FirstName {
                [CompilerGenerated]
                get {
                    return this.<FirstName>k__BackingField;
                }
                [CompilerGenerated]
                set {
                    if (string.Equals (this.<FirstName>k__BackingField, value, StringComparison.Ordinal)) {
                        return;
                    }
                    this.<FirstName>k__BackingField = value;
                    this.OnPropertyChanged ("FirstName");
                }
            }

            public string LastName {
                [CompilerGenerated]
                get {
                    return this.<LastName>k__BackingField;
                }
                [CompilerGenerated]
                set {
                    if (string.Equals (this.<LastName>k__BackingField, value, StringComparison.Ordinal)) {
                        return;
                    }
                    this.<LastName>k__BackingField = value;
                    this.OnPropertyChanged ("LastName");
                }
            }

            //
            // Methods
            //
            public virtual void OnPropertyChanged (string propertyName)
            {
                PropertyChangedEventHandler propertyChanged = this.PropertyChanged;
                if (propertyChanged != null) {
                    propertyChanged (this, new PropertyChangedEventArgs (propertyName));
                }
            }

            //
            // Events
            //
            [field: NonSerialized]
            public event PropertyChangedEventHandler PropertyChanged;
        }
    }
January 09, 2015 3:14 GMT

Xamarin Weekly Newsletter #22

customLogo

A free, once-weekly e-mail newsletter roundup of all things Xamarin. Join over 522 other developers and get the latest news and information about Xamarin, the most exciting thing in mobile.

Amazing Community-Built Plugins for Xamarin
James Montemagno, from Xamarin Inc., shows off the community built plugins, even some for Xamarin.Forms.

Re-enabling the CommandManager feature with RelayCommand in MVVM Light V5
Laurent Bugnion, from GalaSoft, gets the CanExecute delegate working again in MMVMLight v5.

Data storage options for Xamarin Apps
Valentin Polushkin, from Xamarin Inc., enumerates the many options Xamarin developers have for on device storage.

Xamarin: Happy 2015 from Xamarin!
Take a look at some of Xamarin’s favorite highlights of 2014.

Xamarin.Forms U.S. Senate Contact App Course
I (Adam) introduce my free Xamarin.Forms course (a work in progress).

Update on Xamarin.iOS Unified API Release Plans
Miguel de Icaza, from Xamarin Inc., informs iOS developers that the unified API will be here next week.

Deploying the Xamarin Forms Dice App multi-platform
Alex West, from Rarely Impossible, redeploys his Android app to iOS and Windows.

Xamarin and iOS 8: 64 Bit Support and UI
Wallace McClure releases his training course on LearnNowOnline.com.

Handling Orientation Changes in Xamarin.Forms Apps
Chris Sells is blogging again and this time he’s getting orientation straight in Xamarin.Forms.

Launching the Native Map App from Xamarin.Forms
Chris Sells launches native maps with this simple method.

Presenters in MvvmCross: Using Presentation Values
Greg Shackles gets his bundles ready and shows off presenters.

Lollipop AppCompat PreferenceActivity
James Montemagno, from Xamarin Inc., shows us his love for Material Design.

Jump Start the New Year with Xamarin!
Jayme Singleton, from Xamarin Inc., will get you ready for the new year with these Xamarin events.

Get up to speed with Xamarin
The Xamarin resources page got a facelift! Check it out now for great webinar recordings, videos, case studies & more.

Azure Mobile Service for client apps – Xamarin Developers
Sara Silva is collecting resources for Xamarin and Azure Mobile Service developers. Check it out.

Paul Betts: Tweets Akavache 4.1.0 is now out, with support for Xamarin.iOS
Akavache now supports the Xamarin Unified profile for iOS and Mac.

Module 08, Video 01: Summary and Demo
Kent Boogaat posted his next video on his series on Building an iOS app with C#.

Designing UIs for Multiple iOS 8 Devices
Wallace McClure cures his fragmentation blues with storyboards.

 

Don’t miss out! Subscribe Today

Do you blog about Xamarin? Get your blog in the newsletter.
Email me at adam [at] XamarinWeekly.com.

The post Xamarin Weekly Newsletter #22 appeared first on Syntax is my UI.

January 07, 2015 11:09 GMT

Data storage options for Xamarin apps

Xamarin has a vibrant ecosystem and the on-device storage segment is no exception. Here are some projects that you might want to give a whirl next time you're writing a Xamarin app:

SQLite.NET is a very popular ORM developed by Frank Krueger. Frank is the author of one of my favorite OS X apps - Calca. ORM stands for Object Relation Mapper, and in a nutshell, allows you to work with the database using objects. In other words, it encapsulates the code needed to manipulate the data, so you don’t use SQL anymore, but work directly with C# objects and the library’s methods to insert, select, etc.

The original version did not support PCLs, however, there is a fork developed by Øystein Krog that does just that. You will need to get platform-specific implementations of the ISQlitePlatform interface to get it working.

InstantDatabase is a project that sits on top of SQLite.NET. Developed by James Clancey, an engineer here at Xamarin, this library does the smart grouping for you, so you get quick jump and grouping for free.

SQLite.NET Extensions is another library used in conjuction with SQLite.NET. Developed by TwinCoders, it allows you to create one-to-one, one-to-many, many-to-one, many-to-many relationships between your objects.

Couchbase Lite for .NET is a lightweight, document-oriented database. It primarily solves two problems: periodic loss of internet connectivity and changes to the database schema. Couchbase also offers multiple deployment options. Take a look at our blog post on this component.

Akavache is a key-value store built by Paul Betts. Paul is an engineer at Slack (previously at GitHub) who wrote numerous libraries for Xamarin such as ReactiveUI and ModernHttpClient. Akavache is designed for working with (and caching) any remote data whether it's an HTTP response, image or a JSON string.

I hope you try some of these projects in 2015. Happy New Year!

January 07, 2015 12:20 GMT

Xamarin.Forms U.S. Senate Contact App Course

Today, I am kicking off development of the first of a series of e-courses on building mobile apps with Xamarin and Xamarin.Forms. Courses will have text, images, code, video, slides, screen-shares, and the occasional quiz to test your knowledge. And if you’re the type that likes badges and certificates, we’ll have those too.

My first of many Xamarin courses will be the U.S. Senate Contact App. We, here in the US, have finished our elections and the U.S Senate has a few new members. These new members have taking office today. I have no doubt that these new and old members would love to hear from their constituents. That would be you!

It’s for Real

Did I forget to mention that the app built in this course is already available in the Google Play store! Yes, that’s right; a real app with real world data in a real world app store. I think it’s pretty important to show Xamarin and Xamarin.Forms used in anger on real world apps. Nothing is more real than the App store.

A Real Looker

When was the last time you built a tutorial app that was easy on the eyes? You know, the UI looked good, the launch icon was within design guidelines, and all the icons matched. As you might have noticed from my blog, I like UI and think it’s pretty important. Syntax courses will not only focus on Xamarin and Xamarin.Forms but will also make UI and UX a priority. I am not a designer but a developer that likes working with good design.

SenateContactsAndroidScreenShot

My favorite UI / UX tool is the Sketch.app on the Mac. I’ll have some bonus videos on how to make icons and assets for your cross-platform applications.

When can I take the course?

Do you want to take the course? I hope so. I’m writing and filming it now and will have something ready by early January 2015. People on the Syntax mailing list will be the first to hear about it. So if you want to take the course, sign up below.

Sign Up for the Newsletter and get a Free Training Course.

The course will be free while its in beta and when finished and polished will be put up for sale.

The post Xamarin.Forms U.S. Senate Contact App Course appeared first on Syntax is my UI.

January 05, 2015 6:02 GMT

Xamarin and iOS 8: 64 Bit Support and UI

My training course on Xamarin and iOS8 regarding the new 64 bit support and the new User Interface designer tools has just recently been posted to the Learn Now Online site.  I hope that you find it helpful!

Url to course: http://www.learnnowonline.com/course/i8x1/xamarin-and-ios-8-64-bit-support-and-ui

Url to trailer: http://www.learnnowonline.com/trailer/i8x1

Course description

In this course, we will look at the architecture of iOS, how xamarin is supporting 64 bits and what you need to do to update your applications. Next, we will look at the new features in UIKit. Some of these features include the new Xamarin Designer for iOS, AutoLayout and new features added to notifications, and many other enhancements.

Prerequisites

The course assumes knowledge of C# and .NET at an intermediate level. Some familiarity with OSX is helpful, but not required. A very basic understanding of XML is also required.

Outline:

OS 8 Architecture (19:33)
  • Introduction (00:19)
  • Apple iOS (03:15)
  • Major 64-Bit Changes (01:44)
  • ILP32 & LP64 (01:36)
  • Impact on Apps (02:12)
  • Apple Hardware (02:06)
  • iOS Adoption (01:48)
  • Apple Requirements (01:36)
  • Xamarin.iOS (01:01)
  • Xamarin Unified API (00:27)
  • Defaults (03:09)
  • Summary (00:15)
IOS 8 Architecture Continued (23:02)
  • Introduction (00:12)
  • Splits (02:29)
  • Components (01:56)
  • New Data Types (01:47)
  • Upgrade Apps (01:01)
  • Demo: New Unified API (05:10)
  • Demo: API Migration (05:15)
  • Demo: Troubleshooting (01:30)
  • Other Changes (01:43)
  • Images (01:10)
  • Icons (00:24)
  • Summary (00:19)
UI Kit Intro (14:46)
  • Introduction (00:17)
  • Current Status of iOS (00:57)
  • Current Devices (00:53)
  • Current Supported Screen Sizes (01:12)
  • Problem (01:38)
  • Current Version Distribution (01:44)
  • App Icon Images (01:01)
  • Startup Screen (01:33)
  • Demo: Startup & Images (05:14)
  • Summary (00:14)
Design Surface (22:58)
  • Introduction (00:19)
  • Xib (01:09)
  • Xcode Integration (00:43)
  • Storyboards (01:24)
  • Size Classes (01:23)
  • Constraints (02:11)
  • AutoLayout with the Designer (00:40)
  • Constraint Toolbar (00:58)
  • Creating Constraints (00:58)
  • Little Things with Designer (01:33)
  • Demo: iOS Designer (05:22)
  • Demo: Constraints (06:01)
  • Summary (00:12)
Create UI Programmatically (09:55)
  • Introduction (00:14)
  • Programmatically UI (00:40)
  • Historical Requirements (01:01)
  • Apple Way (00:42)
  • FluentLayout (01:04)
  • Methods (00:52)
  • Demo: Programmatic UI (04:35)
  • Resources (00:27)
  • Summary (00:15)
UI Alert View Controller (18:15)
  • Introduction (00:13)
  • UIKit (00:50)
  • UIAlertView (00:46)
  • UIAlertViewController (00:38)
  • UINavigationController (00:56)
  • UINavigationController in iOS8 (00:58)
  • Demo: UIAlertController (04:52)
  • Demo: UINavigationController (01:41)
  • Notifications (01:16)
  • Notification Additions (00:28)
  • UIMutableUserNotificationAction (00:55)
  • Personal Lesson (00:47)
  • Demo: Notifications (03:35)
  • Summary (00:13)
Popover (15:49)
  • Introduction (00:16)
  • UIPopoverController (01:01)
  • UIPopoverPresentationController (00:23)
  • UISearchController (00:43)
  • UISplitViewController (01:04)
  • Demo: Popover Controller (03:11)
  • Demo: Search Controller (04:05)
  • Demo: Split View Controller (04:43)
  • Summary (00:21)

 

January 03, 2015 6:52 GMT

Presenters in MvvmCross: Using Presentation Values

As shown in my last post, a MvxViewModelRequest contains a dictionary named PresentationValues that can be very useful in passing around data that your presenter might find useful. Let's say you that in your view model you know that when you request to show a view model you know that you want to clear the app's back stack before showing it, such as after a login operation so that the login screen is no longer in the stack.

All overloads of ShowViewModel() in MvvmCross contain an optional IMvxBundle parameter named presentationBundle. It's easy to create a bundle from a dictionary and then pass that into the show request:

var presentationBundle = new MvxBundle(new Dictionary<string, string> { { "NavigationMode", "ClearStack" } });

ShowViewModel<MyViewModelType>(presentationBundle: presentationBundle);  

When your platform's presenter gets that request, the values you passed in with the presentation bundle will be available in the PresentationValues property described earlier. With that in place, let's implement the clear operation on both iOS and Android.

iOS

For this example I'm going to assume the presenter inherits from the standard MvxTouchViewPresenter class provided in MvvmCross, which manages a UINavigationController stored in a property named MasterNavigationController. All our presenter needs to do is detect the hint we sent in the request and react accordingly:

public override void Show(MvxViewModelRequest request)  
{
    if (request.PresentationValues != null)
    {
        if (request.PresentationValues.ContainsKey("NavigationMode") && request.PresentationValues["NavigationMode"] == "ClearStack")
            MasterNavigationController.PopToRootViewController(false);
    }

    base.Show(request);
}

I'm using magic strings here to keep things simple, but you could use constants/enums/whatever works for your application if you want to formalize things a bit more. The false sent in to PopToRootViewController() says not to animate so that it happens immediately. You can easily get yourself into trouble with UINavigationController if you have competing navigations, so definitely be careful there. I'll dig into that topic further in a future post.

Android

Now let's look at Android. I'm going to assume a presenter that's using fragments for all views and has a FragmentManager field it uses to manage them. In a future post I'll talk in more detail on how to implement this model in Android, but that's a bit off topic here. With that aside, the Android implementation ends up looking pretty similar to iOS:

public override void Show(MvxViewModelRequest request)  
{
    if (vmRequest.PresentationValues != null)
    {
        if (request.PresentationValues.ContainsKey("NavigationMode") && request.PresentationValues["NavigationMode"] == "ClearStack")
            _fragmentManager.PopBackStackImmediate(null, PopBackStackFlags.Inclusive);
    }

    // ...
}

This is just one thing you can do with presentation values, so it's really up to you and what makes sense in your apps. If you have some knowledge in your view models that are of use to the presenter during a request, these values provide an easy way to pass that knowledge along with it.

January 03, 2015 5:39 GMT

Lollipop AppCompat PreferenceActivity

I fell in love with material design the moment I saw it and at Evolve 2014 my good friend and co-worker Jérémie Laval and I actually gave 2 sessions on the concept and implementation of material design in your apps. With the introduction of v7 app compat library rev 21 you are now able to upgrade your apps while maintain compatibility with older versions of Android. If you are looking to get started integrating the support library into your apps then check out my samples over on the Xamarin documentation site. While transitioning my Bike Now app over to v7 appcompat I ran into one small issue, which is that there is no updated PreferenceActivity with a SupportActionBar or one that takes advantage of the new Toolbar and back arrow. However, there is an awesome workaround that will allow you to get that beautiful material design in your preference activity.

Special Themes


You should already have a base theme of your application that you are using that inherits from Theme.AppCompat of some sort that is used throughout your application, but you will need to create a new theme specific for the PreferenceActivity.



This will ensure that your toolbar is properly themed with the up indicator and will use your primary colors correctly as well, while still inheriting from your base theme.

Settings Layout


Normally with a preference activity there is no layout file at all because everything is generated for you through the preference xml file. However, we will actually need to insert a new v7 Toolbar at the top of the preference activity. I have a universal Toolbar that I use throughout my application that I specify in my Toolbar.axml and then I created a new Settings.axml which simply stacks the toolbar ontop of a FrameLayout that we will use later on to insert the main preference ListView.



Update PreferenceActivity


The last piece is to now trick our PreferenceActivity into using our new Settings.axml. This is done in the SetContentView where we will combine the two layouts together cleverly.



With that in place you are all set to now have a beautiful preference activity with the back arrow properly in place. In addition to this since you have a full Toolbar you can still use menu items and handle them appropriately as well.

January 01, 2015 1:00 GMT

A Xamarin Year in Review

2014 was all about venturing out of the web development world and immersing myself into the mobile app development and Xamarin worlds. The journey has been a blast.

GCU Maps App

GCU Maps App IconEarlier this year I spent a very busy week building my employer’s first mobile App, the GCU Maps App. The app is used everyday by students trying to get to their classes on campus. To go from nothing to having an app in the store took me a total of three weeks. Without Xamarin, Xamarin.iOS and Xamarin Studio, it would have taken me much longer.

 

Xamarin Weekly Newsletter

customLogoIn August 2014, I started the Xamarin Weekly Newsletter and the response has been surprising in a good way. To date we have 492 subscribers and a very good open and click rate. I have never produced a newsletter but thought that a JavaScript Weekly style newsletter would do wonders for the Xamarin community and give me a good reason to read everything I could about Xamarin.

I have no plans to change the newsletter in the near or distance future. So if you’re one of the 492 subscribers, you can expect your copy to be delivered early every Friday morning in 2015. If you’re not a subscriber, you can subscribe at XamarinWeekly.com.

Senate Contacts App

Senate Contacts Course Feature 3What’s a self respecting cross-platform mobile app developer supposed to do if they have only one platform? Create and deploy an app to the other platform of course. The Senate Contacts app is my first Xamarin.Forms app and it is already deployed to the Google Play store. This application is the subject of my new e-course on Xamarin and Xamarin Forms.

 

Xamarin Forms Courses

I am currently filming my first online course on how to build the Senate Contacts mobile application using Xamarin Forms. Yep that’s right the same app I deployed to the Google Play store is the app built in the course. Not a fake app but a real world app that’s in the store.

2015

Nobody knows what’s going to happen in 2015. What I do know, is that Xamarin and mobile development will be a part of mine.

To learn more about the Xamarin online courses please subscribe to the Syntax newsletter. Subscribers will be the first to hear about the course and will be given some of the free beta seats in late January 2015.

 

The post A Xamarin Year in Review appeared first on Syntax is my UI.

December 31, 2014 5:26 GMT

Driving Xamarin's Android Player from the Command Line

As part of our effort to automate taking screenshots, we also need the ability to spin up Android emulators via the command line. This all needs to run headless, so it's necessary to be able to spin up Android emulators from the command line. A quick look at my ps output showed this to be even simpler a task than I'd anticipated.

To launch a new instance of the Android Player from the command line, all you need to do is run:

"/Applications/Xamarin Android Player.app/Contents/Helpers/Xamarin Android Player.app/Contents/MacOS/Xamarin Android Player" --name "Nexus 5 (KitKat)"

You can substitute the name there for whichever image you want to spin up. Once it finishes launching it'll be in a locked state. From the command line you can unlock it by using the adb command:

adb shell input keyevent 82  

Here's a little F# script I put together to run through this sequence. If it finds any Android Player processes running, it assumes one is already running and skips that step. If you have the main Xamarin Android app running, even without having started any emulators from within it, this check will treat that as if an emulator is running. If none are found, it launches one and waits for 30 seconds before trying to unlock. Crude, but it does the job for now.

let startAndroidEmulator = fun (emulatorName:string) ->  
    let xamarinPlayerPath = "/Applications/Xamarin Android Player.app/Contents/Helpers/Xamarin Android Player.app/Contents/MacOS/Xamarin Android Player"
    let exec = fun file args ->
        let info = new ProcessStartInfo()
        info.FileName <- file
        info.Arguments <- args

        let proc = new Process()
        proc.StartInfo <- info
        proc.Start() |> ignore

    if Process.GetProcessesByName("Xamarin Android").Length = 0 then
        exec xamarinPlayerPath (String.Format("--name \"{0}\"", emulatorName))

        Async.Sleep(30 * 1000) |> Async.RunSynchronously

    exec "adb" "shell input keyevent 82"
December 31, 2014 3:48 GMT

Presenters in MvvmCross: A Primer

Use a custom presenter

-- Me, at least once a week in #mvvmcross

Having been involved in the MvvmCross community for several years now, often it feels like my most common response to questions in the #mvvmcross JabbR room from someone new to the framework is to look into using a custom presenter. Presenters are an important piece of the MvvmCross architecture, but that's not necessarily obvious when you're first getting into things. A long time ago I vowed to do a series of blog posts on different aspects of presenters...better late than never, right?

Eventually I want to dig into a variety of things related to presenters but for now I'd like to keep it to the absolute basics. So, what is a presenter?

What Are Presenters?

Ever wonder what happens in between calling ShowViewModel<>() in your portable class library and a navigation happening in your app? That's where presenters (and some of their friends) come into play. As the name implies, presenters take requests from the view model layer for things like navigating to a new view model and decide how to present it within the application itself.

Because they deal with the view layer, presenters are specific to individual platforms by definition. This gives you a clean separation between requests and how they get propagated to the UI, which gives you a lot of power. Want to display things differently depending on whether the device is a phone or a tablet? Use tabs on iOS and Android but a pivot view on Windows Phone? Use fragments for everything on Android? Presenters are going to be your new best friend.

The best example I've found to help illustrate this distinction is the typical master-detail pattern. Imagine an app with two view models, one with a list of people, and one for displaying the details of a specific person. On a small phone screen you might want to display the list as a single screen, and then tapping on a person navigates you to a second screen containing their details. If you're on a larger screen like a tablet you might want to use a split view so that both views are actually visible at the same time, and take advantage of the screen's real estate. In both cases the view models and their behavior is identical regardless of how they're displayed. Even the views might even be shared in both implementations, but it's just the actual presentation of those views you want to customize.

Let's take a look at the interface itself for presenters:

public interface IMvxViewPresenter  
{
      void Show(MvxViewModelRequest request);
      void ChangePresentation(MvxPresentationHint hint);
}

Presenters are really useful, but at their core they are also very simple. Let's address each of these interface methods individually.

Show

As the name implies, Show() is called when ShowViewModel() is invoked from a view model. Passed into it is a simple object containing the details of this particular request:

public class MvxViewModelRequest  
{
    public Type ViewModelType { get; set; }
    public IDictionary<string, string> ParameterValues { get; set; }
    public IDictionary<string, string> PresentationValues { get; set; }
    public MvxRequestedBy RequestedBy { get; set; }

    // ...abridged...
}

Included here are the type of view model being requested, along with parameters specific to both navigation and presentation. We'll dig into PresentationValues more in a future post, but that property can be a really useful way to send hints to your presenter to help control how the presenter behaves.

Using the information in this requesst object, it's the presenter's job to construct and display the corresponding view in whatever way makes sense to the UI. For example, a simple presenter on iOS would manage a UINavigationController and call PushViewController(nextView) in order to navigate to the requested view. In fact, this is precisely what happens in MvxTouchViewPresenter, one of the default presenters on iOS and ships in the box with MvvmCross.

ChangePresentation

That covers the basics of showing a new view model, but there's still one other method in IMvxPresenter: ChangePresention(). Let's say you want to trigger some sort of presentation change from your view model that doesn't involve showing a new view model. This method is how you can go about doing that.

If you've been working in MvvmCross at all you've probably been using this piece of the presenter without even realizing it. Ever called Close(this) from a view model? Close() is a method on MvxNavigatingObject, the base class to MvxViewModel, and is really just a quick proxy to ChangePresentation():

public abstract class MvxNavigatingObject : MvxNotifyPropertyChanged  
{
    protected bool Close(IMvxViewModel viewModel)
    {
        return ChangePresentation(new MvxClosePresentationHint(viewModel));
    }
}

ClosePresentationHint is a built-in class to MvvmCross that can signal to a presenter that it should pop the view, rather than navigate to something new. Let's take the implementation in MvxTouchViewPresenter as an example:

public override void ChangePresentation(MvxPresentationHint hint)  
{
    if (hint is MvxClosePresentationHint)
    {
        Close((hint as MvxClosePresentationHint).ViewModelToClose);
        return;
    }

    base.ChangePresentation(hint);
}

This will then call PopViewController() in order to navigate backwards in the stack. You could easily create your own subclasses of MvxPresentationHint in order to signal other actions up to your presenter to achieve whatever behavior your app needs.

Summary

This just scratches the surface of what presenters allow you to do in MvvmCross, but hopefully it helps clarify the piece of the puzzle they provide. Navigation can get particularly tricky when you try to take it cross-platform, so in future posts I'll try to cover some things I've run into there, as well as some other presenter tricks of the trade.

Have something in particular you want to know about presenters? Let me know!

December 30, 2014 12:00 GMT

Ultimate Cross Platform NuGet Restore

If you just want the straight solution, download the targets file alongside your .sln and name it Before.[solution file name].targets. Now just build from either IDEs or command lines :).

Back in the day, when NuGet just came out, you were supposed to just right-click on your solution node in Visual Studio, and click “Enable NuGet Package Restore”. You may be surprised to still find that context menu command even when the latest recommendation by the NuGet team is to NOT use it.

The new way is to just run nuget.exe restore before building the solution. And of course there are a gazillion ways of doing it, from batch files, to a separate MSBuild file that is built instead of the main solution, to powershell scripts, etc. Oh, and you should probably download nuget.exe from nuget.org too before doing the restore ;).

With the unstoppable rise of Xamarin for development (ok, maybe I’m slightly biased ;)), it’s highly desirable that whatever solution you adopt also works on a Mac too, Xamarin Studio, and why not xbuild in addition to MSBuild command line builds?

It turns out that such a cross-platform solution is pretty straight-forward to implement and very simple, by just leveraging a little-known extensibility hook in MSBuild/xbuild.

IDE vs Command Line Builds

Both Xamarin Studio and Visual Studio build solutions differently than their command line counterparts xbuild and MSBuild. Both IDEs read the solution file and construct their in-memory representations of the included projects. From that point on, it’s the IDE that controls the build, not the command-line xbuild/msbuildn tools.

But since the solution file is not an MSBuild file, on command line builds a temporary MSBuild file is created from the solution, and this file is built instead. And luckily, it also has some extensibility points itself that we can leverage.

It’s important to keep in mind though that these extensibility points are for the command line builds only, which is a really nice plus in this case, since both IDEs already do their own NuGet package restore automatically (and that’s why the project-level MSBuild-based package restore from before is no longer recommended, it’s just duplicate behavior that just slows down every build).

So, part of the good news is: if you just want IDE-driven NuGet package restore, you don’t have to do anything at all :). But who does IDE-only builds these days anyway? So let’s see how we tweak the command line builds so that they work from the very same solution file as the IDE.

Command Line Automated Package Restore

The approach is to basically have a file named Before.[solution file name].targets (like Before.MyApp.sln.targets) alongside the solution. As explained by the awesome Sayed in his blog, this targets file is imported alongside the temporary MSBuild project generated for the solution, and can therefore provide targets that run before/after any of the built-in ones it contains:

  • Build
  • Rebuild
  • Clean
  • Publish

For package restore, we’ll just provide a target that runs before Build. On a Mac, if Xamarin Studio is installed and you’re performing a command line build, the “nuget” (no “.exe” extension) command will already be available in the path, so we need to conditionally do things slightly different there than on Windows.

The gist of the solution is very very simple:

<PropertyGroup>
    <NuGetExe Condition="'$(OS)' == 'Windows_NT'">.nuget\NuGet.exe</NuGetExe>
    <NuGetExe Condition="'$(OS)' != 'Windows_NT'">nuget</NuGetExe>
</PropertyGroup>

<Target Name="RestorePackages" 
        BeforeTargets="Build" 
        DependsOnTargets="DownloadNuGet">
    <Exec Command="&quot;$(NuGetExe)&quot; Restore &quot;$(SolutionPath)&quot;" />
</Target>

That’s basically it. Run NuGet.exe Restore [solution] on Windows, and nuget Restore [solution] otherwise. Of course, on Windows we’ll also need to download the nuget executable if we don’t find it locally, so that’s the DownloadNuGet target. This target just uses an inline code task that downloads the executable from nuget.org, just like the now deprecated NuGet.targets restore did, with a tweak to make it work consistently across all installed versions of MSBuild/Visual Studio.

Note that this target will never run on the Mac/xbuild. And it’s important since xbuild does not support inline code tasks.

<Target Name="DownloadNuGet" Condition="'$(OS)' == 'Windows_NT' And !Exists('$(NuGetExe)')">
    <DownloadNuGet TargetPath="$(NuGetExe)" />
</Target>

<UsingTask TaskName="DownloadNuGet" TaskFactory="CodeTaskFactory" AssemblyFile="$(CodeTaskAssembly)">
    <ParameterGroup>
        <TargetPath ParameterType="System.String" Required="true" />
    </ParameterGroup>
    <Task>
        <Reference Include="System.Core" />
        <Using Namespace="System" />
        <Using Namespace="System.IO" />
        <Using Namespace="System.Net" />
        <Using Namespace="Microsoft.Build.Framework" />
        <Using Namespace="Microsoft.Build.Utilities" />
        <Code Type="Fragment" Language="cs">
            <![CDATA[
            try {
                TargetPath = Path.GetFullPath(TargetPath);
                if (!Directory.Exists(Path.GetDirectoryName(TargetPath)))
                    Directory.CreateDirectory(Path.GetDirectoryName(TargetPath));

                Log.LogMessage("Downloading latest version of NuGet.exe...");
                WebClient webClient = new WebClient();
                webClient.DownloadFile("https://www.nuget.org/nuget.exe", TargetPath);

                return true;
            }
            catch (Exception ex) {
                Log.LogErrorFromException(ex);
                return false;
            }
        ]]>
        </Code>
    </Task>
</UsingTask>

The situation with MSBuild inline code tasks is quite a mess with regards to the CodeTaskFactory assembly name. Between MSBuild 4 (VS2010), MSBuild 12 (VS2013) and MSBuild 14 (VS2015), Microsoft changed not only the location of the file but also its name, in each version. So there are three ways of pointing to the right assembly. Sigh.

Anyway, this solution I found seems to be the most consistent with the way Microsoft itself detects what version of VS/MSBuild is running and what assemblies should be used:

<PropertyGroup Condition="'$(OS)' == 'Windows_NT'">
    <CodeTaskAssembly Condition="'$(MSBuildAssemblyVersion)' == ''">$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll</CodeTaskAssembly>
    <!-- In VS2013, the assembly contains the VS version. -->
    <CodeTaskAssembly Condition="'$(MSBuildAssemblyVersion)' == '12.0'">$(MSBuildToolsPath)\Microsoft.Build.Tasks.v12.0.dll</CodeTaskAssembly>
    <!-- In VS2015+, the assembly was renamed, hopefully this will be the last condition! -->
    <CodeTaskAssembly Condition="'$(MSBuildAssemblyVersion)' != '' and '$(MSBuildAssemblyVersion)' &gt;= '14.0'">$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll</CodeTaskAssembly>
</PropertyGroup>

Again, this is something that only applies to Windows/MSBuild, not Mac/xbuild. The condition isn’t really necessary, but it just makes it clearer that this applies only to Windows/MSBuild. MSBuildAssemblyVersion is a new reserved property (since MSBuild 12) that allows us to determine the right assembly to specify for the CodeTaskFactory task.

So there it goes: a simple .targets file alongside the solution file, and you can do IDE and command line builds consistently that automatically restore without slowing down builds for each project unnecessarily.

You can just download the entire targets file alongside your .sln and name it Before.[solution file name].targets.

Update: to make this even easier, I just turned the thing into a nuget package :). So in your repository root, just run:

NuGet Install build -ExcludeVersion

Full project source in GitHub.

Happy nugetting! ;)

December 29, 2014 9:41 GMT

Scroll To in Xamarin.Forms Grouping

In a recent blog-post I showed how to use the new Scroll To feature in Xamarin.Forms.  In this posting I’ll show how to go to a particular entry within a group and also how to go to a particular entry.

We start with the code were using in the previous post.  …. The key difference is that we add another parameter to ScrollTo.  Continued here