TL;DL – .NET Rocks! 1372 (Building Mobile Apps using MFractor with Matthew Robbins)

Show link.NET Rocks! 1372 (Building Mobile Apps using MFractor with Matthew Robbins)

GuestMatthew Robbins

Show Notes

  • MFractor is for Xamarin Studio; what does it do?
    • It provides XAML code analysis (e.g., does a symbol exist, auto-correction for simple mistakes) and C# code generation.
    • It can link up symbols in XAML to their .NET counterparts so you can navigate to them.
    • There is IntelliSense — which isn’t currently in Visual Studio’s Xamarin.Forms — built into Xamarin Studio; but MFractor adds that capability for Android string resources.
  • There’s a slew of small features that when combined make the experience much better.
    • Example: verifying that a toast notification has been shown.
    • MFractor tries to solve the burden of finding problems at design-time.
  • Finding run-time errors is frustrating because usually the error isn’t helpful.
    • Xamarin.Forms uses inflated XAML (i.e., take the XAML and expand it out to make the view hierarchy). All the issues arise when that operation happens. You get really obtuse errors (e.g., bad binding expressions).
    • Example: when fixing XML by adding a namespace, you don’t get an error at that point — you get it when you try to invoke that object. Xamarin tried to mitigate this by doing compiled XAML (i.e., build-time conversion of XML into compiled C# to make it a compile-time error), but it’s still a post-build error, not a design-time error.
  • Convince me to use Xamarin Studio for Xamarin.Forms.
    • The friction for a Xamarin developer is lower in Xamarin Studio. Visual Studio is bulky; Xamarin Studio is a streamlined IDE specifically for making mobile development easier.
    • You can develop on a Mac in .NET; you don’t need a simulator. Note: The simulator on the Mac doesn’t support touch/gestures.
  • What are some code generation features of MFractor?
    • Creating properties from binding expressions. Typically you create the property in the view model, then bind to it from the XAML. The generator inverts that process: Create the XAML binding, then right-click to generate the property on the view model automatically.
    • Auto-completion comes out of the box with Xamarin Studio.
    • The focus is to create the boilerplate code that we shouldn’t have to write. With XAML, so much is ceremonial.
  • There is a designer for XAML — which you can’t get away from using with iOS — but for Android development, Matthew does it by hand, as it seems quicker.
  • There’s a cycle of writing code, and then looking at the results when dealing with mobile apps that have to show up on multiple devices. It’s hard because the devices differ from what you’re building on.
  • What are some of the Xamarin.Forms-specific features in MFractor?
    • XAML analysis; it uses Roslyn to run about 40 code checks (e.g., binding expression resolution, spelling error, types to generics, namespace resolution).
    • There are tooltips — e.g., hover over a binding expression and it will try to figure out the binding context and the type being bound to.
    • MFractor makes it easier to navigate to/from the view, code-behind, and view model.
  • What is Fody?
    • Fody is a tool that re-weaves your assembly after it’s been built to add code for you.
    • For example, you can annotate your class with ImplementPropertyChanged, and Fody implements that for you on all properties with public getters and setters.
  • Do you spend much time in the Universal Windows Platform (UWP)?
    • No; not many of my peers are developing for UWP, so there’s not much demand.
  • With the app your company is building for Android and iOS in Xamarin.Forms, how much platform-specific code are you writing?
    • At most 15-20%; this percentage could be lower but depending on third-party packages can be an issue in terms of support. You can also run into issues when targetting a specific Android API level.
  • Does most of the pain from development occur when the platform OS gets updated?
    • Yes, that’s one. You’ll have a major version upgrade to go through, so Xamarin.Forms updates in turn. Third-party packages also need to be updated, and they could be late depending on how actively they’re supported.
  • How much knowledge is necessary about underlying platform architecture and APIs to be a successful Xamarin.Forms developer?
    • If you’re just starting out, minimal knowledge is needed; Xamarin.Forms is good at abstracting things away.
    • When developing long-running or complex apps (e.g., video streaming, custom charting controls), you’ll need more advanced platform knowledge. The Android activity lifecycle can be tricky to get right.
  • Where can we find guidance for iOS and Android so that we can create well-behaved long-running apps?
    • The Xamarin website has good docs. There’s an “advanced” section, where they explain their architecture and how to best manage that alongside the constraints of the platform.
    • Stack Overflow is another good resource.
  • What’s next for MFractor?
    • More XAML code generation — e.g., figuring out what value converter you’re trying to use.

Better Know a Framework

Xamarin Components; open-source plugins that work with Xamarin Forms. You can use the native dependency object to access components such as the file access, geolocation, accelerometer, etc. or you can use Xamarin Components. Write the code once in your shared or PCL process.

Listener E-mail

From show #1309 (Instrumenting Mobile Apps with Greg Shackles); it can be a bit “Big Brother” to have a vendor know when their app fails and contact you. The likelihood of acceptance depends on the users — e.g., having an automated home system vendor contact you proactively would be very welcome. The corporate environment also works because everyone expects to be monitored.

Technology Giveaway Ideas

MacBook Pro