Xamarin Image Importer

Firstly, I have a confession to make … I am pretty lazy! Perhaps not Homer Simpson lazy, but it’s something I do aspire to… 😉 I take some solace from this quote attributed to Bill Gates:

“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”

On a recent Xamarin.Forms project I was working on, the focus was a UI/UX refresh with a lot of non-linear lines and shapes. Accordingly, there was the need for a lot of images. The requirement was to support @1x, @2x and @3x resolutions on iOS, and mdpi, hdpi, xhdpi and xxhdpi on Android. So for every image required, there were actually 7 variations of the same image at different resolutions. On top of that, as the project went on sometimes images would need to get updated to get things pixel-perfect, while other times churn would be created as the machinations of the business got involved. This added up to many minutes lost to a tedious, error prone, recurring manual task. The pain of this process was particularly felt with Android, which uses the convention of a separate directory for each resolution.

I already had some PowerShell up my sleeve to mitigate some of the pain, but I decided to polish it up and make it available, for the simple joy of writing and shipping code without bureaucracy if nothing else. And so, the Xamarin Image Importer was born, in the form of a module in the PowerShell Gallery.

This little utility aims to do 2 things only – (1) copy images to the correct location in the file structure required by iOS / Android (2) add them to .csproj files so they will appear in Visual/Xamarin Studio. Many of the variables of the process can be inferred by convention. This worked well for the project I was working on, where the designer on the team would export images from a SVG using Illustrator then dump it into a Dropbox folder. From there, the PowerShell slurps in the images and does the rest.

While I have no immediate need to develop the tool further for myself right now, some potential additions I can imagine include:

  1. A pretty simple change to cater for images other than .png
  2. Handle project types other than Xamarin e.g. Telerik AppBuilder
  3. Take a .svg as the import source, and then do the export into various resolutions automatically, reducing the need for the likes of Illustrator or Sketch purely for this mechanical task (version 2.0?)
    • Could perhaps use the logo.gen tool my colleague Poya Manouchehri has been working on
  4. Something else somebody suggests and/or comes up with in a Pull Request

Anyway, hope this little tool helps some of you out there. Happy lazy coding!


Xamarin & Azure: BFF, Really?

Earlier this week, I gave a presentation at the Brisbane .NET User Group.

The talk was focused on the integration story between Xamarin and Azure, with a deeper look at the Offline Data Sync feature. The value that Azure provides for mobile apps is really good these days, and is ever evolving and improving like everything with Azure. While I used Xamarin.Forms as a convenient example during the presentation, Azure’s support for mobility is not just for Xamarin, but also for native iOS, Android, Windows or Cordova-based apps. This of course reflects Microsoft’s recent philosophy of platform agnosticism.

Anyway, the slides are below:

Java To C# – There & Back Again

Many years ago, I used to be a Java developer. I liked it, and even held elitist attitudes against .NET when it first came on the scene in response to Java. At the time I thought, “there was Microsoft years behind yet again, not innovating but merely copying the market leader!” Later, the organisation I was working for made “strategic” technology changes to go with the whims of new management (without consulting the team of course). Before I knew it, I was developing in C# on the .NET stack. Kicking and screaming all the way, but mind you, professionally kicking and screaming all the way.

Anyway during the recent Christmas break, I decided to get my Java back on and have a play with native Android on a pet project. Yes I do realise that Android has its own implementation of Java, only adopting its syntax and semantics. So for the purpose of this post, I will focus on the language and not the platform or Android specifics. Within several hours however, I already had a list of Java features that were frustrating me or I was yearning for! Without further ado …

1. Decimal Numbers
I was shocked that in the 10 years or so I have been away from the language on a day-to-day level, Java still does not have a more elegant and concise way to deal with decimal numbers. They are still second class citizens – I don’t want to have to deal with a boxed object every time I work with currency! The decimal type in .NET is much more convenient to work with. Surely Java could provide arithmetic overloaded operands for BigDecimal at the very least?!?

2. Properties and Object Initializers
While properties and object initializers are really just “syntactic sugar”, I do appreciate how they make code more concise. More specifically with properties, there is no longer the need to have explicit setter/getter methods to access private fields, while object initializers alleviate the need to have multiple constructors catering for every parameter permutation. Admittedly, if I hadn’t gotten used to this syntax in C#, I probably wouldn’t have noticed their absence in Java. But I have, so I did.

3. Implicit Typing
I surprised myself when I realised I missed being able to declare “var” instead of the explicit type. When the feature was introduced to C#, I was skeptical before slowly embracing it. I know this is a contentious issue and there is still a debate on it … but these days I know how I prefer to code!

4. Asynchronous-ness
Since .NET 4.5 onwards until facing life in Java without them, I took for granted just how awesome the async/await operators are. It’s quite impressive when you look in depth at the work Microsoft have done to make asynchronous programming so easy – the compiler generates a state machine for each async declaration! Of my wish-list for Java, this is admittedly the most ambitious, but it would certainly be nice.

I never thought I would say this back when I was primarily developing in Java, but I really like C#! It is no longer a necessary evil forced upon by circumstance, but now my language of choice. As it stands today, C# is more concise, elegant and progressive than Java. Furthermore if you look at the history of release cycles, Microsoft is evolving and iterating the language faster than Oracle. As such I have every confidence that C# will continue to provide a great developer experience for the foreseeable future. However, if there is one thing I have learnt in my time in the industry is to not be dogmatic about technology, as demonstrated by the swinging fortunes of Java and C#. But for now, C# FTW! 🙂

Xamarin Test Recorder

By many accounts, Xamarin is a fantastic product that makes it easier for developers to build apps for a range of mobile devices. For me however, delivering that functionality well is only ‘par for the course’. That is, a seamless experience to develop an apk, ipk or appx is what I would simply expect for any offering that promises a common code base targeting multiple mobile platforms.

An approach that continues to strike me about Xamarin is their commitment to making the mobile software development life-cycle easy – the entire process of building, testing and monitoring to borrow from the company’s current mantra. The direction taken by Xamarin with the 4.0 release certainly builds upon the impressive suite of tools already available. One new feature of this release that I was particularly eager to get my hands on is the preview of the Xamarin Test Recorder. Whereas many other features available in the 4.0 release are evolutions of known tools, to my knowledge Test Recorder is a completely new offering. It is good to see the company not rest on their laurels!

To get the Test Recorder running, you first need to download and install the OSX package. However, there are several steps which are not explicit in the preview version of the documentation I was looking at. As such, I will outline them here should it help anybody.

1. You will need your Xamarin Test Cloud API key upon installation. This is available once you log in to your Test Cloud portal. In case you are wondering about hidden or unexpected costs, remember that all Xamarin subscribers have 60 free Test Cloud minutes each month!

2. If you wish to use the Test Recorder with an Android project, you will need to grant the ‘INTERNET’ permission in the Android Manifest.

3. Publish your apk or ipk locally. Then simply start Xamarin Test Recorder, select the apk/ipk you previously published and the magic begins!

Now, all you need to do is hit ‘Record’ and starting using your app. When you finish the sequence you wish to test, click ‘Stop’. From there, you can either ‘Play’ the test sequence again, copy the generated Xamarin.UITest output to the clipboard, export to file to import into your test project, or send it straight to Xamarin Test Cloud. As you can see below, I have put the Test Recorder in action on the sample timesheet app I recently made available.

Xamarin Test Recorder generating tests for my sample timesheet app on Android
Xamarin Test Recorder generating tests for my sample timesheet app on Android

Manual testing is of course time-consuming and somewhat error prone, but absolutely necessary in software development. This is perhaps even more true in the world of mobile apps where there is much competition. But Xamarin.UITest and Xamarin Test cloud already solves the problem, so why do we need the Test Recorder? The answer is of course, the significantly reduced time for developers to write tests! Furthermore, there is even potential for non-developers to generate tests! Imagine empowering your BA or QA team who are not well-versed with Xamarin to develop tests … or even watching and replicating how your non-technical grandmother breaks your app!

I do wish it was more complicated to get the Test Recorder running, as it would make this blog post look more insightful and myself more intelligent! 🙂 However, there really isn’t any significant barrier to entry if you are already an existing Xamarin developer. I can’t wait to use the Test Recorder on my next live project.

Xamarin, thank you for exceeding my expectations once again!



Xamarin Timesheet Sample App

As part of studying for my Xamarin Certification, I wanted some extra practice before sitting the exam. As such, I decided to do a Xamarin iOS and Android version of the same Xamarin.Forms timesheet app I implemented and wrote about before. The added bonus of this is that it could potentially provide a basis of comparison between ‘vanilla’ Xamarin and Xamarin.Forms. So in case it helps anybody, I have made the source code available on GitHub.

Xamarin iOS & Android Implementation:

Original Xamarin.Forms Implementation & Corresponding Blog:

Exam Update

I subsequently passed the exam … I am now certifiable certified! 🙂 That will most definitely do me for a while in terms of exams and certifications, having notched up my MSCD, PSM I and now Xamarin in the past 6 months. I’ve enjoyed the process and they were all valuable experiences, but for now it is time for me to get my hands ‘dirty’!

Badge Collected – MCSD (Web Applications)

I know you have all been on the edge of your seat wondering why I haven’t been blogging recently! Well, I have been using my spare time to prepare for the “MCSD – Web Applications” certification, which I successfully completed yesterday. What a better way to get back on the blogging train than by quickly writing about my experience of the certification process!

For me, the biggest takeaway of doing this certification is that it provided a framework for learning and a tool for self-improvement. I also set myself a goal to finish it by the end of June. Without such catalysts, my natural tendency is to learn in an ad-hoc manner, and typically only as much as I need to for upcoming tasks at work. In studying for the exams I became familiar with technologies I didn’t even know existed previously (e.g. WCF Data Services or Entity SQL). To put it another way, I didn’t know what I didn’t know before! As a consultant that is expected to be at the top of my game and could get thrown anywhere in the Microsoft stack with minimal notice, having a prior understanding of everything in the toolbox certainly does not hurt. Furthermore, knowing how the range of ‘lego blocks’ can work together enables me to effectively design elegant solutions with different approaches – not just the way I may already know.

Some may suggest that in the age of intelli-sense and Google whether it is necessary. To be honest, during the grind of studying I asked myself that question too as I tried to memorise the third parameter on some function I was unlikely to ever use. I don’t know how much detail I will recall in future, but I am confident I will remember the key concepts of technologies I came across. It also gives me sufficient background knowledge to quickly navigate many technical problems effectively. I’m not suggesting I won’t need Google in future, but I dare say I won’t need it to learn ideas for the first time in the ‘heat of battle’ with a deadline looming.

Overall, while it took more time and effort than I originally expected, I am really glad I did it (I did take the time to write small snippets of code or click around the recesses of Azure I hadn’t previously.) Admittedly, I’m probably also one of the rare few that actually like to read the manual before getting a new toy or tool. I also happen to enjoy the process of learning and acquiring knowledge, if not necessarily studying or sitting for exams. There is an adage that ‘when you have a hammer, everything looks like a nail’ … as a craftsman, I am now much more familiar with the range of tools at my disposal so I won’t need to use the same ‘hammer’ for every job!

But for now, I am going to delete the hundreds of MSDN and other bookmarks I accumulated during the course of my study! 🙂

5 Different Retrospective Ideas

On a recent client project that embraced many Agile ideas without adhering strictly to one methodology, I had some ‘Scrum Master’ responsibilities. One aspect of this I enjoyed in particular was facilitating our team retrospectives. Over several retros towards the end of the project when many of the easy improvements had already been identified, I endeavoured to introduce a new activity each time in an effort to keep each meeting fresh. After consideration of where the team and project was at each time, below are the activities we tried along with the rationale as to why and how it went for our team. (As an aside, a thank you to the team for being willing guinea pigs!)

1. Turn The Tables
Activity Details: scrumalliance.org

This is a fun, interactive game that ensures everybody gets involved. In essence, the premise is that each person writes down what is good and bad about the project using only 1 or 2 words, while a different person has to explain it. The value of this activity is that it develops understanding of different perspectives as each participant has to present another team member’s input with only minimal context. As an added bonus, hilarious misunderstandings will typically come out of it, lightening the mood and bonding the team. In my opinion, it’s not a retro you would conduct every sprint but is worthwhile to consider occasionally especially when a team hasn’t quite gelled yet.

2. Liked, Learned, Lacked, Longed For
Activity Details: funretrospectives.com

This activity provides the team with an analytical framework to reflect on the good and bad of a project. That is, it encourages participants to articulate the good with ‘liked’ and ‘learnt’, and the bad with ‘lacked’ and ‘longed for’. The ‘liked’ categorisation should be self explanatory, while in my experience what typically separates good developers and teams from the pack is the perpetual desire to learn. As such, encouraging participants to reflect on what they have learnt is definitely a worthwhile exercise. The differentiation between ‘lacked’ and ‘longed for’ was not immediately obvious to some and needed clarification, but the idea is the former focuses on what has been done already but could be done better in future, and the latter exists only in the realm of imagination. Like ‘Jessica Alba’ and ‘Hugh Jackman’ according to one of our team, without elaborating and violating the ‘circle of trust’! 🙂 Overall, it is a reasonably simple and worthwhile activity to run semi-regularly.

3. Circles & Soup
Activity Details: innovationgames.com

If team feedback is anything to go by, this game is a definite winner with some of our team suggesting to do it again! The activities we previously tried, while providing variety, still tended to operate on the good-bad paradigm. With ‘circles and soup’ however, the thinking completely shifts to what is in the team’s control, what is under the team’s influence, and things that the team cannot change no matter the level of desire or effort. Thus, this simple game really helps the team to focus on the action points with the highest chances of success.

4. How-Now-Wow
Activity Details: innovationgames.com

The crux of this activity is to categorise ideas along an x-axis of originality and y-axis representing the difficulty of implementation. As a result, a matrix of four quadrants is formed: (1) difficult, original ideas – ‘how’ (2) easy, original ideas – ‘wow’ (3) easy, normal ideas – ‘now’ (4) difficult, normal ideas – largely ignored. As a facilitator, I did not have the prescribed coloured dot stickers available and so I had to improvise. Additionally, I inadvertently treated the 2 axes as continuums rather that discrete boxes – I would suggest that it is more productive to stick to the simpler box model as prescribed. The focus of this activity is on identifying original or innovative ideas, and to that end it does it well. As such, this activity is probably best suited towards the start of a project or at a natural juncture of an ongoing one.

5. Wellbeing North Star
Activity Details: innovationgames.com

This meeting became an unofficial retrospective for the project as a whole as it came to an end. For this, we wanted something fairly simple to frame discussion points around different aspects of the project, and so the Wellbeing North Star fit the bill well. Essentially, the idea is to put the central idea of discussion in the middle of the star, with an aspect of this idea on each point. The points of the star we used were: (1) Tech (the ‘what’) (2) Process (the ‘how’) (3) Client (i.e. the gig itself & working environment) (4) Readify (i.e. our consulting team & company) (5) Career (i.e. ‘me’). The activity went well and served its purpose.

Final Thoughts

There are many activity options available once you begin to look, but I found the majority of them are simple variations along the ‘good vs bad’ axis of analysis. There is nothing wrong with this line of thinking and it served us well for a long time, but in our situation changing our retrospective format reinvigorated our retros and helped to identify suitable points of improvement.


What Makes a Good Developer Blog?

When I was writing one of my recent posts, I thought to myself – “what makes a good blog for a developer?” So out of curiosity, I began to do some quick research on the matter. Somewhat surprisingly, while there was a lot of advice for blogging in general and some for tech gadget-y blogs, there is not as much targeted specifically for developers. I don’t pretend to be a subject matter expert on the topic nor provide any original insights here, but for personal reference if nothing else, I have summarised the key takeaways from the sources I found to be most useful.

1. PluralSight – “Get Involved”
Full Course: pluralsight.com

This is a PluralSight course by Scott Hanselman and Rob Conery. Apart from blogging which is my focus here, the topics covered included Twitter, GitHub, StackOverflow and user groups. The content even included the rudimentary mechanics of setting up a blog for absolute beginners, and also broader career considerations for developers. Below are the nuggets I noted for myself as I was watching it.

Scott Hanselman
According to Scott, there are 2 types of blogs.
1.  A how-to, guide or documentation supplement … these should:
–  Be detailed and clear
–  Link one concept to the next
–  Solve a problem
2. An opinion or ‘op-ed’ … these should:
–  Contain concise explanations
–  Backup your opinions
–  Not rant
To ensure his words always add value and have purpose, as Scott writes he continually asks himself “SO WHAT?” That is, he repeatedly questions the relevancy of his writing.

Rob Conery
Rob describes his characteristics of good and bad blog posts.
1. Good:
–  Write what I care about
–  Do so truthfully
–  Infuse personality into writing, while showing skill with words
2. Bad:
–  Being overly dramatic or using cliches
–  Trying to sell or conform to something
–  Trying to manipulate or being over the top
=> ‘Dishonest writing’
Good feedback once given to Rob – “I can hear your voice so clearly – it’s like you’re talking to me.”

Jeff Atwood
Jeff’s thoughts on blogging are:
–  Tell a story
–  Should sound like something I would say.
–  “Is this the way I would say it?”
–  “Does it sound like writing, or does it sound like talking?”
=> Conversational in style

Rob Conery on Scott Hanselman’s style:
His live presentations mirrored his writing style, which contains deep technical detail, witty asides, interesting pictures … and he always learns something new.

Rob Conery on John Gruber’s style:
Minimalistic … sometime his posts contains contain quotes with very few words of his own but they always make a strong point.

Rob Conery on Jeff Atwood style:
Synthesises disparate sources into something new.

2. Simple Programmer – “How Taiseer Joudeh, Built an Incredibly Successful Technical Blog in 14 Months”
Full Article: simpleprogrammer.com

Thanks to my colleague @EmadAshi for pointing me to this article where John Somnez interviews Taiseer Joudeh. It is a quick read and very informative, with the key takeaways for me being:
–  Be passionate about your topic – if so the content will come and it won’t seem like ‘work’
–  Taiseer picked a niche area to specialise in
–  Use your own words and writing style – authenticity
–  Be consistent in how often you blog
–  Also has other good tips for promoting your blog – you can read these for yourself if you are interested! 🙂


Xamarin Native Linking Failed in an iOS Unified API Project

On a project my colleague @halkar and I were working on, we came across a puzzling issue. We only discovered this issue after converting our project from the Classic MonoTouch API to the Unified API. On the iOS simulator, our application would fun fine, but when we tried to run it against a real iOS device, we could get an error to the effect of “Native linking failed, undefined Objective-C class …”.

Xamarin - Native Linking Failed

A quick search within our solution revealed no clues, and the subsequent Google search confirmed that EAAccessoryManager is indeed a native Objective-C class. So the class is clearly defined, but our compiler tells us otherwise?

As per the compiler error message, Google has multiple sources to suggest that the solution is to simply add a [Protocol] attribute to the offending C# class. However, here the code wasn’t in our application but in the Xamarin binding library that didn’t get linked to the corresponding Objective-C EAAccessoryManager.

Upon further investigation of the Xamarin.iOS Type Registrar to explain why the application worked in the simulator but not a real device, it turns out that Xamarin uses dynamic registration for simulator builds but static registration for device builds. The reason for this is speed, in that a development machine would have the necessary power to scan classes at runtime, whereas a new binary is always required to deploy to a device. Going down this path, a suggested solution is to use the legacy registrar, but this just results in a different compiler error indicating it is not allowed in a Unified API project.

So where to from here?

Enter the Xamarin Linker

This led to us having a deeper look at the Xamarin.iOS Linker. In short, our project compiled when we selected “Don’t link” for the Linker behaviour option. The default option is “Link SDK assemblies only”, which will mean the Xamarin linker will attempt to exclude all the symbols from the SDK it thinks is unnecessary. Unfortunately, it appeared in our case the static registration analysis was over-zealous. It should be mentioned also that the use of the word “Linker” by Xamarin is slightly counter-intuitive as noted by Adam Kemp and the behaviour is different to the conventional sense of the word. For my own understanding, I found it made more sense if it I substituted the word “Optimize” for “Link” – i.e. pick the “Don’t optimize” option!

Xamarin - Linker Options

But it has to be at least … three times bigger than this!

Please pardon the obscure Zoolander quote, but in practice you will need to consider the size of the generated IPA binary. It really depends on the exact nature of the application as to what the actual size difference would be, but roughly speaking it appears the “Don’t link” option can be 3-5 times larger than the default “Link SDK assemblies only”. App consumers these days are quite unforgiving, and so you really need to do everything in your power to provide a good first impression. This, of course, includes minimising the size of your app and therefore potential installation problems.

As such, the solution we settled for was to explicitly reference the EAAccessoryManager class in our code, allowing us to revert back to the“Link SDK assemblies only” option. This of course is merely a workaround, but it was the most elegant method we came up with to solve our problem. Hopefully Xamarin will address the issue with the Linker soon, but until then this workaround should do the trick.

using ExternalAccessory;
var sharedAccessoryManager = EAAccessoryManager.SharedAccessoryManager;

Success! Time to go home.

Addendum – Xamarin Support

A big shout out to @kumpera and the Xamarin support team! We had a response within 24 hours after submitting a sample solution to replicate the problem. In our particular case, there were 2 issues that were at the root of the problem, neither of which was a fault with Xamarin. Firstly, a third party library we used did not contain ARM64 code, meaning linking failed when building for this architecture. Secondly, this library also had dependencies on frameworks such as the EAAccessoryManager. Anyway, instead of the workaround originally suggested, a better way to do achieve the same thing is to use the LinkWith attribute.

[assembly: LinkWith (..., Frameworks = "ExternalAccessory")]

Once this attribute was added and we selected ARMV7 as the architecture to build for, we no longer experienced the issue originally described.


My First 6 Months @ Readify

As of today, I am no longer on probation at Readify. Happy days!!! With this milestone, I wanted to take a few moments to reflect and share my experience of the first six months in the business.

Going into Readify I knew I would be surrounded by brilliant minds, but I didn’t realise how good it would be to learn and work alongside them. At first it was such a challenge to not be intimidated but I could see the continual opportunities for growth. While I hadn’t previously given much credence to certifications or even MVPs, of which there are an extraordinary number of at Readify, I quickly changed my opinion after seeing them operate. It has certainly inspired me to work on the depth and breadth of my own technical knowledge. As such I have committed myself to obtaining a number of certifications that interest me, starting with a MCSD in Web Applications. Fortunately, the company has good provisions for professional development to support this.

While the team all know their stuff technically, what differentiates Readify from many other technology companies is the emphasis on leadership, teamwork, influencing and soft skills. I have previously been in environments with many incredibly smart people and have also been in environments with many influential and charismatic leaders. However, it is certainly rare to have so many technologists who are articulate, influential and also enjoyable to have a few drinks with! I have particularly enjoyed working with the Principal Consultants. It is obvious almost immediately why they are where they are, as they can always seemingly communicate ideas quickly, readily and convincingly with only a few short sentences.

Another observation which I believe separates Readify from other organisations I have worked for is their desire to promote on merit. In the past, I have felt that often the wrong people get recognised by seemingly only using their social or political skills to climb the corporate ladder. While building trust and camaraderie with your team will never go astray, the emphasis at Readify does appear to be actual job performance. More importantly for myself however, while I may not currently be a Principal Consultant, I am encouraged to be as good as I can be and am consistently empowered, supported and shown how to improve. Other organisations I have been at expect the best people, but with no idea how to *produce* the best people. At Readify though it seems the main ceiling is myself and how much effort I am willing to invest to mastering all aspects my craft.

Finally, the company’s annual kick-off was certainly an eye opener and highlight for me, which was held soon after I started. What I now remember most vividly after several months was how executives admitted mistakes and addressed how they would rectify them. This was done openly on stage with little sugar-coating. In my experience, management tended to not admit mistakes until it was too late with half of the company suddenly retrenched. Alternatively, mistakes were swept under the carpet and never talked about. Since kick-off, I have seen management continually ask for feedback from the entire company and then diligently attempt to follow through to make it a stronger organisation and a better place to work. The results may not always please everybody, especially with such a diverse and intelligent crew with strong opinions, but it is definitely not for a lack of effort or desire. I remain impressed by the genuine and transparent way in which management conduct themselves.

Overall after six months, I am certainly enjoying the challenge, culture and the environment that Readify provide. With the benefit of hindsight, of the opportunities that presented themselves to me at the time, I have no doubt I made the right choice with Readify! It has been a long time since I genuinely looked forward to coming to work each morning.