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.

Insights is dead, long live Insights

In my previous post I sang the praises of Xamarin Insights and explained how it enabled me to locate a bug with the FillLPG for Android application.

At that time Insights as in Preview Release and all Xamarin subscribers has free access to the service, many like myself building it into production applications. We all knew that the time would come when Xamarin would decide that the product was mature enough and take it out of preview and start charging for it. At the recent Evolve conference (which I was not fortunate enough to attend) it was confirmed that existing users would still have access to the service but that plans were still being worked out.

Well, the plans have been worked out and the pricing released – and the news is not great for users like myself. It was hoped that existing users would retain free access, albeit limited, to all aspects of the service – but this is not the case.

The free tier is ‘limited’ to the real-time issue/crash reporting area (as used in my previous post) with all other areas, what I will refer to as Analytics, only available to paid subscribers.

Now, here’s the crux of the issue – the entry level subscription is $199/month. When I received the email I actually had to read it a few times to make sure I was not mistaken – surely they meant $199/year didn’t they?

Well, no – they didn’t. Xamarin have put a price tag on this service is just shy of $2400/year. Now I, and others, see that as a bit of a slap in the face from Xamarin – after all, my usage during the Preview phase has surely been helping with their development of the service. That said, I do still have access to the Issue/Crash reporting part of the service and while there are some limitations being placed on that (log retention etc) this is the area I was making the most use of anyway – so frankly I’ve not really lost much, especially seeing as the Analytics have been offline for sometime now.

Now, FillLPG for Android was using some of the Analytics aspects of the service – I was able to tell how many users had actually logged in and how many had used certain functions such as updating or confirming a station price. That was interesting and has now been lost – in Insights anyway.

In the midst of this maelstrom a number of fellow Xamarin developers have mentioned the Mobile Analytics offerings from Google and Amazon and how they can be incorporated into Xamarin applications. These services are essentially free so I will be investigating them both shortly and intend to post the results in the coming weeks.

Xamarin Insights to the Rescue

So, calling webservices from mobile applications is a solved problem yes? Well, not quite. I’ve been developing desktop and web-based applications for many years now and when it comes to accessing the Internet there are normally only a couple of scenarios to consider, you either have access or you don’t – simple.

However, in the world of mobile it’s not that simple. Mobile devices are just that, mobile, and can move in and out of coverage and between data connections numerous times during an application lifecycle. As mobile developers we know that this happens and we guard against it but checking that we have a valid connection and maybe even that we can ‘ping’ the target resource somewhere out there in the cloud.

Well, I thought I’d done all that within the FillLPG application. I knew, absolutely knew, the format of the content that the webservice would return, which is currently XML, and had suitable methods in place to parse that data. So imagine my confusion when I start receiving error reports like this:

The above is from the Xamarin Insights dashboard which provides me with near real-time crash and issue reporting. There was dozens of records like this in the logs and it was really confusing because I know that the webservice should be returning the following XML:

<?xml version="1.0" encoding="UTF-8"?>
<colours>
  <green>53.9</green>
  <yellow>59</yellow>
</colours>

So, why on earth was the app complaining about a DTD reference?

Well, with a quick configuration tweak I was able to find out. I added the response to the exception data before sending the report to Insights so that I could see what the method was actually returning:

catch (Exception ex)
{
    ex.Data.Add("Thresholds XML", xmlResponse);
    Insights.Report(ex);
    throw;
}

And this was the result…..

This was not the XML is was expecting and explains why the parsing method were choking. But where was this HTML page coming from? I was sure it was nothing to do with the FillLPG website.

Reading through the markup it was clear that this was a login page for a Wifi Hotspot! The device had connected to it but it was not authenticated so the calls to the FillLPG webservice were just being redirected to the login page.

I was able to replicate this scenario by configuring my router to block all traffic to the FillLPG site and then hitting refresh (or any operation that invoked a webservice call). The router then redirected to the ‘This Site Is Blocked’ page and the app crashed!

The fix for this was fairly straightforward and I’ll put another post together for that, but I was already checking the Status Code of the Response and assumed, wrongly as it happens, the a value of 200 indicated a successful operation.

I was also using the ConnectivityPlugin and checking for an active connection AND that the site was reachable – but for some reason these tests were passing even though the router was actively blocking connection to the webservice.

So Xamarin Insights has saved the day for me again. There is no way I would have located this issue without it and while it is still ‘In Preview’ it is proving to be an invaluable tool for tracking down even the most elusive of bugs.

Xamain.iOS – Mapping & My Location

So, you’ve created your MKMapView in your view controller and instantiated a CLLocationManager which you’ve called RequestWhenInUseAuthorization() on. Everything tells you that this should be enough so that when the Map loads and requests the current location iOS will prompt the user whether they want to allow the device to share it’s location – but the prompt is never displayed and neither is the location.

I watched a Xamarin University course on iOS Mapping (IOS 230) and when I followed along with the exercise using a new project (not the one provided in the course materials) the location was still not displayed. But, when I ran the Completed project in the course materials I was prompted to allow location sharing and when I clicked ‘Allow’ the location was displayed. Looking at the code it did not seem to be any different from mine (but of course it had to be).

I finally found the missing element – it was a missing property in the Info.plist file. The Xamarin course materials had it but it was not mentioned during the course itself.

The good news is that it is super simple to fix this:

  • Open Xamarin Studio
  • Open Info.plist
  • Using the tabs at the bottom of the window – select ‘Source’
  • Click the ‘Add new entry’ text at the bottom of the table and add a new String property as follows:
    • Property: NSLocationWhenInUseUsageDescription
    • Value: Show map location
  • Save the file

That’s it – run the app again and (as if my magic) you will be prompted to allow access to your location and (if you click Allow) your location will be displayed.

You can download the (very basic) solution used above by clicking here.

Note that the solution was created using Xamarin Studio 5.9.5 (build 9) and Xamarin.iOS 8.10.3.2 (Business Edition)

iOS Limitations and Xamarin Mobile Certification

In my previous post I mentioned that I was looking at developing a cross platform, mobile application to schedule SMS messages.

Well I’m afraid that took a bit of a backseat for a couple of reasons.

Firstly I became aware that the action of sending a text message with no input from the user was not possible using iOS. While I have not investigated this fully it did make me pause for thought – what was the point of starting this cross-platform project if it was not going to work on the iPhone? Well, if the information I have is correct, there is no point …… unless I just demonstrate that writing apps for Android does not necessarily mean Java! So, this project is still on the cards – just not at the top of the deck.

The second reason for me not starting the development was that I have been studying via the Xamarin University and am happy to say that I am now Xamarin Mobile Certified :-).

The training took the form of a number of live web session presented by experienced Xamarin developers. Over the course of a couple of months I ‘attended’ many required sessions to allow me to sit the certification. This consisted of 150 questions which must be answered in under three hours. The pass mark was 80%. With my knowledge of iOS a little on the shaky side (being an Android user at heart) I was a bit hesitant about taking the full exam (I could have just taken the Android flavour) but I thought ‘what the hell’.

The exam did highlight to me that I need to do some more work on iOS but a pass is a pass and now that I have my evenings back I will be moving forward with the migration of the FillLPG application to Xamarin. Initially targeting Android but developed using all I have learnt to ensure that the maximum amount of code can be reused for an iOS version.

The code for FillLPG will unfortunately not be made available but I’m sure that there will be more than a blog post or three coming out of the development so stay tuned.

Getting Started with Xamarin – a Pet Project

In previous posts I have mentioned that 2014 will be my ‘Year of the Mobile‘ and that Xamarin (which will allow me to develop for Android, iOS and Windows Phone using C#) will be my weapon of choice.

As with all undertakings such as this I needed a few pet projects to work on, something that more closely resembles a real world application than some contrived examples that you find in some books and web tutorials (that’s not to say that all book and web tutorials are created equally).

I already have my FillLPG application, written in Java, which I am moving to C# via Xamarin but I wanted something that integrated with the standard phone functionality, e.g. phone calls, SMS. I also wanted it to be something that I could make use of myself – scratching my own itch if you will.

I’ve had a number of ideas but you need to walk before you can run so I’ve opted for an SMS Scheduler app. Yes, I know that this has already been done both as an integrated feature in full blown messaging applications and standalone utility apps (which is what mine will be) but that’s no reason not to use it as an learning exercise. The requirements are such that it will provide a number of opportunities for investigation into operations such as:

  • Contact Selection (taking into account some contacts may have multiple phone numbers)
  • Date/Time Pickers
  • Data storage (probably file based – SQLite is a bit heavy weight for this in my opinion)
  • Scheduling of the SMS ‘jobs’
  • Sending of the SMS itself
  • Logging and Notifications

As with previous ‘tutorials’ I’ll provide full source code at each step and the final project will also be on GitHub.

As I am predominantly an Android user I will be developing for that platform first but with a mind to sharing as much code as is practical.

2014 – The Year of the Mobile?

I’ve always said that when it comes to software development, you have to “pick your fights” – it’s just not possible to keep up with the ever-changing technologies. We only have so much time to spend learning new technologies and techniques so it is important to carefully consider what to focus on and what to let pass us by.

When it comes to Mobile development I have released a simple, native, Android app which was written using my somewhat rusty Java skills. At the time of writing the app is installed on around 5000 devices (if Google Play is to be believed). Since it’s original release I have addressed bugs and added a few requested features but I found it to be a bit of a struggle due to Java not being my main development language – but I simply don’t have time to bring my Java skills up to the required level. As for iPhone/iPad development I have joked that “I don’t have enough time left in my life to learn Objective C “.

So when I heard about a product which will allow developers to create native applications for Android & iOS (and Windows Phone) using C# (my language of choice) I was naturally intrigued.

The Xamarin ‘framework’ provides a set of bindings which sit above the Android and iOS APIs  allowing C# code to be compiled into native applications for the target platform. Moreover, it is possible to share large chunks of code between platforms thus reducing maintenance and duplication.

I’m currently in the process of completely rewriting the FillLPG application using Xamarin and C# with a view to reusing as much code as possible in order to ease the process of developing a version for iOS. It’s not been an easy process by any means – every new technology has it’s learning curve and fair share of bugs and issues, but because I’m using C# – indeed I’m also using Visual Studio 2013 – at least I’m not starting from zero.

The process of rewriting the FillLPG application has taught me a lot but as the old adage goes ‘you don’t know what you don’t know’ so I’ve also enrolled onto the Xamarin University course at the end of February and all things being equal I should be certified by the end of March.

So I declare 2014 to be my year of the mobile. I will still keep as current as I can with web development but the mobile market cannot be ignored and with a tool such as Xamarin I’m now in a position to take it on.

Looking forward – building Android apps using C#

So, mobile is where it’s at, or at least that’s what we are told and there is plenty of evidence to back it up. I know from how much I use my Android phone and how much I rely on it that it is a development platform that can’t be ignored.  As you may or may not know I currently have an app in the Android Play Store and while it’s pretty simple in what it does it has had over 5000 downloads and has a rating of about 4.5 stars. But nothing in development stands still and it already looks dated, uses the old Google Maps API and contains a reasonable amount of code that I’m not happy with. The problem is that I’m a .NET developer and while I have developed with Java in the past it too has moved on and I constantly find myself Googling for solutions to problems I know how to address in C#. So when I saw that there was a tool that would allow me to write native Android applications using C# I thought – “What’s not to like?”.
As with most new technologies though the learning curve is fairly steep, but I’m getting there. My initial aim is to rewrite the FillLPG application, from scratch using Xamarin and hopefully making it much easier to maintain. I want to use the latest version of the Google Maps API and make the application tablet friendly. Long term I want to get a few more applications into the Play Store (I’ve get a few ideas for applications that may be worth investing some time in) and in doing so add another string to my bow – as a contractor that has to be a good thing.

My initial impressions of the Xamarin stack were not great as the Starter Edition (a free licence which imposes some limitations) refused to let me build anything, even the simplest of applications. A quick email to support followed by a prompt response and a new version was installed and I was away … almost. The starter edition restricts, among other things, the size of the application you can build and the use of third-party libraries. That sounds like it shouldn’t be too limiting but consider that the new version of the Google Maps API is caught by the 3rd party library and my investigations into how feasible it will be to rewrite my application appear to have taken a major step backwards – although there is a light at the end of the tunnel (more on that a little further down). It would also appear that creating a solution with multiple projects, e.g. FillLPG.DataAccess and FillLPG.Core, is not possible, presumably due to the projects being classes as third-party libraries. Frustrating yes but not a show stopper – although It’s ironic that some of the official Xamarin samples won’t build using the Started Edition because of these very limitations.

In order to do any serious work with Xamarin it is clear that I’ll need to buy a ‘proper’ licence, which start at $299, and Xamarin do offer a 30 day money back guarantee. But there are two issues I have that will stop me from buying a licence right now.

  • I want to be able to use Visual Studio (so that I can make use of CodeRush during my development) and the licence that includes that support is $999
  • I need to make sure I have time to properly evaluate the tools to really see if they will do what I want to be able to do – because $999 isn’t what I’d call an impulse buy 😉

I’ve watched a few of the videos from the recent Evolve conference and it is clear that a lot of time, attention and money is being put behind Xamarin and I’m pretty confident that when I get a free couple of weeks to be able to devote to it, I’ll buy a licence and get coding – hopefully never looking back.

Solving Android SDK ‘No Such File or Directory’ error in Eclipse

I’ve hit this problem a few times now but this time I should probably write it down for my own sanity. Over the weekend I upgraded to Mint 13 (which is brilliant by the way) and because my laptop is running 6GB of RAM I opted for the 64-bit version of the distro to make full use of it. Having Eclipse and the Android SDK ‘installed’ on my separate /home partition I didn’t need to bother reinstalling everything (but my blog post on how to do it still holds) so assumed I was good to go – but I was wrong.
Opening up Eclipse it all seemed OK until I switched to the DDMS perspective where I was greeted with the following error:

No Such File or Directory – what the hell? I checked and double checked but could not understand why this error was coming up.

Then, in a flash of Google, a search result caught my eye that sparked a memory from the last time I paved my system and installed a new version of Linux;

I’m running a 64-bit OS but the Android SDK is 32-bit.

While this is not a major problem there are some 32-bit libraries that are required by the SDK that are not present on a 64-bit install.

Once I remembered what I was looking for I quickly found the required package and installed it with the following command:

sudo apt-get install ia32-libs

Restarting Ecplise and the troublesome error message was no more. I ran up a couple of my projects just to be sure and everything seems to be fine now – I just need to remember that next time, maybe the act of writing it down will help.