Nick's .NET Travels

Continually looking for the yellow brick road so I can catch me a wizard....

MVX=0F Side Note: Adding a Splash Screen

I received some feedback on my previous post on setting up MvvmCross for Xamarin.Forms, asking how to add a splash screen to the Android Forms application. In the post MVX=0 I converted the MainActivity that comes as part of the standard Xamarin Android project into a SplashScreen but when it came to the Android project for Xamarin.Forms I left it without a splash screen.

Luckily adding a splash screen is really easy, so let’s add one to the Forms.Droid project:

  1. Copy the SplashScreen.axml from the /Resources/layout folder in the FirstDemo.Droid project into the /Resources/layout folder in the Forms.Droid project
  2. Remove “MainLauncher = true” from the Activity attribute on the MainActivity
  3. Change the MainActivity inheritance:
    public class MainActivity : MvxFormsAppCompatActivity<MainViewModel>
  4. Add a new class, SplashScreen.cs:
    [Activity(Label = "FirstDemo.Forms.Splash", Theme = "@style/MainTheme", MainLauncher = true, NoHistory = true)]
    public class SplashScreen : MvxFormsSplashScreenAppCompatActivity<MvxFormsAndroidSetup<Core.App, App>, Core.App, App>
    {
         public SplashScreen() : base(Resource.Layout.SplashScreen)
         {
         }
  5.     protected override void RunAppStart(Bundle bundle)
         {
             StartActivity(typeof(MainActivity));
             base.RunAppStart(bundle);
         }
    }

And there you have it – the Android Xamarin.Forms project will launch with a splash screen before redirecting to the MainActivity which will host the Xamarin.Forms content.

Declarative C# as an alternative to XAML

Yesterday I had one of those moment where one minute you’re super opinionated on something, only for someone to point out how things have changed and that you should re-evaluate your position – As much as I have my personal preferences on a lot of developer related topics, I try to listen to those around me and look at why they’re doing things their way, and whether I can adapt/learn/extend what I’m doing.

Yesterday in my post talking about CSS in Xamarin.Forms I made a comment that developers building for Xamarin.Forms should be using XAML and “if you’re doing it in code, you’re wasting everyone’s time”. Almost immediately after posting this I was following a related twitter thread (Adam’s thread on whether XAML is holding Xamarin.Forms back) and I saw a link to the work that Vincent has been doing on using declarative c# instead of XAML. This started with a discussion on the Xamarin forums: https://forums.xamarin.com/discussion/123771/using-declarative-style-c-instead-of-xaml-should-xamarin-redirect-xaml-efforts-elsewhere? Then Vincent provided a link to his repo on Github: https://github.com/VincentH-Net/CSharpForMarkup

My issue with using C# to define layout is that out of the box it’s very difficult to construct layouts without it making it look like a jumbled mess – XAML makes the layout very clean and easy for any XAML developer to easily grok what’s going on. However, what Vincent has done is provide some simple extensions that make it possible to define the layout in a very fluent manner.

Whilst I still prefer, and would recommend using XAML, if you must use C# to define layouts, you should look at the work Vincent has done and perhaps leverage it in your code. Furthermore I’d love to see some metrics on whether there is a noticeable performance gain in using C# versus compiled XAML, and how to handle styles, templates and other resources in code.

Xamarin Forms gets CSS to pander to web developers

I just finished reading a good post by fellow Microsoft MVP, Sam Basu, looking at how to use CSS for styling web development. Since becoming aware of the intent to add CSS as a styling option with Xamarin Forms I’ve been an advocate against it, not because I’m “not a web guy” but because the platform doesn’t need options. Xamarin Forms is a great platform and one that I’ve been talking, blogging and working with since it was created; it’s not perfect but it’s incredibly powerful in how quickly cross-platform applications can be generated. What it does not need is a second alternative for styling.

In talking with the product team and other Xamarin Forms developers I’m always keen to understand their opinions, so I decided that I’d review Sam’s list of CSS benefits and try to boil them down into why I think the decision was made to add CSS. My summary of the list it comes down to (I’ve discounted the other comments because they’re just statements, not really benefits of CSS over XAML styling):

- The developer ecosystem is inundated with web developers (ie people who know and understand CSS) so let’s give them a technology they’re familiar with (without having to learn anything new)

- CSS is less verbose

- CSS offers additional styling inheritance

-  CSS can be shared between web and Xamarin Forms applications

Let me leave the first point for a second – I promise I’ll come back to it. The second point regarding CSS being less verbose is a bit irrelevant since intellisense/autocomplete makes writing XAML styles super quick; XAML styles are then compiled and so don’t need to be parsed in the way CSS does. I have to admit, one of the only benefits I see of using CSS is around styling inheritance and referencing – this has always been a limitation of XAML styles and one that I would love to see a fix for, rather than cobbling some other styling alternative. The last point regarding sharing CSS between web and Forms might be nice in theory but as we’ve seen say across Phone, Windows, Xbox, the reality is that most of the styling needs to be adjusted per platform anyhow, so the benefits are marginal at best.

The article goes on to talk about some caveats – I’ll rephrase this as “Here are the reasons you should never use CSS in you Xamarin Forms application”:

- XAML styling is, and I’m guessing, will continue to be the primary way to do styling in Xamarin Forms – anything else will be built on top of this meaning that all new features will come later, if at all, to CSS

- There are some limitations on what CSS can do, even today – do you think this will get addressed any time soon? I wouldn’t be betting the future of any project on these getting addressed in the short term, if ever.

- CSS is parsed – Xamarin/Xamarin Forms adds enough overhead as it is, do you really want to slow down your mobile apps further. Just on this note, please make sure you optimise your apps, leveraging XAML compilation

Ok so I mentioned I’d come back to the first benefit of using CSS which is that it’s a familiar technology for web developers – the reality is that Xamarin.Forms is for building mobile applications and unless you’ve come from a background of building SPAs with offline capabilities (such as building a PWA), chances are you’re going to need to learn a bunch more than just XAML syntax. Furthermore, if you’re going to be building with Xamarin.Forms you need to be using XAML to layout your pages (if you’re doing it in code, you’re wasting everyone’s time), so why wouldn’t you use XAML styling too.

Now, do I think that XAML styling is perfect? – it is definitely not. The lack of even simple things like multiple inheritance, and in the case of Xamarin.Forms, basic control templates for the standard controls, are annoyances and need to be fixed. I think there is an opportunity to learn from CSS and adapt it to improve XAML across the board. Do I think this is a good enough reason for adding CSS? NO, I repeat NO – you can’t imagine the resource drain that CSS will have on the Xamarin.Forms product team (bugs, feature requests, support for new features).

Going forward I’d like Xamarin.Forms to focus on core requirements with a view to “bringing back the magic”.

PWA Follow Up

It’s clear that talking about Progressive Web Applications (PWAs) is all the rage. I noticed today that fellow Microsoft MVP, Adam Pedley who runs the Xamarin Help website and blog, posted about where PWAs and Xamarin.Forms fit. Whilst I’m not sure I agree with his opening statement about PWAs being started by Google (there is a long legacy of different browsers providing pseudo-offline features which pre-date the term PWA, so the concept itself isn’t new), I will definitely agree that it has been Google that has been championing the cause, with Microsoft adding some behind the curtain support (eg PWABuilder.com). One of the most interesting points that’s worth highlighting is the disconnect between the device features/capabilities that the web and client applications (native, Xamarin or Xamarin Forms) can take advantage of. Whilst the difference is being progressively eroded, there are still plenty of areas where a client application is the way to go. Shout out to https://whatwebcando.today/

image

New BuildIt Release for NetStandard 2.0 (General, States and Forms)

A new release of the following libraries is available via NuGet (v1.1.0.134):

- BuildIt.General

- BuildIt.States

- BuildIt.Forms

Whilst not much has changed in terms of features, behind the scenes there was quite a significant change as we adjusted the solution/project structure, and thus the nuget package structure. We took advantage of the ability to multi-target which meant we no longer have to have separate projects/libraries in order to support platform specific features. BuildIt.General, which used to have a UWP specific library, is now a single libary. Same goes for BuildIt.States. BuildIt.Forms has two libraries, down from the 5 that it used to have.

Additionally we also added direct support for netstandard 2.0. As part of the build process, each library is compiled for netstandard 1.0, netstandard 2.0 and then any platforms that have additional features.

In this release we’ve released multiple packages with the same version number, even though there is an interdependency between them (Forms –> States –> General).

Please reach out and let me know if you see any issues in this release with any of these libraries. We’ll be working to release updates to the other BuildIt libraries over the coming weeks.