Disclaimer: this is an automatic aggregator which pulls feeds and comments from many blogs of contributors that have contributed to the Mono project. The contents of these blog entries do not necessarily reflect Xamarin's position.
This blog post explains how to build your Unity project stored inside a Plastic Cloud Edition repository.
Unity Cloud Build does not provide native support to download code from Plastic, but it is possible to take advantage of the Plastic ability to synchronize with Git to solve the problem.
We explain how to use GitLab as an intermediate storage for Plastic repos so that Unity Cloud Build can access them.
Last fall, Apple announced that new applications and updates would need to support the Apple Watch Series 4.
“Starting March 2019, all new apps and app updates for iPhone, including universal apps, will need to be built with the iOS 12 SDK and support iPhone XS Max. All new apps and app updates for Apple Watch will need to be built with the watchOS 5 SDK and support Apple Watch Series 4.”
The Series 4 watch runs on a new processor architecture, ARM64_32, and the Xamarin team has been hard at work adding support.
Today, we have a preview ready for testing and app submission. It is based upon the Xamarin.iOS SDKs shipping with Visual Studio 2019 and Visual Studio for Mac 8.0, currently in preview.
To get started, install or upgrade to the latest preview of Visual Studio, and then install the appropriate preview of Xamarin.iOS:
After installing the preview, one manual step is required to opt-in to the new support.
ARMv7k, ARM64_32Currently, ARM64_32 (and thus Apple Watch Series 4) builds are limited to the Release configuration. Make sure to confirm that you are using Release builds when deploying to the Apple Watch Series 4 as debug builds are not supported in this preview.
We encourage you to try it out this preview and we look forward to receiving your feedback. If you have feedback or run into any issues, please create an issue on GitHub so that our team can look into it.
The post Get Your Apps Ready for Apple’s New Watch Processor Architecture appeared first on Xamarin Blog.
One of the most frequent questions we receive about Xmerge, Plastic SCMs built-in mergetool, is why the following merge scenario does not automatically resolve:
Xamarin.Essentials are your ultimate open source library to access native features from a single cross-platform API. Since the first release, we have received awesome feedback on GitHub from developers that integrated it into their apps. We have also received some great pull requests to add some new features and bug fixes that have gone into the newest release 1.1.0 that are available today. This includes the ability to detect shake movement of the device, customization when opening the browser, ability to check for mock location, and several platform helpers.
Sometimes you need to detect shake movement of a device that your app is running on to open a feedback form or put the app into edit mode. Xamarin.Essentials’ built-in Accelerometer API gives you everything you need to calculate this cross-platform. Having to figure out all of the math and queue systems could be a bit much. So we figured why not just create a unique ShakeDetected event that you can register for. You will still have to start the Accelerometer, but now you have the option to get all changes or just when a shake is detected:
public override void OnAppearing()
{
Accelerometer.ShakeDetected += Accelerometer_OnShaked;
Accelerometer.Start(SensorSpeed.Normal);
base.OnAppearing();
}
void Accelerometer_OnShaked(object sender, EventArgs e)
{
ShakeTime = $"Shake detected: {DateTime.Now.ToLongTimeString()}";
}
public override void OnDisappearing()
{
Accelerometer.Stop();
Accelerometer.ShakeDetected -= Accelerometer_OnShaked;
base.OnDisappearing();
}
When you need to launch a website the best approach is to use the built-in Open Browser from Xamarin.Essentials. It will automatically handle opening the system optimized browser with SFSafariViewController and Chrome Custom Tabs. In the new release of Xamarin.Essentials you now have more control over the look. You can also get the feel of the browser including the title visibility and the colors of the toolbar and controls.
await Browser.OpenAsync(uri, new BrowserLaunchOptions
{
LaunchMode = BrowserLaunchMode.SystemPreferred,
TitleMode = BrowserTitleMode.Show,
PreferredToolbarColor = Color.AliceBlue,
PreferredControlColor = Color.Violet
});
The core goal of Xamarin.Essentials is to simplify cross-platform app development. Most of the APIs that are part of the library up until now have abstracted common platform features into a single API. Xamarin.Essentials 1.0 launched with a plethora of built-in unit converters such as converting Miles to kilometers or Celsius to Fahrenheit. With this release, we are pleased to introduce several key helper utilities for converting between .NET and platform structures such as Color, Rect, Size, and Point.
For System.Drawing.Color we want to bring all of the goodies that Xamarin.Forms developers are able to take advantage of such as creating color from Hsl, Hex, or UInt.
var blueHex = ColorConverters.FromHex("#3498db");
var blueHsl = ColorConverters.FromHsl(204, 70, 53);
var blueUInt = ColorConverers.FromUInt(3447003);
Additionally, you can easily convert System.Drawing.Color to the platform specific color structure:
var system = System.Drawing.Color.FromArgb(255, 52, 152, 219); // Extension to convert to Android.Graphics.Color, UIKit.UIColor, or Windows.UI.Color var platform = system.ToPlatformColor();
var platform = new Android.Graphics.Color(52, 152, 219, 255); // Back to System.Drawing.Color var system = platform.ToSystemColor();
Just like the Color extension methods to convert to and from the platform specific classes can be done with Size, Rect, and Point:
var system = new System.Drawing.Size(width, height); // Convert to CoreGraphics.CGSize, Android.Util.Size, and Windows.Foundation.Size var platform = system.ToPlatformSize(); // Back to System.Drawing.Size var system2 = platform.ToSystemSize();
The same can be done for Rect with ToPlatformRectangle and ToSystemRectangle and for Point with ToPlatformPoint and ToSystemPoint.
We want to call out the amazing community contributions that helped make this release possible:
| Contributor | Description |
|---|---|
Chris Dinon |
Use Apply on Android Preferences (#636) |
Niklas Schilli |
Browser Customization APIs (#196) Fix Launcher Sample (#629) |
Pedro Jesus |
Add IsFromMockProvider for Geolocation (#676) Detect Shake API (#126) |
We have also received several great bug reports and feature requests from the community, which has been great to see! If you are looking to help out simply head over to the Xamarin.Essentials GitHub page to open an issue or send a pull request.
You can learn more by browsing the full Xamarin.Essentials documentation including new documentation for Detect Shake, Color Converters, Platform Extensions, Browser options, and more. Additionally, each week you can find a brand new Xamarin.Essentials API of the Week videos covering a single feature in just a few minutes.
The post Xamarin.Essentials Adds Detect Shake, Browser Customization, Color Helpers, and More! appeared first on Xamarin Blog.
Developers around the world use Xamarin every day to build beautiful native mobile apps with .NET. What better way to highlight the amazing work that these developers are doing than with a customer showcase. As you browse through you will find customers building apps for all industries including consumer-facing, service, healthcare, charity, and enterprise.
Each customer in the showcase has a full case study to learn more about how they leveraging .NET to build mobile apps with Xamarin. It also showcases other services here at Microsoft including Azure, App Center, Azure DevOps, and more! Additionally, you can even download and try these apps from the app stores including several apps developed here at Microsoft:
As you browse through the customer shows you will find additional customer stories on the official Microsoft Customers site covering all Microsoft technologies. You will also find a link directly to the new community built and community maintained community showcase: BuiltWithDot.net
There you can browse through apps and libraries built not only with Xamarin but with all .NET technologies. You can even submit your very own project to get it featured, so head over there now and submit your app today.
We hope that you love the new customer showcase highlight amazing companies and developers building .NET mobile apps with Xamarin.
The post Introducing the New Xamarin Customer Showcase appeared first on Xamarin Blog.
One of the best parts about using Xamarin for mobile development is access to all of the platform APIs from C# bindings. Additionally, any native iOS or Android library can be consumed by a Xamarin application by creating a custom binding project. That’s exactly what the Component Team here at Microsoft does for the most popular libraries that developers need access to. In the last 6 months, there have been drastic changes across several key libraries such as Google Play Services and Android Support Libraries. To catch everyone up on work that the team has been doing, what is available for you today, and what’s coming in the future.
The first thing to share is that all of the work our team does is completely open source on GitHub. This is the best place to follow the work for any SDKs that our team supports. It is also the official place to report any issues. Here is a quick list of the official open source components that you may want to follow:
To stay up to date by Starring each of the repositories on GitHub. Turn on notifications under Watch as well to ensure you don’t miss a release!
We also encourage pull requests to any of the component repositories, including fixes for existing bindings or new 3rd party bindings, that you may be doing yourself.
Google moves fast updating their APIs across iOS and Android. We wanted to give you an update on the libraries and technical work that we have been doing to keep up to date.
Recently we’ve invested substantial time and effort into improving the way we create and maintain bindings for massive SDKs such as Google Play Services / Firebase for Android and Android Support libraries.
A lot of these changes have been happening quietly, behind the scenes but they are nearly complete. These improvements will not only help increase the reliability and consistency of our updates but allow us to react more quickly to new releases and changes in the future.
We support many of the major Google and Firebase SDKs from Google for iOS and you can find a full list and version number mapping on the official Google APIs for iOS GitHub repository. Newly added to the list is support for Firebase ML-Kit. Recently some libraries were deprecated by Google and the updates broke older versions of our bindings such as mobile ads. These breaking changes were reported by the community which alerted us to take quick action to prioritize finishing the work the team had already started.
If you haven’t already done so, check out our latest bindings for Android Support libraries v28 with multi-targeting to make installation in your projects easier.
The Components and Android teams have also been hard at work on AndroidX support for Xamarin. Our initial work at providing bindings to these libraries is almost complete, and we will be releasing preview packages for them soon. You can track the binding work on the AndroidX branch of the official AndroidX GitHub repository. Later this year we will be introducing support for helping you migrate your existing apps and third-party dependencies which currently use Android Support libraries to the new AndroidX ecosystem.
You asked for it, and we’re on it! We’ll be releasing bindings for Android Architecture WorkManager very soon so you can get on with scheduling your work!
This year saw another major change in the Android ecosystem with Google splitting up Play services and Firebase libraries for Android into individually released artifacts. As part of our previously mentioned core work on improving our binding process, we are very close to bringing you another release of bindings for Google Play services and Firebase libraries for Android. Google has deprecated some older library versions and included bugfixes in these versions which you’ll soon be able to use in your apps! Our progress can be seen in the 15.0.1-binderate branch of the official Google Play services & Firebase for Android GitHub repository.
The team is always hard at work keeping up with the latest updates and changes that library creators are making in these SDKs. We will always prioritize breaking app SDK changes in our work sprints as we are made aware of them. With the vast amount of components that the team supports we are taking a strategy of prioritizing based on core consumption of libraries through NuGet. Through looking at the numbers we know that there are several essential libraries that a vast majority of our developers are using today and those are put at the top of our list for updates. We are here to listen and you can always chat with us in our Xamarin Components Gitter chat room.
The post A Quick Update on Google Components for iOS and Android appeared first on Xamarin Blog.
Over the last four months, part of the team was quite busy working on an evolution for the Plastic server.
We wanted to provide Enterprise Edition customers with a fault-tolerant, zero-downtime server for their on-premise setups.
This is the story of how we achieved it.
Read more »ARM is important for us. It’s important for IOT scenarios, and it provides a reasonable proxy for phone platforms when it comes to developing runtime features.
We have big beefy ARM systems on-site at Microsoft labs, for building and testing Mono – previously 16 Softiron Overdrive 3000 systems with 8-core AMD Opteron A1170 CPUs, and our newest system in provisional production, 4 Huawei Taishan XR320 blades with 2×32-core HiSilicon Hi1616 CPUs.
The HiSilicon chips are, in our testing, a fair bit faster per-core than the AMD chips – a good 25-50%. Which begged the question “why are our Raspbian builds so much slower?”
Raspbian is the de-facto main OS for Raspberry Pi. It’s basically Debian hard-float ARM, rebuilt with compiler flags better suited to ARM11 76JZF-S (more precisely, the ARMv6 architecture, whereas Debian targets ARMv7). The Raspberry Pi is hugely popular, and it is important for us to be able to offer packages optimized for use on Raspberry Pi.
But the Pi hardware is also slow and horrible to use for continuous integration (especially the SD-card storage, which can be burned through very quickly, causing maintenance headaches), so we do our Raspbian builds on our big beefy ARM64 rack-mount servers, in chroots. You can easily do this yourself – just grab the raspbian-archive-keyring package from the Raspbian archive, and pass the Raspbian mirror to debootstrap/pbuilder/cowbuilder instead of the Debian mirror.
These builds have always been much slower than all our Debian/Ubuntu ARM builds (v5 soft float, v7 hard float, aarch64), but on the new Huawei machines, the difference became much more stark – the same commit, on the same server, took 1h17 to build .debs for Ubuntu 16.04 armhf, and 9h24 for Raspbian 9. On the old Softiron hardware, Raspbian builds would rarely exceed 6h (which is still outrageously slow, but less so). Why would the new servers be worse, but only for Raspbian? Something to do with handwavey optimizations in Raspbian? No, actually.
Common wisdom says ARM architecture versions add new instructions, but can still run code for older versions. This is, broadly, true. However, there are a few cases where deprecated instructions become missing instructions, and continuity demands those instructions be caught by the kernel, and emulated. Specifically, three things are missing in ARMv8 hardware – SWP (swap data between registers and memory), SETEND (set the endianness bit in the CPSR), and CP15 memory barriers (a feature of a long-gone control co-processor). You can turn these features on via abi.cp15_barrier, abi.setend, and abi.swp sysctl flags, whereupon the kernel fakes those instructions as required (rather than throwing SIGILL).
CP15 memory barrier emulation is slow. My friend Vince Sanders, who helped with some of this analysis, suggested a cost of order 1000 cycles per emulated call. How many was I looking at? According to dmesg, about a million per second.
But it’s worse than that – CP15 memory barriers affect the whole system. Vince’s proposal was that the HiSilicon chips were performing so much worse than the AMD ones, because I had 64 cores not 8 – and that I could improve performance by running a VM, with only one core in it (so CP15 calls inside that environment would only affect the entire VM, not the rest of the computer).
I already had libvirtd running on all my ARM machines, from a previous fit of “hey one day this might be useful” – and as it happened, it was. I had to grab a qemu-efi-aarch64 package, containing a firmware, but otherwise I was easily able to connect to the system via virt-manager on my desktop, and get to work setting up a VM. virt-manager has vastly improved its support for non-x86 since I last used it (once upon a time it just wouldn’t boot systems without a graphics card), but I was easily able to boot an Ubuntu 18.04 arm64 install CD and interact with it over serial just as easily as via emulated GPU.
Because I’m an idiot, I then wasted my time making a Raspbian stock image bootable in this environment (Debian kernel, grub-efi-arm64, battling file-size constraints with the tiny /boot, etc) – stuff I would not repeat. Since in the end I just wanted to be as near to our “real” environment as possible, meaning using pbuilder, this simply wasn’t a needed step. The VM’s host OS didn’t need to be Raspbian.
Point is, though, I got my 1-core VM going, and fed a Mono source package to it.
Time taken? 3h40 – whereas the same commit on the 64-core host took over 9 hours. The “use a single core” hypothesis more than proven.
The gains here are obvious enough that I need to look at deploying the solution non-experimentally as soon as possible. The best approach to doing so is the bit I haven’t worked out yet. Raspbian workloads are probably at the pivot point between “I should find some amazing way to automate this” and “automation is a waste of time, it’s quicker to set it up by hand”
Many thanks to the #debian-uk community for their curiosity and suggestions with this experiment!
This post was guest authored and contributed by Matthew Robbins. Matthew is a Microsoft MVP and the founder of MFractor, incredible Xamarin tools for Visual Studio Mac.
MFractor is a powerful Visual Studio for Mac extension to streamline the development of your Xamarin applications. By improving many common Xamarin workflows, MFractor can save a significant amount of development time and effort over the course of your project.
In this article, we’ll explore three of MFractors handiest features, the XAML editor, Image Manager, and Font Importer. We will also discuss how we can leverage them to save time and effort when building our Xamarin apps. Let’s get started by taking a look at the XAML editor.
Have you ever created a data-binding and ran your application only to discover you misspelt the property name? It’s an annoying mistake and let’s be honest, we’ve all done this! Wouldn’t it be great if our ViewModel properties were included IntelliSense to prevent this?
ViewModel property IntelliSense is one of the many features in MFractors XAML editor. By automatically detecting the ViewModel for a XAML file, MFractor suggests your ViewModels properties in IntelliSense. It even lets you generate properties and commands onto your ViewModel.
MFractor checks binding expressions for many common issues, for example, does that property exist in the ViewModel? Additionally, it can provide detailed binding tooltips and includes navigation shortcuts to let you quickly move between your View and ViewModel. The XAML editor also includes dozens of additional completions, 70+ XAML inspections, insightful tooltips, navigation shortcuts and 50+ XAML refactorings to make editing XAML faster and easier.
For example, MFractor can suggest image assets, static and dynamic resources, grid rows and columns and much more. Want to see what image is being used in XAML? Simply hover over the image to see a preview.
MFractors XAML editor is available for free in MFractor Lite; use it in up to 4 XAML files per day!
Imagine that your designer has just handed you a bunch of image assets. Now you need to add them to your Android and iOS projects. We’d have to copy each image into the different density folder, then manually add them one by one into our projects. This highly manual process is a big and expensive time sink in app development.
To improve this workflow, MFractor’s Image Importer can generate new images for the different densities from a source image. Choose a source image and the Image Importer will create a new version of that image for each density. It will then place them into the correct folders and add them to our Android and iOS projects.
The Image Importer is just one of many features included in MFractors Image Manager. A useful tool to simplify image resource management for your iOS and Android projects. Access the Image Manager by going to the MFractor menu in the top menu bar and choosing Manage Image Assets.
The Image Manager gives a ‘birds-eye’ view of all the images across your application. Groups them by name in the left list and displays a preview of that asset. Thus enabling you to visually explore the images in your projects.
You can learn more about the Image Manager in our Simplified Image Asset Management for Xamarin Apps blog post.
The Image Manager is available in MFractor Professional.
Custom fonts are one of the backbones of modern app development. They are critical to an apps branding and fonts like FontAwesome are often used for iconography.
To use a font in Xamarin.Forms, we include adding the font to our Android and iOS projects. Update the Info.plist for iOS to use the FontFamily property and apply the fonts in XAML. All in all, it’s a lot of manual work. It’s very easy to miss a step and then spend an hour debugging to fix it.
Instead of doing this fiddly work, we can use MFractors Font Importer to add a ttf or otf file into our Android an iOS projects. This handy tool adds the new font in each project, creates an Info.plist entry in any iOS projects, and generates the font lookup XAML ready for us to use:
Access the Font Importer through the top MFractor menu. Then select -> Import, Font.
You can learn more about the Font Importer in our Using Custom Fonts In Xamarin.Forms blog post. The Font Importer is available in MFractor Professional.
MFractor is available in two flavours; Lite (free) and Professional (paid).
MFractor Lite is a fantastic value by enabling our XAML Editor in four files per day. Use MFractors XAML IntelliSense to gain ViewModel property code completion. Use 70+ code inspections to spot a range of common issues, 50+ code actions, detail tooltips and navigation shortcuts.
If you want even more powerful features, upgrade to MFractor Professional to use:
To get MFractor, open the Extension Manager using the Extensions item in the main Visual Studio menu. Then, under “Gallery and IDE Extensions”, select MFractor to install. To learn more about MFractor, head to www.mfractor.com.
PS: Use the discount code MFRACTOR-101 to take 10% off MFractor Professional 
The post Enhanced Xamarin Development With MFractor appeared first on Xamarin Blog.
The Visual Studio Mobile Developer Podcast features Matt Soucoup and James Montemagno discussing the latest and greatest in mobile and cloud development.
This month’s Visual Studio Mobile Developer’s Podcast POPs!
Matt and James talk about a ton of newness out there for all mobile developers including a hot new Xamarin documentation landing page. They also discuss the brand new one-stop-shop for all Microsoft development blogs.
But the action does not stop there!
The newness continues with customer app showcases and releases including Xamarin.Forms 3.5, 3.6 AND Xamarin.Essentials 1.1.0.
Plus tune in to get the lowdown on how to supercharge your Xamarin.UITests with something known as the Page Object Pattern – POP POP! We also talk about Microsoft //Build, an amazing Twitch Team (and XamU is even going to be streaming!), some new releases for Visual Studio, and of course… the Pick of the Pod!!
Be sure to download this episode from your favorite podcast app.
Keeping up with the latest in .NET, C#, Xamarin, and Azure is easier than ever. Cohosts Matt Soucoup and James Montemagno cover a range of topics relevant to Xamarin developers from designing mobile apps to identity management. Be sure to subscribe to the Xamarin Podcast on iTunes, Google Play Music, Stitcher, or your favorite podcast app.
The post Podcast: POP! New docs, blogs, customer showcases, and Twitch streams! appeared first on Xamarin Blog.
On mono-project.com, we ship packages for Debian 8, Debian 9, Raspbian 8, Raspbian 9, Ubuntu 14.04, Ubuntu 16.04, Ubuntu 18.04, RHEL/CentOS 6, and RHEL/CentOS 7. Because this is Linux packaging we’re talking about, making one or two repositories to serve every need just isn’t feasible – incompatible versions of libgif, libjpeg, libtiff, OpenSSL, GNUTLS, etc, mean we really do need to build once per target distribution.
For the most part, this level of “LTS-only” coverage has served us reasonably well – the Ubuntu 18.04 packages work in 18.10, the RHEL 7 packages work in Fedora 28, and so on.
However, when Fedora 29 shipped, users found themselves running into installation problems.
I was not at all keen on adding non-LTS Fedora 29 to our build matrix, due to the time and effort required to bootstrap a new distribution into our package release system. And, as if in answer to my pain, the beta release of Red Hat Enterprise 8 landed.
Our packaging infrastructure relies upon a homogenous pool of Ubuntu 16.04 machines (x64 on Azure, ARM64 and PPC64el on-site at Microsoft), using pbuilder to target Debian-like distributions (building i386 on the x64 VMs, and various ARM flavours on the ARM64 servers); and mock to target RPM-like distributions. So in theory, all I needed to do was drop a new RHEL 8 beta mock config file into place, and get on with building packages.
Just one problem – between RHEL 7 (based on Fedora 19) and RHEL 8 (based on Fedora 28), the Red Hat folks had changed package manager, dropping Yum in favour of DNF. And mock works by using the host distribution’s package manager to perform operations inside the build root – i.e. yum.deb from Ubuntu.
It’s not possible to install RHEL 8 beta with Yum. It just doesn’t work. It’s also not possible to update mock to $latest and use a bootstrap chroot, because reasons. The only options: either set up Fedora VMs to do our RHEL 8 builds (since they have DNF), or package DNF for Ubuntu 16.04.
For my sins, I opted for the latter. It turns out DNF has a lot of dependencies, only some of which are backportable from post-16.04 Ubuntu. The dependency tree looked something like:
This ended up in two PPAs – the end-user usable one here, and the “you need these to build the other PPA, but probably don’t want them overwriting your system packages” one here. Once I convinced everything to build, it didn’t actually work – a problem I eventually tracked down and proposed a fix for here.
All told it took a bit less than two weeks to do all the above. The end result is, on our Ubuntu 16.04 infrastructure, we now install a version of mock capable of bootstrapping DNF-requiring RPM distributions, like RHEL 8.
We make various assumptions about package availability, which are true for CentOS, but not RHEL (8). The (lack of) availability of the EPEL repository for RHEL 8 was a major hurdle – in the end I just grabbed the relevant packages from EPEL 7, shoved them in a web server, and got away with it. The second is structural – for a bunch of the libraries we build against, the packages are available in the public RHEL 8 repo, but the corresponding -devel packages are in a (paid, subscription required) repository called “CodeReady Linux Builder” – and using this repo isn’t mock-friendly. In the end, I just grabbed the three packages I needed via curl, and transferred them to the same place as the EPEL 7 packages I grabbed.
Finally, I was able to begin the bootstrapping process.
After re-bootstrapping all the packages from the CentOS 7 repo into our “””CentOS 8″”” repo (we make lots of naming assumptions in our control flow, so the world would break if we didn’t call it CentOS), I tried installing on Fedora 29, and… Nope. Dependency errors. Turns out there are important differences between the two distributions. The main one is that any package with a Python dependency is incompatible, as the two handle Python paths very differently. Thankfully, the diff here was pretty small.
The final, final end result: we now do every RPM build on CentOS 6, CentOS 7, and RHEL 8. And the RHEL 8 repo works on Fedora 29
The only errata: MonoDevelop’s version control addin is built without support for ssh+git:// repositories, because RHEL 8 does not offer a libssh2-devel. Other than that, hooray!
This week, Xamarin.Forms 3.6 shipped with another round of improvements, the most exciting of which is called Visual. Visual enables developers to create beautiful, cross-platform mobile applications that share not only a massive amount of code but also design and behavior. Material Design is the first style of cross-platform controls to take advantage of Visual.
Every month the Xamarin product team surveys Xamarin developers and has hundreds of one-on-one interactions with Microsoft customers to learn how we are progressing on key challenges developers face every day. One such challenge is making your Android and iOS apps look and behave consistently with each other. Xamarin values deep integration with the host platform, culture, and design patterns that are expected by people like us, living and working on their devices. In fact, Xamarin excels at this by providing all those native controls out-of-the-box. When you start a new Xamarin project, you get the same starting point you would get if you started new projects with Xcode and Android Studio.
Today, we believe we can do better to boost your productivity when your design goal is to achieve mostly the same visual appearance and behavior across these mobile targets. In Xamarin.Forms 3.6 we are introducing the first iteration of Visual with a suite of Material design components for Android and iOS. When you enable Material Visual, supported and decorated controls adopt the same design system cross-platform to create a unified look and feel. Let’s look at our implementation of the Material design components to see how this works by making your own, then get you started with Material, and finally look at the roadmap for this exciting new capability.
In 2014, Google introduced the Material design system to describe guidelines for how interactive UI should be implemented in order to achieve highly usable interfaces that would delight people. This system has been so well received, that it inspires many of the mobile app designs we see from you. Let’s start by looking at a Button.
Material Design Buttons from Google’s Material Design Guidelines
If you enable the Material theme in your Android platform project, you will get this design and behavior by default. But what about iOS? Google now also provides a set of iOS controls that implement an interpretation of Material design. Xamarin.Forms Material Visual makes it possible to use both at once and does some additional work to improve the consistency between platforms.
Visual is a set of control renderers. At its most fundamental level, that’s it. You can use Visual today to tie together all your custom renderers across all the Xamarin.Forms backends (platforms). If you are unfamiliar with how custom renderers work, then our documentation guides can bring you up to speed.
Let’s run through the steps for making your own Visual. To begin, declare an IVisual marker in your Xamarin.Forms library.
namespace MyApp
{
public class FancyVisual : IVisual
{
}
}The code is a couple of lines; the marker exists to tie renderers together. Next, in your platform project you add this marker to the custom renderer’s ExportAttribute:
[assembly: ExportRenderer(typeof(Xamarin.Forms.Button), typeof(FancyButtonRenderer), new[] { typeof(MyApp.FancyVisual) })]
namespace MyApp.Droid
{
public class FancyButtonRenderer : ButtonRenderer
{
public FancyButtonRenderer(Context context) : base(context)
{
}
protected override void OnElementChanged(ElementChangedEventArgs<Xamarin.Forms.Button> e)
{
base.OnElementChanged(e);
Element.Text = "I am a Custom Visual Renderer";
}
}
}Now in your XAML, when you use a Button and mark it to use your new Visual="FancyVisual" the Xamarin.Forms toolkit will use your special renderer. You can also omit the “Visual” suffix, Xamarin.Forms will respect both.
<Button Visual="Fancy" />
What about other controls? If no renderer is found for your marker, then the Xamarin.Forms default renderers are used.
When it comes to delivering Material Design consistently across Android and iOS, we are of course using Visual. The Material Design system is opinionated, as are most design systems. It prescribes the size, color, spacing, and potentially other aspects of how individual controls and entire layouts should look and behave. As such, when you adopt Visual=”Material” in your code, those design system rules are applied by highly customized renderers. In the case of Material for iOS, we have supplied those renderers in a specific NuGet package, Xamarin.Forms.Visual.Material.
To get started using Visual in a Xamarin.Forms 3.6 projects, open your NuGet package manager in Visual Studio and add Xamarin.Forms.Visual.Material to the Android and iOS projects. This is the style you want, because…well, it’s the only style available at this time! More on that later.
Note: On Android and iOS, this NuGet delivers Xamarin.Forms optimized renderers, and on iOS provides the transitive dependency to Xamarin.iOS.MaterialComponents, a C# binding to Google’s Material Components for iOS. On Android it provides some compile targets to make sure your Target Framework version is setup properly.
Next, initialize the renderer package in your AppDelegate.cs like this:
global::Xamarin.Forms.Forms.SetFlags("Visual_Experimental"); // ONLY if using a pre-release of Xamarin.Forms
global::Xamarin.Forms.Forms.Init();
global::Xamarin.Forms.FormsMaterial.Init();For Android, update your MainActivity.cs like this:
global::Xamarin.Forms.Forms.SetFlags("Visual_Experimental"); // ONLY if using a pre-release of Xamarin.Forms
global::Xamarin.Forms.Forms.Init(this, savedInstanceState);
global::Xamarin.Forms.FormsMaterial.Init(this, savedInstanceState);
Note: Be sure your Android project is using:
- FormsAppCompatActivity
- Android Support Libraries 28.0.0 or greater
- Target Android framework (v9.0 presently)
- Minimum Android Version 5.0 (API 21) or greater
Now you’re ready to start seeing some Material design. Let’s take a look at 2 Buttons and how you can apply Visual. Notice the difference between the normal buttons and the consistency between the buttons using Visual.
<StackLayout Spacing="8">
<Button Text="Normal Button"/>
<Button Text="Material Button" Visual="Material"/>
</StackLayout>
In the XAML above, we tell Xamarin.Forms to use the Material renderer for the Button on the bottom. Imagine how powerful it is to be able to opt-in and out of Visual per control, even at runtime! You can also declare Visual on any layout, ContentPage, or even at the app level, and it will cascade down to all child controls.
<ContentPage Visual="Material">
<StackLayout Spacing="8">
<Button Text="Normal Button" Visual="Default"/>
<Button Text="Material Button" />
</StackLayout>
</ContentPage>This XAML achieves the same result as the previous. The Default Visual or any control is the base platform renderer. In the animation below from TheLittleThingsPlayground app, you can see a variety of examples of a simple Button in the Material style. Notice the nice ink ripple effect!
Some Limits Apply: Material Design components adhere closely to Google’s guidelines. As a result, the controls are biased towards that sizing and behavior. When you need more control of the styles or behavior, you can still create your own Effect, Behavior, or Renderer to achieve the detail and polish you desire.
The Xamarin.Forms team has adapted and implemented 11 controls for Material design. You can see the list below, and explore these controls in TheLittleThingsPlayground app.
| ActivityIndicator Button DatePicker Editor Entry Frame |
Picker ProgressBar Slider Stepper TimePicker |
Now that we have a stable first release, it’s time to hear again from you. Is this as helpful as we expect? What should we address next?
We have been inviting developers to take a “visual challenge” using this new capability to recreate an existing design that should look mostly the same across Android and iOS. Don’t be shy, you can participate too! We are challenging Visual, not you; though, feel free to show off your skills.
The goal is to spend an hour on the exercise and then submit your progress and learnings in the form of a pull request to the project repository. Here’s what we are learning so far:
We owe a huge thanks to the adventurous souls that have participated thus far:
More have taken the challenge, but not submitted pull requests. There’s still time, and we have more to be learned. Please take a shot and join us! In the meantime, here is a recap of the resources mentioned in this article, as well as future proposals for your consideration.
Here are some other popular examples of design systems:
Today on the Mobile Community Standup, Xamarin.Forms engineer Shane Neuville joined James Montemagno and myself to discuss Visual, Material components, and creating your own Visual. Hit the links below for a look “under the hood”.
The post Beautiful Material Design for Android & iOS appeared first on Xamarin Blog.
Monologue is a window into the world, work, and lives of the community members and developers that make up the Mono Project, which is a free cross-platform development environment used primarily on Linux.
If you would rather follow Monologue using a newsreader, we provide the following feed:
RSS 2.0 Feed
Monologue is powered by Mono and the Monologue software.
Alex Graveley
Alex Rønne Petersen
Andrew Jorgensen
Ankit Jain
Boyd Timothy
Brad Taylor
Brent Schooley
Calvin Gaisford
Christian Hergert
Dan Winship
Daniel Morgan
Eric Maupin
Gaia Ajax
Gendarme
Geoff Norton
Gonzalo Paniagua Javier
Jared Hendry
Jeremie Laval
Joe Audette
Marc Christensen
Marek Habersack
Mario Carrion
Martin Baulig
Michael Hutchinson
Nemerle
Nestor Salceda
Pedro Martínez
Piotr Dowgiallo
Rafael Ferreira
Rafi Mizrahi
Ruben Vermeersch
Touch4Apps
Valentin Sawadski
