Skip to content

A Podcast for Microsoft Users and Enthusiasts Alike

Microsoft - in a new light

The goal of this post is to ask you, the reader (and hopefully podcast listener to tell me what you want from a new podcast on Microsoft.

One thing I have learnt from over 20 years as a software developer is that, unless I am making something for just me, my opinion isn’t really that important… yours is.

What I will say is that I will do my best to deliver something that is worthy of the time you will spend listening to it. 

What I need from you is suggestions on what is missing in the Microsoft podcast world, and what you would like to see in it.  Please comment below,  I look forward to hearing from you.

Posted in Microsoft, Podcasts, The Microsoft Show, Uncategorized.

In Case You Missed It (ConfigureAwait)

In Case You Missed It is a periodic series of cool tidbits, reminders and things I have found useful in coding.

I recently picked up this valuable little tidbit from a developer I had the pleasure to work with. I can’t believe that I hadn’t known this before, but when I found out that several other developers I have worked with before weren’t aware of it either, I stopped feeling quite so foolish…

ConfigureAwait on the end of an awaited call can serve many purposes. First of all, it helps to avoid deadlocks by enabling a small amount of parallelism and ensure that it runs in parallel with the GUI main thread, the second is that it stops the continuous check-ins with the main thread, thereby ensuring optimal performance with no UI hiccups.

It does this by ensuring a consistent context for the running code. Awaited calls without ConfigureAwait check back into the main thread (GUI) at the completion of their run and subsequent calls to that context can result in deadlocks.

The syntax is simple:

await Task.Delay(500).ConfigureAwait(continueOnCapturedContext: false);

or just:

await Task.Delay(500).ConfigureAwait(false);

One other important thing to note is that once you invoke ConfigureAwait in a method, it is best to do it for every awaited call after that point in the method. This ensures a more consistent flow in the way the code runs and allows the code to continue to execute in parallel without checking back in to the GUI or main thread.

You should, however, avoid ConfigureAwait if you have to use the context of the method after the await. This is especially true for apps with a user interface. Any code that is used to affect GUI elements or is involved in updating bound properties or needs access to GUI-specific types such as Dispatcher/CoreDispatcher should not use ConfigureAwait.

ConfigureAwait is a powerful little tool in the Async arsenal, used wisely it will make your users’ experiences much better!

Hope this helps.

Posted in In Case You Missed It, Periodic Post Series.

Tips & Tricks & Bits (Xamarin)

Tips & Tricks & Bits is a periodic series that will showcase things that I have found useful to know in my coding endeavors.

Here’s a quick list of a couple of things I have found useful to know when writing apps for Xamarin (check back, this list will grow):

  • Android projects hate hyphens.

    Don’t use a hyphen in an images or resource names. Using “my-icon.png” in your drawable folder will give you all sorts of strange errors, which, unfortunately, will not, in any way include “Don’t use hyphens” in the messaging at all. Use “my_icon.png: instead and all will be well.

  • Make Sure Platform Heads Get Their Packages Too.

    Even if you are only using a particular feature in your PCL(s) (e.g. settings, file system, location sensor, etc.) make sure that the platform head projects get the appropriate packages. What you have to keep in mind is that Xamarin compiles to native code and the heads need to have the appropriate platform specific libraries available so that you cool PCL code will run. Often the NuGet Package Manager will take care of that for you, but, you should always be aware for those times that it doesn’t.

  • DON’T create your UI in code unless you absolutely have to

    It is cool to create code only custom control (I do it a lot), but really, unless you absolutely have to, it is not a great idea. There is a lot going on in the simplest of controls in Xamarin once you factor in the multi-platform support and therefore, it can get tricky to manage and maintain very quickly. With all the binding, converters and commands involved in controls, it is easy to end up with strange, platform-specific issues when you start to build complex user/custom controls in code. Avoid the headaches where possible and do code only controls in Xamarin only when absolutely necessary.

  • ListView Properites HasUnevenRows and SeparatorVisibility.

    Xamarin Forms ListView can seem to make it tricky to create the UI you want in lists. This is especially when trying to get the vertical layout to dynamically “grow” the way you need it to. You also may find that (mainly on iOS) you have ugly horizontal lines dividing items. To help with these issues, Xamarin has something that UWP/WPF doesn’t have: HasUnevenRows and SeparatorVisibility. Setting these properties to False and None, respectively, will help you easily to solve these annoying UI issues.

  • AbsoluteLayout is not your friend.

    I am sure that you need this thing to be exactly here… I am sure that you think that you need AbsoluteLayout, but from my experience with Android, it is not going to be your friend. It is hard to be sure that it will look correct in all the form factors and play nicely with all the other layout settings of all the other controls. Avoid it when you can and only use it when you must.

  • Posted in Periodic Post Series, Tips & Tricks & Bits.

    Tagged with .

    Contrary To Popular Opinion

    Surprisingly, there is still a lot of money to be made from Windows Phone users. I know that there are no new devices coming out and the latest ones were released almost two years ago (not counting WileyFox’s phones which were only available for a short time before the company entered into bankruptcy, TechCrunch , Digital Trends).

    I am speaking from personal experience, I am seeing a marked uptick in downloads and income from my apps over last year. It seems surprising until you think of it logically. There are still millions of Windows Phones out there and as developers leave the market or as apps get abandoned, the users are motivated to download and support the apps that are being maintained and properly marketed.

    One thing to make sure you’re doing is to update existing apps to UWP, it will help to ensure you are future-proofing your apps for whatever comes next. With full Windows coming to Arm, new devices and new categories will be made with form factors that will embrace and need the flexibility of UWP.

    Remember, as always, the development and deployment of an app is only about 30% of the actual work involved in making serious money from your app portfolio. Stay tuned for more tips and info on how you can make money on your apps.

    Posted in App Developer Success, Mobile Development, Windows Mobile, Windows Phone, WP App Lifecycle.

    Where UWP Makes Sense

    I get asked this question a lot and here is my point of view.

    UWP is still important for it’s webpage-like flexibility while having the trust and power of the desktop. It allows for relatively fast prototyping and grows more powerful with every release. There are lots of form factors from, Hub, Xbox, Desktop and, to some extent, still Windows Mobile.

    Microsoft screwed up their phone play… They admitted as much. That takes a lot of the wind out of the sails of the UWP development proposition, but all is far from lost.

    With the advent of WOA (Windows on ARM), there is a host of new devices coming our way, all with different form factors. These form factors will be non standard and varied as the industry searches for the next new thing. Making sure your software solutions get the most eyeballs and the most use is paramount in an app developer’s mind and drives much of what we do. To that end, UWP has a whole new shot at relevance and increased import. At least that is how I see it and why all my new apps targeting Windows in any flavor are UWP projects.

    Posted in Uncategorized.

    I’m back!

    After a long time away, I am back and active again in the community scene! Looking forward to talking to lots of devs and expect a lot of new stuff from my blog. As always, any questions or comments can be sent directly to me at

    Posted in General.

    Slakr – Call for Beta Testers

    If you use Slack ( for team communications and you are a Windows or Windows Phone user, you may have noticed a bit of a hole in the support for these platforms.

    I decided last weekend to create a Slack client for Windows Phone and Windows.   I am a good way through the app now and am looking for some beta testers. 

    THIS IS NOT THE OFFICIAL SLACK APP, but has the blessing of Slack and hopefully will make lots of Slack users very happy.  As much as I love the name Slakr, i have to change to comply with the rules of using the API, so I don’t confuse users. 

    If you want to beta test the app, please email me at and give me your email address so I can add you to the Slakr team of testers.  There will be channels to ask for features, report bugs or issues and to discuss the project directly with me.

    Some of the basics:

    • Slakr will support multiple teams out of the box.
    • To be on the beta test team, the first team you have connected to Slakr must be the Slakr team.  You can connect to as many other teams as you like.
    • As an added bonus, the beta testers that give the most constructive and useful help and reporting will be rewarded with a gift to be revealed at the end of the beta.
    • You will be asked to be polite to the other members of the team and do not solicit or spam them.
    • If you advise or request a feature that becomes a paid feature, you will get a special code to get all paid features for free.  This code will be good only for two devices at a time and will be attached to the email address you used to join the beta.

    The team is set up now and I will be taking requests for features even before the app is available to the store!  

    Hope to see you on the team!

    Posted in Beta Testing, Mobile Development, Windows Phone, Windows RT.

    Build 2015 Announcements – My Humble Opinion


    There has been much turmoil and conversation about the new features and tools created to allow for easier porting of existing iOS or Android code to the Windows Platform.  The announcements mean that they will be able to bring more basic apps over (banking ones, general use, some games) with a much smaller assisted dev budget than before…

    I don’t see the rapid influx of Android or iOS developers rushing to take over the Win market, there is far too much small-minded Microhate out there for that to happen.

    Simply re-compiling a iOS or android project will not give the rich / adaptive UI necessary to create a great, cross device experience or to take advantage of all that Windows has to offer, there still is architecture, device and user consideration to factor in.  Many devs will not do this, to their own detriment.  The projects where Microsoft partners with top development shops to create Windows Platform versions of their popular products will do this.

    I don’t see native development going anywhere right now, or in the near future. Native development still looks strong, there are still vast resources and effort being put into the native toolset And the evolution of those tools

    Many native developers thought the world was ending with Cordova, HTML 5 app development, App Studio and did anything change, not really..

    It will take time for the numbers of Win 10 devices to hit a critical mass that will turn the vultures and, more importantly, the industry fanbois from their current troughs. At that time, we, as native developers will have to compete with the same numbers as if the platform had been popular all along, which has been what we wanted anyway right???  Why are we all whining and bitching?

    My tactic will be to be entrenched in the landscape so that they are competing against me, not me against them.

    Realistically, a vast majority of app developers do not make money, on any platform and these announcements are not for them… It is for the banks, services, and other companies that are not looking to make money, but reach all their customers… This will, hopefully close that gap… Until there is a device count that approaches, matches or exceeds the other platforms, most developers will ignore this change.

    Worst case scenario, the porting tools fall flatter than the WinJS options have.  In which case, there are still native cases to be made for all the millions of users that do and still will use Windows.

    As the platform gains traction and market share promised (if it does) there will be value in knowing how to rapidly, expertly and effectively create experiences that do that.  In the event that Microsoft does exactly what it dreams and regains the dominant position, the native developers that have worked hard to hone their craft, will be golden.  Until then, even targeting the smallest market on the landscape, i am doing just fine and it will just get better.  

    Every challenge is only what you make it.

    Posted in Uncategorized.

    Questions??? Answers: When will you shift your focus to developing strictly for Windows 10?

    Questions??? Answers is a little section where I pull the answers I have given to developers about actual questions they have asked.   I am always open to questions, ping me on Twitter, or ask below.

    I will continue to build for Windows 8.1 until the tools are fully ratified and the kinks are worked out, usually takes few months or so past release.  Once I see that the numbers of phones updated to 10 are higher, I wills switch my development efforts over to strictly focus on Windows 10.

    That being said, any app that I decide to develop that needs the features provided by Windows 10 SDK and is not available on Windows Phone 8.1 SDK, I will, of course develop it right away on Win10.  This will also go for any apps that I am making that will have a tablet or Windows desktop focus.

    As for converting apps to Windows 10, with the backwards compatibility going all the way back to 7.8, I will be converting all apps that make sense based on features and/or user numbers.

    During the time between Windows 10 Phone release and general common availability, I will be definitely be working to experiment and extend my libraries to focus on the new available features to make sure I am staying current and fluent in the new SDK.

    Posted in Developer Questions, Mobile Development.

    Being a Successful App Developer – Part 1 – Defining Success

    I get asked this a lot, so I thought I would try and put together a section on being a successful app developer.

    The very first step to being successful in anything is to first decide what success is.  That may seem strange and perhaps even silly, but when you stop and think about it, many of us start off on projects / ventures and even careers without first defining what we see as the main goal of our quest.

    Not taking the time to first define the success of the project or endeavor often leads to an unsatisfactory result or experience and usually leads to a great deal of wasted time as we shoot for an impossible, moving, blurry target.

    Success is as diverse and varied as the individual or group seeking it.  What may define success for me, may not be what defines success for you, or perhaps anyone else.  The same can be said for the definition of success from one project to the other.

    For instance, I wrote an app once, solely for the purpose of playing a prank on someone I knew.  The app went into the store so that the person could access it (they could not side load it), so realistically, the purpose for that app release was aimed at a single person / purpose.  That is the only instance of that in my app portfolio, therefore the definition of success was the yelp when the app i wrote scared the crap out of her .

    Before you start your app, take a few minutes to define the app’s success, you will find that your ability to architect, scope and complete your projects will greatly improve.  It’s funny, defining the goal can lead to a better result even if you never actually reach it.  At least you know where and how you fell short and lead to better understanding how to target and resolve any issues leading to the outcome.

    Remember that Thomas Edison once said “I have not failed, I have just found 10,000 ways that do not work”.  If there was no definition of success, he would not have known even that.

    Success is not necessarily money, or downloads even, it is varied and can even change as the project progresses and the app evolves.

    Posted in App Developer Success.