Help – A Covid-19 Tracker app has been secretly installed on my Phone!

On LinkedIn the other day I noticed a post claiming that Covid-19 tracker apps had been installed on everybody’s smart phone and that we were all being tracked.

Ok, so lets ignore the fact that we can be tracked via our phones anyway and look at what the fuss is about.

If I open up the settings on my OnePlus 6T Android phone I see a new item – ‘COVID-19 exposure notifications’. This is what some people are losing their minds about right now.

I on the other hand am not. Why not?

Well, as a developer (web and mobile) I listen to numerous podcasts with presenters and guests who know what they are talking about and one such episode focused on the collaboration between Google and Apple to create the foundations for Covid-19 tracking app and roll it out to their phones during a standard update cycle.

In this episode, which non-techies will find boring as hell, security expert Steve Gibson analyses the technology and gives it the thumbs up from a security and privacy point of view. This is a man I trust when it comes to these things.

But here’s the thing that you may have missed – this is the foundation for app development, it is NOT a tracking app itself.

If people bothered to tap on the above settings option to open and read the details, instead of taking screenshots, posting them on LinkedIn (and probably Facebook and Twitter) claiming that something underhanded is going on, then they would have seen that this functionality is only activated when a compatible application is installed.

There’s other information there too which may have reassured them (or not) and a link for them to find out even more about this functionality.

In case you are concerned that someone could create an app and secretly access this functionality for nefarious reasons, not just any Tom, Dick or Harry can knock up Covid-19 Tracking App using this API.

Only third party companies affiliated with a public health authority or government can use it and that will be tightly controlled by Apple and Google.

So what do I do now?

Frankly, nothing. There is nothing you can do to remove this nor is there any need for you to do so. If you don’t install a tracking app, this functionality won’t be activated on your phone. Simple as that.

If you don’t trust Google or Apple (or your Government) then you probably want to think about changing your phone to something a bit less “smart”.

As an aside….

Above I linked out to the Security Now podcast with Steve Gibson where he gave the thumbs up to the technology.

A later podcast is entitled “Contact Tracing Apps RIP” where he explains that while the technology is sound, the system will probably not work in the real world.

Why is this?

Well, research suggests that for the system to work effectively it would need at least 80% of the population to install it on their devices – and if the above hysteria is anything to go by, that’s just not going to happen.

I’ll leave it there….

Using Fonts for Icons in Xamarin.Android

I’m currently working on a new privacy application for Android and in a previous post I guided you from the Xamarin.Android Drawer Navigation project template to something that actually worked (as in you could actually use the pretty navigation provided by the template).

Now I wanted to change the menu items to something more relevant with some appropriate icons – I mean, how hard can that be right?

Well, as with everything in development these days – things are not always as easy as they seem to be.

Continue reading “Using Fonts for Icons in Xamarin.Android”

Getting Started with Visual Studio 2019 Android Navigation Drawer template

So, I’ve had an idea for another privacy-focused application, this time aimed at mobile devices – Android in particular (I know that Apple are a little touchy about encryption apps – maybe I’ll venture into iOS at a later date).

Notwithstanding my desire to keep my skills up to date I knew that the project I have in mind would require a lot of platform specific logic. While Xamarin Forms can handle this I prefer to take the hit, roll my sleeves up and I opted for a native Android project instead – and that’s where the trouble/fun started.

If you go through the ‘New Project’ process below you will end up with an application which will look something like the one above;

Yep -just what I needed, an application with a slide out menu. Now all I need to do is to replace the default options with my own and then open the appropriate views when they are clicked – what could be easier?

Continue reading “Getting Started with Visual Studio 2019 Android Navigation Drawer template”

Unit Testing with the Xamarin.Forms MessagingCenter

While we all know that Test Driven Development (TDD) is a good idea, in practice it’s not always viable. It could be a time constraint, a resource issue or the project just doesn’t warrant it.

While TDD may sometimes be an option, unit tests themselves should really be considered to be a must. They will save you a lot of time in the long run and while they may not prevent you from going grey, ask me how I know, they will reduce your stress levels when bugs raise their ugly heads.

So, whether you write your tests before you write the code or vice-versa, if you are developing production code you really should write tests to cover it.

Now, one of the requirements for unit testing is the ability to mock out a components dependencies so that you are only testing the component itself.

Normally you would use the Dependancy Injection pattern to help develop loosely coupled systems but Xamarin.Forms has a few components which can be a fly in the ointment – one of these is the MessagingCenter.

Continue reading “Unit Testing with the Xamarin.Forms MessagingCenter”

AppSettings in Xamarin.Forms

If you have used ASP.NET in recent years you will probably be familiar with the appSettings.jsonfile and it’s associated, build-specific transformations, e.g. appSettings.development.json and appSettings.release.json.

Essentially these allow developers to define multiple configuration settings which will be swapped out based on the build configuration in play. Common settings are stored in the main appSettings.json file while, for instance, API Endpoint Urls for development and production deployments are stored in the development and release files.

At compile-time any values specified in the deployment version of the file overwrite those in the common version.

Simple – works well and we use it all the time without thinking about it. But what about Xamarin.Forms – it doesn’t have such a mechanism out of the box so how do we achieve this and prevent accidentally publishing an app to the App/Play Stores which are pointing to your development/staging servers?

Continue reading “AppSettings in Xamarin.Forms”

Updating an end of life application

A while ago I posted that the FillLPG for Android application was, in a word, Dead! But in few days time users will notice a new version, 2.0.28.5, hitting the Play Store as well as in-app notifications to update – so what gives?

Have I changed my mind about withdrawing support for this app – no, I haven’t. Essentially my hand has been forced by Google’s recent decision to deprecate some of the functionality I was using to fetch nearby places as part of the ‘Add New Station’ wizard as well as requiring 64 bit support – the latter being little more than a checkbox and nothing that most users will ever notice.

Removal of the Places Picker

Prior to the update, when adding a new station a user could specify the location in one of two ways;

  • Select from a list of locations provided by the Google Places API and flagged as ‘Gas Stations’
  • Open a ‘Place Picker’ in the form of a map and drop a pin on the desired location

It is the second option which is now going away – and there is nothing I can do about it. Google are pulling it and that’s that.

Continue reading “Updating an end of life application”

Your app does not support Andorid Pie!

I receive a lot of SPAM regarding the FillLPG mobile app, mainly offering to increase my install numbers and ratings, but today new approach appeared in my Inbox.

Hi there,

I was reviewing your app FillLPG – LPG Station Finder, and it looks great. But it appears the app does not support new Android Pie.  Without it, more than half of the users cannot use the app properly. I am an app developer and I can update your app in a couple of days if you want.

Thanks

Jon

It may not be obvious but this is just SPAM, sent by a bot and I doubt that anyone called ‘Jon’  is actually involved in the process, let alone reviewing my app.

Continue reading “Your app does not support Andorid Pie!”

Another Xamarin Forms app about to hit the App/Play Stores

Smite is a wooden garden game based on a Northern European game and played around the world.

If you think of a combination of skittles and boules you’ll be pretty much there – but not quite, there are a few twists.

Each player will take turns to throw a wooden ‘smitter’ at 10 numbered wooden pins, arranged in a similar manner to those in 10 pin bowling.

  • Knock over a single pin and you score the number on that pin.
  • Knock over two or more pins and you score the number of pins that fall; knock over four pins and you score four points.
  • Before the next players turn the pins are stood back up but remain where they fell, they are not returned to their original location.
  • Miss all the pins three turns in a row and you are ‘smitten’ and out of the game.
  • If any players score exceeds 50 points they are returned to 25..!
  • When a player scores exactly 50 points the game will end when the round completes – all remaining players will complete the round. There can be more than one winner!

It sounds simple but when the pins start to spread out the game becomes much harder – I can personally attest to this, as can many members of my family..!

Keeping score is not difficult but games can go on longer than expected and you soon find yourself scrabbling around for scraps of paper to continue the scoring.

Continue reading “Another Xamarin Forms app about to hit the App/Play Stores”

Xamarin Gotcha – Care needed when taking a photo with the Xam.Plugin.Media plugin

I’m currently writing a Xamarin.Forms scoreboard application which, as part of the functionality, allowed each player to take a photo which would be displayed within their ‘player tile’. I made use of the Xam.Plugin.Media plugin developed by James Montemagno to implement this feature and everything was working like a charm. I then parked the project for a couple of months while I attended to some paying development and training.

When I returned to the project I looked at the outstanding items on my backlog and decided to implement the saving of game state when the app is backgrounded. This was pretty straightforward and I had it nailed in a few hours by adding code to the OnStart, OnSleep and OnResume handlers in the shared class library (in this case, a PCL). After testing the functionality I then ran through a manual ‘smoke test’ to make sure everything was working as expected – and that’s when the trouble started 🙁

I was initially working on the Android version and I quickly discovered that the photo taking functionality appeared to be broken. When I took a photo and then accepted it using the Android camera app I was taken back to a blank player list!

This didn’t used to happen – this was working code and I was certain I hadn’t change anything to do with the player photo code.

Nuget?

I then decided to create a quick and dirty app to pull in just the packages I needed to take a photo and display it within a view – and that worked just fine using the same versions that I had in my project, so the “problem” was in my code.

Returning to my code, the first thing I tried was to update all the Nuget packages. Some time had passed since I’d last opened the project and there were a number of updates pending. I was testing on my Pixel 2 XL running Android P (I’m in the beta program) and maybe, just maybe there was a mismatch here. As it was, this made no difference but it was a good job done – I’d have needed to do this anyway so no time like the present.

PCL v .NET Standard?

One major difference was that my app was using a Portable Class Library (PCL) while the sample app used .NET Standard (as you can’t create a PCL version now). Maybe that was my problem – maybe I needed to upgrade to please the plugin and/or Xamarin.Forms 3.0. Deciding it was another useful exercise anyway I decided to do just that – I created a new shared class library using .NET Standard and pulled my code over (a very simple process considering).

No joy – the problem persisted!

Then, in a moment of clarity, I wondered whether this was a problem was present in the iOS version of the app and to my surprise I found that it wasn’t. Running the smoke test on an iPhone 6s demonstrated the expected behaviour.

Going back to Android and diving into logcat I didn’t find anything obvious in terms of errors but then I saw a debug output message that I had added to the OnResume handler while developing the Save Game functionality. Why was that being called?

Eureka!

Then the penny dropped and it’s a fundamental part of the way that Android works.

When I called into the plugin to take the photo it opened up the Android Camera app – temporarily backgrounding my app in the process. When the user takes and accepts the photo, the Camera app will return control to my app, passing it the image data, and thus bring it into the foreground.

Of course, when the app is backgrounded the OnSleep handler is called and when it is brought into the foreground OnResume is called. In my case the OnSleep handler wasn’t a problem, but the OnResume hander was a different matter.

When resuming the app will now attempt to locate any saved state and if found it will deserialise the data and initialise the state to continue the saved game. But, if no saved state was found it will assume that the app is being opened with no saved state so it would just create a new game – and this is what it was doing, creating a new game with an empty player list!

A quick update to handle this unexpected backgrounding/foregrounding behaviour and I was back to a fully working app on iOS and Android.

The fact that the camera app was temporarily backgrounding my app didn’t dawn on me at the time but when I thought about it it was obvious.

A frustrating few hours to be sure but at the end of the day the app is now working the way it was intended to work and it’s now running with .NET Standard with all Nuget packages updated.

First Xamarin.Forms app goes live in both App Stores

A while ago I eluded to the fact that I was revisiting Xamarin.Forms for cross platform mobile development – previous projects had used the ‘native’ Xamarin.Android and Xamarin.IOS toolkit.

I was interested to see how far Xamarin.Forms had come since my last encounter where I found it lacking in some critical functionality that was required for the project at hand – primarily when dealing with Maps.

When I was approached by a user of my FillLPG application to write something along a very similar line, i.e. a number of points of interest displayed on a map with clickable markers to display more details, for both Android and iOS I wondered whether Xamarin.Forms had matured enough to do the job.

The application is a companion to the Motorhome Stopover website which provides it’s members with access to over 600 locations around the UK where they can park overnight for free. While these are not campsites, facilities vary from location to location, they do provide a useful service when drivers are travelling across the country to their ultimate location (not everyone wants to drive from Edinburgh to Penzance in one day and being able to break the journey is a godsend).

The app requirements were very simple, for the minimum viable product (MVP) anyway.

Authenticated Motorhome Stopover members should be able to view all currently active locations on a map, view contact details of any location and the facilities it provides and, using the device’s built-in navigation capability, navigate a route from the users current location.

Essentially, with the addition of an FAQ and About page, the app boiled down to a map showing stopover locations and a page listing contact and facility details for a location when the user tapped on its marker. If Xamarin.Forms couldn’t deal with this then I was going to be surprised.

The client was an Android user so much of the initial development was undertaken with that in mind and I focused on getting that version to a level where it was functional and he was happy – then I would take a run at the iOS version.

Initial development was undertaken prior to the release of Xamarin.Forms 3.0 but later upgraded without any problems – nothing appeared to be broken and everything just worked.

Looking back at my previous forays into Xamarin.Forms I think that the biggest hurdle was Custom Renderers. The problem being that documentation was very sparse and with the base toolkit not providing the level of customisation I wanted I didn’t have the confidence to plough on and develop Map Renderers only to have to revert to native development.

This time around the documentation was there in abundance, along with GitHub samples and a Xamarin University course. How times have changed 😉

That said, it wasn’t plain sailing and there were still a few speedbumps along the way – although many of these can be attributed to climbing the learning curve of Xamarin.Forms rather than problems with the toolkit itself.

The best thing was, when I turned my attention to the iOS version of the app there was very little to do once the Custom Renderer for the map was completed and wired up. Everything else pretty much worked as expected with the only additional development being that of addressing minor styling and layout differences as can be seen in the screenshots below.

Not withstanding the need for additional features such as searching and filtering there is still some work to do. This mainly centres around testing and everything that facilitates it, e.g. dependency injection in Xamarin.Forms and how to do this within a Unit Test.

The ease with which I was able to develop these applications and the level of code reuse has certainly confirmed to me that Xamarin.Forms is more than just a tool to create very simple applications, quick mock-ups or proof of concept apps.

Overall I’m pretty happy with the initial release of the applications. Yes they are a bit feature-light at the moment and need a bit of polish here and there, but I’ve learned the hard way that at some point you just you need to ship something otherwise it will never see the light of day!

By defining a clear Minimum Viable Product I was able to focus on the core functionality and not get bogged down in the minutiae.

 

Starting Development of FillLPG v3.x

Overview

With the most recent update to the FillLPG application (v2.0.28.2) rolling out I will be ceasing all development of this version (unless some horrible bug raises it’s ugly head). But fear not loyal LPG users – that doesn’t mean the the app will be going away – far from it.

Technology moves on at pace and over time new skills are acquired and lessons are learned. The ‘problem’ is that to implement all of this it is easier to start over again – taking advantage of the new framework features, applying the new skills and remembering those sometimes painful lessons.

So, what’s on the horizon?

I suppose the ‘headline’ news is that an iOS version will soon be a reality! After years of focusing solely on the Android version our Apple-using LPG’ers will be getting some love too.

The aim will be to develop an iOS application with feature parity to the current Android version.

Now, don’t fret if you are an Android user – I’m not abandoning all of you who have helped make the app what it is today. The fact that I can essentially develop for two platforms at the same time is due to the advances made in the underlying framework used to develop the app. Previous versions didn’t really lend themselves to the type of mapping that is required for the FillLPG app – but that’s all changed now and mapping is now fairly straightforward to achieve on both platforms whilst sharing the maximum amount of code – which is good for maintainability (fix a bug in one place and it’s fixed for Android and iOS).

With the rest of the application mainly consisting of ‘Forms and Lists’ and these can easily be shared between the new platforms.

The result will be a more modern UI, lower impact on battery life and data usage.

Other planned features include:

  • Offline price updates (updates will be pushed when your device next has internet access)
  • “Route Planning” – display stations along a particular route allowing you to plan stops
  • Enable/Disable update alerts for favorite stations

But there’s more…

The webmaster of the FillLPG website is currently developing a new version with a new and improved webservice – which is how the app communicates with the site. This will expose a lot more data to the app, including:

  • Station notes
  • Opening Times
  • Flags such as ‘Disabled Friendly’ and ‘SafeFill Capable’
  • Ability to specify price currency
  • and more

Obviously I have no control over the timescales for the new website functionality but as soon as it is available I will be including it into the application as quickly as I can.

Please remember though that the FillLPG website and the mobile apps are ‘labours of love’ and that both myself and the site webmaster have other commitments. The website and apps are provided free of charge and with no ads.

 

Xamarin Certified Once More

I first passed my Xamarin Mobile Certification back in June 2014 but when it came to taking the recertification exam the following year I never quite got around to it. Ultimately it lapsed and I while I was no longer certified I did keep my University subscription running so that I could keep my skills up to date.

During the next year I have to say that I was quite disappointed as there didn’t really seem to be any new content, i.e. no new courses were added as far as I could tell. At the end of that year I was considering not renewing my University subscription, at $1500 it was not exactly a no-brainer.

Then Xamarin was bought by Microsoft and it was included in the MSDN subscription, effectively saving me $2000. With the promise of new content I decided to renew my University subscription – I was $500 up anyway so why not I thought.

Well, as promised, new content is being added, a handful of Azure courses and one on Xamarin.Forms custom renderers so far. That and the fact that I’m currently engaged as a Xamarin developer I thought it would be prudent to refresh my certification. That, coupled with the fact that the Certification and Recertification exams are to change on 15th October this year meant I had a definite timeframe.

Xamarin list 10 courses as being required knowledge for the recertification exam so I spent a couple of weeks reviewing these – making notes and doing the exercises – before embarking on the exam.

The exam itself is 100 multiple choice questions which must be completed within three hours. The pass mark is 80% so not a lot of wiggle room here.

During the exam itself there were a few, shall we say, curve balls – questions which, to me, seemed quite ambiguous. One mentioned an image which was not present resulting in me having to guess the correct answer based on the text – which proved unsuccessful as it turned out – it was in the list of incorrect answers. If I’d missed the 80% by a single mark I don’t think I would have been too happy. As it was I passed with a score of 87% which I’m pretty happy with.

Creating a Simple Modal Dialog Form for Xamarin.Forms

I’ve finally managed to get some time to look at the Smite Scoreboard application that I’m using as a vehicle to dive into Xamarin.Forms (XF) and it’s been a fraught time (see bottom of post).

Between incompatible nuget packages, mismatched Windows and iOS configurations and finding that XF didn’t actually support what I wanted to do I was pretty close to saying, “you know what, to hell with it – I’ll just use the native Xamarin approach instead”.

However, I recalled a video by John Sonmez titled ‘Why does Programming Suck?’ and rolled my sleeves up and dug in again.

Anyway – getting back to the Smite Scoreboard app and what is basically the first User Story.

As a user I want to be able to create a list of players, adding, editing and removing as appropriate.

Now, I know what I wanted to do to implement this story – a simple ListView with an ‘Add Player’ button which would open a modal dialog . The dialog would contain a ‘Player Name’ field with OK and Cancel buttons. Entering a name and tapping OK would add a new row to the ListView. Simple huh.

Well no, not really. While XF does support modal pages, which take up the whole screen, it does not support modal dialogs.

I tried a couple of approaches including the creation of a layout with an Entry field above the ListView which would replace the field I was going to put in the dialog. I had this partly implemented but really didn’t like how it was working and decided to bite the bullet and find a way or make a way!

And this is what I came up with (iPhone on the left, Android on the Right):

Yes – it’s not pretty but it shows me that I can do what I want to be able to do. Making it look nice is a job for later, lets get it working first ?

So, on to the code. I decided to address the initial problem – how do I create a modal dialog (or the impression of a modal dialog) which will allow data entry? I didn’t worry about the ListView integration as I’m happy enough that I can make this work.

I found the key in Charles Petzolds book (which is free) and simply extended his solution to my needs.

Basically he uses an AbsoluteLayout which will hold the ‘normal’ page elements as well as a ContentView which will form an overlay that the user can see through but crucially not tap through. The ContentView is initially loaded with it’s IsVisible property set to false.

The skeleton xaml file looks like this:

<AbsoluteLayout>
  <!-- Normal Page Content -->
  <StackLayout AbsoluteLayout.LayoutBounds="0, 0, 1, 1"
               AbsoluteLayout.LayoutFlags="All">
      <!-- Normal Page Content -->
  </StackLayout>
  <ContentView x:Name="overlay"
               AbsoluteLayout.LayoutBounds="0, 0, 1, 1"
               AbsoluteLayout.LayoutFlags="All"
               IsVisible="False"
               BackgroundColor="#C0808080"
               Padding="10, 0">
      <!-- Overlay -->
  </ContentView>
</AbsoluteLayout>

With this in place I added a button to the StackLayout and bound the Click event to a handler in the code behind which flipped the IsVisible property of the ContentView to True, thus displaying the overlay.

All I had to do now was to create a layout within the ContentView which looked something like a dialog. I came up with this:

<StackLayout Orientation="Vertical"
             BackgroundColor="White"
             HeightRequest="175"
             WidthRequest="300"
             HorizontalOptions="Center"
             VerticalOptions="Start"
             Margin="0,20,0,0" >
 
  <Label BackgroundColor="Black"
         FontSize="18"
         TextColor="White"
         HorizontalOptions="Fill"
         Text="Add a Player" />
 
  <Entry x:Name="EnteredName"
         Placeholder="Player Name"
         TextColor="Black"
         VerticalOptions="CenterAndExpand"
         HorizontalOptions="Center"
         WidthRequest="250" />
 
  <StackLayout Orientation="Horizontal"
               HorizontalOptions="Center">
 
    <Button Text="Cancel" FontSize="Large"
                VerticalOptions="CenterAndExpand"
                HorizontalOptions="Center"
                Clicked="OnCancelButtonClicked"/>
 
    <Button Text="OK" FontSize="Large"
                  VerticalOptions="CenterAndExpand"
                  HorizontalOptions="Center"
                  Clicked="OnOKButtonClicked" />
  </StackLayout>
 
</StackLayout>

Wiring the buttons up to flip the IsVisible property of the overlay back to false and, in the case of the OK button, access the entered value was straightforward enough.

using System;
using Xamarin.Forms;
 
namespace SimpleOverlayForm
{
    public partial class Home : ContentPage
    {        
        public Home()
        {
            InitializeComponent();
        }
         
        void OnButtonClicked(object sender, EventArgs args)
        {
            EnteredName.Text = string.Empty;
            overlay.IsVisible = true;
            EnteredName.Focus();
        }
 
        void OnOKButtonClicked(object sender, EventArgs args)
        {
            overlay.IsVisible = false;
            DisplayAlert("Result", 
                          string.Format("You entered {0}", EnteredName.Text), "OK");
        }
 
        void OnCancelButtonClicked(object sender, EventArgs args)
        {
            overlay.IsVisible = false;
        }
    }
}

The result may not be pretty right now but I think it will suffice for the time being until I can get to grips with theming etc.

The full source code can be downloaded from GitHub

It should be noted that I had issues when I attempted to update to the latest version of Xamarin.Forms via Nuget. The version installed with the ‘File > New Project’ did not seem to like the Overlay configuration and while the semi-transparent background was visible the ‘dialog’ controls were not. Only by updating from 2.0.0.6482 (installed by default) to 2.3.1.114 (latest at time of writing) was I able to get this working. But it was not that simple (of course). Version 2.3.1.114 has dependencies on specific version of the Xamarin.Android.Support packages, 23.3.0, but I’d already updated those packages to their latest versions (23.4.0.1). This meant that I had to revert those updates and install 23.3.0 instead.

Unable to deploy Xamarin Android app to GenyMotion emulator

We all know that when you are developing mobile apps there is nothing better than running on an actual device. This is especially useful when wanting to access the device sensors such as GPS and the accelerometer. But we also all know that we have to test against a wider variety of devices than we have in our drawer. That’s where emulators come in – and where the trouble starts in some cases, but I won’t go into Hyper-V here!

Well I’ve been using GenyMotion for a little while and am very happy with it – to the point that I was about to put my hand in my pocket to buy a licence (which I may well still do). However, today I ran into a problem where Visual Studio would refuse to deploy to the emulator.

With the emulator running I selected it as the deployment target in Visual Studio and pressed F5, the build completed successfully and then, just before deployment the emulator disappeared from the list of targets and the deployment failed. I made sure I had the latest version of Genymotion installed (which I did) and that everything else was up to date (which it was).

While I was badgering Xamarin in the forums and via the support email I thought to fire up the Android Debug Bridge (adb) command prompt from within Visual Studio to check what devices the Debug Bridge was actually connected to:

Well, there you have it – it’s a problem with the adb versions ….. wait a minute, how many do I have?

My understanding was that I should only have one – the one that Visual Studio connects to so that it can access the Android devices & emulators. And (I think) I was right on that score – I should only have on running. So what’s with the version clash?

As it happens, Genymotion also ships with a version of the Android Debug Bridge and as it turns out, right now that one and the one shipped with the Xamarin toolset are not the same version.

Comparing versions of adb.exe (from Genymotion and the Android SDK) I found that Genymotion was currently at version 1.0.32 while the Android SDK has 1.0.36.

So what to do?

I suppose I could copy the adb files from the Android SDK into the Genymotion installation – but that frankly smells a bit to me and as it turns out it’s unnecessary.

It is possible, within Genymotion, to set which ADB instance to use for each individual emulator. Simply select the emulator instance and click Settings. Select the ADB tab, click ‘Use Custom Android SDK Tools’ and browse to the SDK location on your system.

Note that the SDK will be in a folder called ‘Android’ within C:Program Files (x86) or C:Users<user>AppDataLocal

Setting this resolved my issues and I am once again enjoying the flexibility of Genymotion and will be buying a licence very shortly.

Visual Studio 2015 – Package Installation Error [Failed to initialize the PowerShell host]

Well today I decided to start a new Xamarin.Forms project in Visual Studio 2015 but fell at the first hurdle – you would have thought File > New Project would be simpler than this really.

After clicking through all the errors I tried to build the solution which failed as badly as I expected it to – only 28 errors but all pretty severe.

Opening the Package Manager Console resulted in another error which seemed to indicate that a file was missing (nuget.psm1) but it was present, accessible and appeared to be intact.

So what’s the problem here? Well, it’s not actually Xamarin.Forms at fault – if I open Visual Studio with no solution loaded and then open the Package Manager Console I get the same error. I checked for updates and compared all the version numbers against the installation on my laptop (which didn’t have the same issue) and everything seemed in order.

Well after a look (and I mean, a lot!) of Googling I found a cure for the symptom but not for the root cause.

When you open Visual Studio 2015 an instance of the devenv.exe.config file is generated in the following location: C:Users<username>AppDataLocalMicrosoftVisualStudio14.0 with a nice comment header indicating that modifications were subject to being overwritten. Now that’s a bit of a pain because only by editing that file can I get the workstation to open the Package Manager Console correctly and hence generate a Xamarin.Forms project.

Add the following within the assembly binding section of the config file:

<dependentAssembly>
    <assemblyIdentity name="System.Management.Automation" publicKeyToken="31bf3856ad364e35" />
    <publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
  <assemblyIdentity name="Microsoft.PowerShell.Commands.Utility" publicKeyToken="31bf3856ad364e35" />
  <publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
  <assemblyIdentity name="Microsoft.PowerShell.ConsoleHost" publicKeyToken="31bf3856ad364e35" />
  <publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
  <assemblyIdentity name="Microsoft.PowerShell.Commands.Management" publicKeyToken="31bf3856ad364e35" />
  <publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
  <assemblyIdentity name="Microsoft.PowerShell.Security" publicKeyToken="31bf3856ad364e35" />
  <publisherPolicy apply="no" />
</dependentAssembly>
<dependentAssembly>
  <assemblyIdentity name="Microsoft.PowerShell.Commands.Diagnostics" publicKeyToken="31bf3856ad364e35" />
  <publisherPolicy apply="no" />
</dependentAssembly>

Now, the laptop does not have those lines in it’s version of the file and it runs just fine so why the workstation is choking I have no idea – this is a quick and (very) dirty fix at best. From time to time you may need to reedit the file but at least you will be able to continue working.

The thing is I plan to pave this workstation soon and perform a clean installation so I’m not really looking to spend a great deal more time trawling the internet to find which obscure setting is flipped the wrong way and is causing this issue.