We love tools that help our clients save time,
We previously walked through how to get started with a cross-platform Xamarin.Forms project, but what if we started with an Android app built in Android Studio? Here's a way to re-use a lot of our Android code and layouts with Xamarin.
"I'm starting a cross-platform mobile project. What problems should my team solve before we begin?"
What an enlightened question, I thought.
The individual standing next to me at a local developer conference had a software architecture background. He clearly understood that laying a solid foundation at the outset of a project can either spell success, or result in project delays, massive technical debt, and quagmires for even rudimentary tasks.
As a consultant of nearly two decades I've seen all too well the results of poor project planning. After 36 individual projects, eight of which were mobile, 4 of which were cross-platform mobile, I felt comfortable answering the gentleman's question with plenty of first-hand knowledge to back it up.
This post answers the question of what problems a mobile team should consider at project outset. It's expressed in real world mistakes and the resulting consequences as I've witnessed them.
1. Overemphasize One Platform
How hard is it for a .NET developer to build a Fire TV app with C#? With the right tools, it's pretty easy; a Fire TV app is just an Android app optimized for viewing on a TV.
Since .NET's inception, my language of choice has been C#. For the C# developer, Xamarin is a useful tool for deployment to more than one platform, such as Windows, Android, iOS, or in our case, Fire TV. With Xamarin, we can build one set of back-end tests and code in C# and share the same code among all of those platforms.
Xamarin.Forms provides even more shared functionality: with Xamarin.Forms, we can even build our views using a set of controls common to all of our target platforms.
Displaying list data in Android using a custom layout is traditionally accomplished by inflating an AXML file for each row of data. However, in my article introducing EasyLayout.Droid I made the case that AXML files slow development speed and decrease cross platform re-usability.
If you've done much Xamarin iOS work you've probably run into Frank Krueger's awesome framework, EasyLayout, that makes manually coded auto layouts considerably easier to read and maintain.
This article explains what Xamarin is, the basics of how it works, and dispels four common misconceptions.
When Mary Jo Foley and Paul Thurott attempted and failed to describe Xamarin on Windows Weekly a couple of months ago, I grumbled about pundits not performing due research and moved on. But when even Scott Hanselman (who I worship greatly admire) mischaracterized it on his most recent podcast, I realized there is sufficient confusion within our industry that additional clarification is needed.
Welcome to Part 3 of my blog series on cross-platform UI testing. For those who are just joining us, in Part 1 we discussed the high-level strategy for cross-platform UI testing using Xamarin.UITest and CodedUI, and introduced SpecFlow as the glue that holds everything together. I also identified a couple of external resources that helped me put this together including Rob Gibbens' article about BDD Tests with Xamarin.UITest and SpecFlow; and finally we created initial cross-platform . In Part 2 of this series, we took a big step towards implementing Xamarin.UITest patterns on windows by implementing Xamarin's IApp interface and defining a startup process so we could control the application's lifecycle. In this post we will complete our journey by defining screens, creating CodedUI UIMaps, setting up our Xamarin project and ultimately creating our first tests using SpecFlow and Gherkin.