Xamarin Forms – Bindable Picker(!!)

Xamarin Forms – Bindable Picker(!!)

I’m rather starting to like doing these look aheads to features coming out in future versions of Xamarin.Forms. It’s really cool tracing through the source code to see how a new feature is being implemented and coming together. And today we’re going to talk about a feature that I keep trying to use, thinking it’s already implemented in Forms… but every time I try, I slap my forehead and remember it’s not there yet … binding a data source to a Picker !! Everything I talk about in this article is dependent upon Xamarin.Forms 2.3.4 – which at the time of this writing (November 29, 2016) is not on NuGet yet. You will need to build from source in order to use it right now. When it does show up on NuGet if there are any changes, I will keep this blog updated. tl;dr; All the code from this post can be found on GitHub here. If you’re only here for the goodness of how to data bind to a Picker … first bind an IList collection to the ItemsSource property. Then bind whatever you want receiving updates to the SelectedItem. Finally, ItemDisplayBinding can receive another binding (from a property within the class’s that make up the IList bound to the ItemsSource), that will determine what gets displayed. Read on to get the full run down of the new data binding! New Properties There are 3 new properties introduced to the Picker as part of the new data binding functionality (more if you count the backing static BindableProperty properties, but we don’t need to directly address those). ItemsSource, SelectedItem,...
Bindable Native Views – Xamarin.Forms 2.3.3 Look Ahead

Bindable Native Views – Xamarin.Forms 2.3.3 Look Ahead

In the last post on the new features of Xamarin Forms 2.3.3 we took a look at Platform Specifics – both how to create one and how to consume one. This time around we’re going to turn our attention to bindable native views in XAML! Again this feature seems to be taking away the need to create custom renderers by giving developers the ability to directly place native (as in 100% iOS or Android or UWP controls) into a Xamarin.Forms core project – and we’re talking putting them into XAML here! Not only that, they are bindable! (As we’ll see, they have to be bindable, because they are not accessible from the code behind file at all.) So let’s dive right in! Adding Native Bindable Views Before we get started with how to add a native view/control – there is a quick gotcha (and isn’t it great when I have to start out with a warning first? This isn’t so bad.) You cannot have XAML compilation turned on for the XAML pages that contain the native views. That’s not ideal. I would recommend you turn it on for every XAML page that does not contain a native view, but leave it off for the ones that do. So in other words – class level, not assembly level. OK – adding one of these native views. A page that has a native iOS UILabel would look like the following: <?xml version="1.0" encoding="utf-8"?> <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" xmlns:local="clr-namespace:XAMLb" xmlns:ios="clr-namespace:UIKit;assembly=Xamarin.iOS;targetPlatform=iOS" x:Class="XAMLb.XAMLbPage"> <ContentPage.Content> <ios:UILabel Text="Hello from an iOS label" View.VerticalOptions="Center" View.HorizontalOptions="Center" /> </ContentPage.Content> </ContentPage> 123456789101112  <?xml version="1.0" encoding="utf-8"?><ContentPage xmlns="http://xamarin.com/schemas/2014/forms"         xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"         xmlns:local="clr-namespace:XAMLb"         xmlns:ios="clr-namespace:UIKit;assembly=Xamarin.iOS;targetPlatform=iOS"        x:Class="XAMLb.XAMLbPage">    <ContentPage.Content>        <ios:UILabel Text="Hello from...
Platform Specifics – Xamarin.Forms 2.3.3 Look Ahead

Platform Specifics – Xamarin.Forms 2.3.3 Look Ahead

Lately it seems that the Xamarin.Forms team has been spending a lot of time making it easier to access the individual platform’s functionality, be it iOS, Android or Windows, from the core shared project. And maybe more importantly, everything being introduced seems to be taking away the need to create custom renderers! Platform Effects have been introduced for tweaking small UI related properties of native controls. Native embedding has been introduced to add platform controls that Xamarin.Forms does not contain directly inline (and you don’t need to use compiler directives in your shared projects either!). Now with Xamarin.Forms 2.3.3 on the horizon, two more features are being introduced that continue down that path – the ability to add native views directly into XAML and something called Platform Specifics. This post is going to take a look at Platform Specifics in-depth, because to be honest, when I first saw them – I had a hard time wrapping my head around them … and I didn’t understand their usefulness at first. But they’ve grown on me and I definitely see their utility now. In a future post I’ll take a look at adding native views directly into XAML. What Is a Platform Specific? This is the part that took me the longest to get my head wrapped around … I mean, a platform specific allows you to access platform functionality from the core Forms project – you can tell that much by the name. There’s already tons of ways you can do that in Forms so what makes a Platform Specific different … what is it? The best way to think...
Code Mill Minute: Stopping the “ThisApp May Slow Down Your iPhone” Message

Code Mill Minute: Stopping the “ThisApp May Slow Down Your iPhone” Message

Welcome to another Code Mill Minute installment! Or where I take a break from writing a long article and write a quick post about a small problem or annoyance that we Xamarin developers happen upon every day. In this installment we’re going to take a look at a brand new “warning” message that pops up in iOS 10.1 about how our app may slow down an entire iPhone unless the developer improves the app’s compatibility. (Talk about your doom and gloom!) I came across this error message after I created a brand new Xamarin.Forms project. After File->New I normally move some directories around to get them the way I like and then update the NuGets. I then run the blank template app to make sure nothing weird happened … and boom! All of a sudden I get the screenshot on the right and iOS is telling me I have slow code! I didn’t even write anything yet!! The Issue The underlying issue is that Apple is trying to rid their app ecosystem of 32 bit applications. So although 64 bit applications had be submitted since Feb 1, 2015 – depending on how you had your build options set up, a lot of the time a 32 bit app would be included in the overall app bundle … so there would be one “version” of the app for older 32 bit iPhones and then another “version” for the newer 64 bit ones. Evidently Apple’s not cool with that any longer. The Fix Easy enough – just have to tell Xamarin Studio (or Visual Studio) which architectures to support within the...
Banish Compiler Directives From Shared Projects!

Banish Compiler Directives From Shared Projects!

Shared Projects definitely take their share of bashing – if you spend any time at all talking to somebody who used Shared Projects in their app – they’ll spend the entire conversation staring at the ground, eventually apologize profusely and then offer to buy you lunch – because well … PCLs! In fact, one would think that compared to PCLs, Shared Projects are inferior and if you use them, your app will be full of bugs and will never get downloaded! Now I’m not going to spend this entire post defending Shared Projects, or giving instructions on how to use them – I already did that here and here and here. But one of the things I hear people complain about with Shared Projects more than anything else is that you need… NEED… to use compiler directives with them. Stop the presses! You don’t need to use compiler directives! With some creative use of partial classes and what I call the poor man’s bait and switch … the only time you’ll have to see that hashtag again is when you’re tweeting how awesome this post is! (Let’s agree to use #SharedProjectsRule, shall we?) OK – I’m fooling around and being sarcastic … but I am serious that you don’t have to use compiler directives with Shared Projects. Let me demonstrate how to with the super cool Native Control Embedding feature from Xamarin. I’m going to take James Montemagno’s blog post introducing Native Embedding and refactor it so it doesn’t use compiler directives. You can find the finished solution on GitHub here. (That blog post creates an UISegmentedControl in iOS...