Creating a round button in Xamarin Forms

For a Xamarin Forms app I’m currently working on I wanted to have round buttons. This should normally be pretty easy, by defining a style in your App.xaml:

<Style x:Key="PrimaryButtonStyle" TargetType="Button">
    <Setter Property="BackgroundColor" Value="Transparent" />
    <Setter Property="BorderColor" Value="White" />
    <Setter Property="TextColor" Value="White" />
    <Setter Property="BorderWidth" Value="1" />
    <Setter Property="WidthRequest" Value="50" />
    <Setter Property="HeightRequest" Value="50" />
    <Setter Property="BorderRadius" Value="25" />

When you use this style for a button, it works great on iOS and the Universal Windows Platform, but it didn’t work on Android. The problem seems to be that our app inherits the new FormsAppCompatActivity. The included compatibility button renderer however ignores the BorderRadius property.

After searching for hours, the solution turned out to be pretty simple. By creating a custom button renderer and inheriting the default, it overrides the compatibility renderer and the round button works on Android:

[assembly: ExportRenderer(typeof(Button), typeof(Project.Droid.RoundButtonRenderer))]

namespace Project.Droid
    /// <summary>
    /// Overrides AppCompat problems with round buttons. Works like a charm!
    /// </summary>
    public class RoundButtonRenderer : ButtonRenderer
        protected override void OnDraw(Android.Graphics.Canvas canvas)

        protected override void OnElementChanged(ElementChangedEventArgs<Button> e)

Credits to the answer on Stack Overflow here:

Show your version number in ASP.NET Core in 2 steps

I always find it useful when working on a project to be able to see the version number of the product somewhere. This doesn’t necessarily have to be shown to the end user later on, but when you’re deploying very often I find it very helpful.

Step 1: set your current version number

  • Right-click on your ASP.NET core web project, and select Properties
  • Go to the Package tab
  • Change the Package Version variable to the version you want
  • Save the properties, and Build the project

Step 2: Show the version number in your web application

Choose the place where you want to show your version number. You can use the following Razor code to show the version:


Simple branching advice

A friend of mine asked me the following questions:

  • Are you working in different branches?
  • Are you working in the same project as other developers at the same time?

As this is a topic of much debate at most offices around the world, I’m writing my own advice here. As I work almost exclusively in Visual Studio, my experience and advice is limited to that environment, and to relatively small teams.

Here’s my rule:

Try to avoid branching at all times!

Branching always costs valuable time. It takes time merging. It takes time resolving conflicts or a bad merge. It takes time explaining how it works and what features should be implemented on what branches. It takes time keeping track of your branches.

Here’s the workflow I prefer, which avoids almost all conflicts:

  1. Write a little piece of functionality.
  2. If it works and builds, check it in.
  3. If you know your affecting other developers, be sure to communicate this to them. Then check it in.
  4. Make sure your team gets the latest source after you added a conflicting change (I’m looking at you code first migrations!).

I almost never encounter any problems using this workflow. It’s great. Even when working with more developers in one project, you shouldn’t encounter much trouble.

That said, there are 2 scenario’s when I do use branching:

  1. Feature Reviews
    When there’s a new or junior developer, I always let them work on their own branch first to implement a feature. When they are done, they create a pull request in VSTS so we can review their work together. We can discuss the code and make changes if required.
  2. Production Releases
    Once you’ve got a version in production, you have to be able to provide hotfixes for it. I do this by creating a branch for that release. When there is a critical bug, it can be fixed on that branch. If applicable the fix can be merged back into the main branch. Creating a branch for each release you need to support and developing further on the main branch keeps the merges as limited as possible.

GTD in Evernote

Bij de implementatie van Getting Things Done (GTD) kwam ik al snel uit bij het selecteren van een tool. Ga ik de lijstjes op papier bijhouden, of toch een applicatie? Ga ik prive en zakelijk mixen, of net niet? Zet ik mijn lijstjes in outlook, of toch todoist, remember the milk, of evernote?

Sinds ik het Getting Things Done boek van David Allen in mijn handen kreeg heb ik talloze applicaties geprobeerd. Na jaren zoeken bestaat de ‘perfecte’ tool voor mij nog steeds niet, en wilde ik een langere tijd mijn energie eens steken in het proces in plaats van de tool. Ik nam  me voor om een jaar lang dezelfde applicatie voor mijn GTD proces te gebruiken.

Mijn keuze is toen gevallen op Evernote. Evernote is niet direct een taakapplicatie, maar kan er wel voor gebruikt worden. Evernote is een zeer flexibele applicatie, en kan dan ook op meerdere manieren gebruikt worden voor het GTD proces. Deze post toont kort de mogelijke manieren om Evernote als GTD tool te gebruiken.

Tags of notebooks?

Een GTD implementatie in Evernote kan op verschillende manieren:

  • Notebooks gebruiken (in combinatie met notebook stacks) voor lijstjes
  • Tags gebruiken voor lijstjes
  • Een combinatie van beiden


Notebooks gebruiken in Evernote voor je actielijstjes ziet er bijvoorbeeld zo uit:


De bekende lijstjes in GTD zoals @Computer, @Calls en @Home zijn hier gebundeld in een Notebook Stack.
David Allen adviseert in zijn eigen Evernote handleiding aan om Evernote op deze manier in te richten. Dit is inderdaad de simpelste oplossing, vooral als je niet bekend bent met de tagging functionaliteit in Evernote.


Een aanpak genaamd The Secret Weapon bied een geheel andere aanpak. Deze opzet gebruikt 1 notebook en werkt volledig met een gelaagde tag structuur. Veel aanhangers van Evernote zweren bij taggen, deze implementatie past hier een stuk beter bij. Op de site staan diverse filmpjes die je laten zien hoe je je systeem kunt inrichten.


Wat is nu beter?

Uiteindelijk gaat het om wat voor jou fijner aanvoelt. Ik heb ze beiden geprobeerd, momenteel gebruik ik de simpelere notebook aanpa weer. Beide inrichtingen werken echter prima. Op een mobiel device kan het zijn dat beide inrichtingen wel net iets anders weergegeven worden, dit ligt een beetje aan het mobiele platform dat je gebruikt. Als je nieuw bent in Evernote, is de eerste aanpak wat laagdrempeliger om mee te beginnen, en kun je later eens wat tags gaan gebruiken om te kijken hoe dat werkt. Het is echter geheel persoonlijk.