James Montemagno: 5 Tips to Properly Style Xamarin.Forms Apps

Xamarin.Forms’ default templates for applications are great! They give you everything you need to get up and running including all three of your app projects and your shared code project. Nothing is faster than this to get a cross-platform application spun up. One thing they don’t do by default is setup nice themes for your applications, in fact they simply use the default device themes, but we can do better.

I wanted to take a quick second to share a few tips on making your Xamarin.Forms app beautiful with just a few lines of code.

Tip 0: Pick a color palette

I had to start my tips at 0 because this tip is so important for your application. Your application needs an identity and a base to start with… a palette that you can pick from.

Take a hint from Google and browse through their Color guidelines and then use http://www.materialpalette.com/ to pick your colors. Use these not only in the app specific theme for Android, but throughout your Xamarin.Forms applications using Styles.

Tip 1: Use a Light Theme

Light themes are iOS’s default theme. Don’t fight it, embrace it. By embracing the light theme there is no need to ever set any custom colors in your application. There is a bit of setup required to get this going on each platform using your new palette.

Android

I have covered this in the past so I wont repost the code, but GO READ THIS POST!! Understanding Android app themes is very important. By applying default Light Holo and Material themes to your application you can completely transform your application.

iOS

There is very little that you need to do to optimize iOS applications since the core theme is already light. The only thing to update is the Status Bar color, which I blogged about earlier, and the title bar color itself. You can accomplish this by opening our AppDelegate.cs and applying a few lines of code in the FinishedLaunching:

Windows Phone

Let’s not forget about Windows Phone as it is the most interesting. By default Windows Phone (silverlight) apps change their themes based on the user preference. You will normally see a dark theme as this is the phone default, but there is a nifty NuGet package from my hero Jeff Wilcox that enables you to manually force a theme for your application. Follow his nifty guide to get you up and running.

Side Tip: On a NavigationPage you may want to set the BarTextColor to White or a shade of black

Tip 2: Don’t set background colors

Unless you decided to ignore Tip 1 and need to go with a custom dark theme there is no need to ever set a background color in Xamarin.Forms for an entire page. You could set it for portion of the page or perhaps strips, but never the full page. Let the main applications theme work for you. This will ensure your font colors work correctly out of the box.

Tip 3: Don’t Use Custom Fonts

Don’t do it unless you REALLY REALLY have to. There is no need to put a comic sans font in your application. Let the platforms work for you. iOS does have plenty of great fonts built right in and I do recommend you customize your iOS apps using these, however let Android’s Roboto and Windows Phone’s Segeo WP work for you.

Tip 4: Padding & Spacing

This tip requires a bit more of an eye for design and a bit of energy. Each platform has some specific requirements around the default padding and spacing that is between controls on the page. Android uses a 8dp baseline grid for components 4dp baseline grid for type alignment. 

Windows Phone on the other hand uses a 10 pixel spacing grid between everything on the screen. Take a look at Jeff Wilcox’s Windows Phone MetroGridHelper to enable an overlay to help with spacing.

You can use Xamarin.Forms Device.OS and OnPlatform to do custom tweaks to your Padding. 

So Much More

These are just 5 of my top tips to help start your Xamarin.Forms app on the right foot, but many of them apply to core iOS and Android applications as well. Do you have tips on styling apps? Leave them in the comments below!

Details

Xamarin: Amazon Web Services Mobile SDKs for Xamarin Now Available

Today, we’re excited to share the launch of the Amazon Web Services (AWS) Mobile SDKs for Xamarin. With these new SDKs, developers can easily connect their high-performance, native Xamarin apps to Amazon’s powerful array of AWS cloud services. AWS platform services provide several powerful solutions, including: identity management through Amazon Cognito Identity, Amazon Cognito Sync, […]

The post Amazon Web Services Mobile SDKs for Xamarin Now Available appeared first on Xamarin Blog.

Details

Xamarin: Join Xamarin at AnDevCon 2015 in Boston

Join Xamarin in Boston, MA from July 30-31 for AnDevCon 2015, the technical conference for software developers and engineers building Android apps. Key members from the Xamarin team will be available to discuss your apps and projects and show you what’s new across our products. We’re excited to give AnDevCon 2015 attendees a close up […]

The post Join Xamarin at AnDevCon 2015 in Boston appeared first on Xamarin Blog.

Details

Wallace B. (Wally) McClure: Data Binding a Custom Cell in Xamarin.Forms ListView

Data Binding a Custom Cell in Xamarin.Forms ListView

The ListView in Xamarin.Forms has a lot of options, and the ability to use a custom cell is one of the more useful features.

Data is the lifeblood of every business. Displaying that data is incredibly important. It doesn’t matter if the company is a brick-n-mortar or an online business — data is important. Here’s how to create a custom cell to display data within a table using Xamarin.Forms.Cell.

Details

Greg Shackles: Solved with a Facepalm: Small Resolution Screenshots with Calabash

As I’ve mentioned on my blog before, I like to use Xamarin’s UITest library (and Calabash, by extension) to help automate the generation of app screenshots. This allows me to reuse my existing UI testing code as well, making it incredibly easy to create the generation scripts.

Earlier this year I ran into an issue where the screenshots being generated for the iPhone 6 and 6 Plus were coming out at a lower resolution than expected, which meant they couldn’t actually be used since Apple validates their dimensions. I subsequently opened this issue on Calabash for it. I spent a little time digging through the Calabash code and didn’t find anything that stood out as being particularly problematic. In fact, the code around screenshot generation was very straightforward and by the books.

Fast forward six months (side note: crap, where did 2015 go?), and in revisiting this code for the first time since then it quickly hit me what was actually happening there. It’s like the old medical diagnostic saying goes:

When you hear hoofbeats, think of horses not zebras.

What was actually happening here is that this particular app wasn’t set up for proper support of the iPhone 6 and 6 Plus sizes, meaning that iOS was actually running them in a scaled mode on those devices. This wasn’t the end of the world, and the app actually didn’t look particularly bad in that mode, but this meant that the resolution of the app wasn’t truly the full resolution of the screen. Saving a screenshot directly from the simulator would be at full resolution, however, which is what caused the initial confusion.

Facepalm City, Population: Me.

To solve this, all I needed to do was switch to using the proper launch screens to enable proper support of these devices. With that in place, screenshots captured through Calabash came out with the expected resolutions. Ultimately this was a pretty silly mistake on my part, but I wanted to share in case someone else runs into this as well.

Details

Mike Krüger: The end of NRefactory 6

I’ve been developing for NRefactory several years now after the roslyn release I made a new 6.0 version. For the 6.0 version there are bad and good news.
The bad news is that it’s no longer in development.

The good news is that the successor of the refactoring part is (RefactoringEssentials). The rest of the code has been moved to the monodevelop source code and is still available and in active development as open source.

So the 5.0 version will remain – and will be still maintained a bit by Daniel Grundwald and me.

Why was this decision made ?

Mostly because most NRefactory6 code was just wrappers around internal roslyn classes (and making them public). I don’t think that it’s worth as a stand alone library.
Since #Develop was discontinued the 2nd big NRefactory user is no longer around and it’s more time effective to move that code to monodevelop and split the refactorings so they can be used in VS.NET 2015 as well.

So I deleted the NRefactory6 today. Bye NRefactory we had a nice time – and hello RefactoringEssentials 🙂

Details