Archive for Xamarin

Hybrid Today, Progressive Web App Tomorrow

App (and I am using that term very loosely here) development has undergone a change. Most companies are eschewing high cost native development and for iOS and Android and going with hybrid solutions using tools like Xamarin or Ionic. This is a great way for organizations to lower their initial development and ongoing maintenance costs as well as get a useful app for their business needs. One area that many organizations are finding is that they still need desktop web applications and you don’t get the code sharing advantages between mobile and desktop platforms that you do between the two dominant mobile platforms – iOS and Android. Luckily, the march of development tools and frameworks has carried on and there’s a new solution – progressive web apps. These are web applications that live on the server but thanks to powerful JavaScript (or in some cases Typescript) can access native-like device capabilities. This, coupled with responsive development techniques and some adaptive CSS allows the app to scale in not only screen-size but also capabilities depending on the device. There are a number of frameworks that provide this, but my two favorites are Angular 4 and Polymer 2.

The Angular team now uses the tagline “one framework, mobile and desktop” and they mean it. Angular has come a long way from the original release of AngularJS and is now a full application development framework.  Currently, Angular is on version four and if you’ve used an older version of the framework you’re going to find major differences (especially in the area of routing) but the time invested into catching up is well worth it. Using Angular 4 you can now create a high-functioning application that runs on everything from your twenty-seven inch desktop screen all the way down to a mobile phone. I do find that there’s a bit more ceremony in the latest versions of Angular than in the first, but you could argue that’s an advantage, since it also makes the framework more flexible than its predecessor.

Polymer 2 is more focused on JavaScript components than Angular but is no less powerful. While the details of it works under the hood are different the end result is exactly the same — you end up with a powerful application that can scale for different screen sizes and devices.  If I had to make a comparison between Angular and Polymer 2, it would be that the Polymer team has made more of an effort to be “pure JavaScript.” I don’t love that criticism of Polymer for two reasons: 1) Angular is now written in Typescript and I (in my opinion) best consumed using Typescript and 2) some of the custom directives in Angular actually lead to less boilerplate than the more “pure JavaScript” alternatives in Polymer (especially around defining custom components), so I’d actually consider that a feature for Angular rather than a bug. Still, that doesn’t mean that Polymer is not a great choice for your progressive web app development needs.

There are of course other choices for developing progressive web apps but these two projects have the backing of Google and large communities around them, so they’re likely going to stand the test of time unlike the many <insert_noun.js>  JavaScript frameworks of the previous ten years.  The future looks bright for the progressive web app and by extension Angular and Polymer, given that the trend of businesses demanding more for less out of their developers and development partners is likely to continue.

If you liked this post, follow me on Twitter for more!

The Year of Xamarin Development?

1423190333_thumb.pngXamarin may now be a viable tool for cost-efficient hybrid app development since it’s recent acquisition by Microsoft.

The current app marketplace is highly competitive and as the general startup market cools in

terms of funding, launch runway for apps is going to be even more important to early stage startups. Xamarin may allow cash-strapped startups to leverage code-reuse and the large pool of global C# developers while targeting both iOS and Android.

In general, developing an app natively for both platforms will nearly double the cost of client-side development and require a team to staffed with developers well-versed in Java as well as

Swift / Objective-C. Even with today’s outsourcing resources, the cost of this duplicated effort can stretch the budget of many startups.

Microsoft’s challenge will be finding a way to keep Xamarin attractive to mobile developers ontoday’s leading platforms by keeping up with the innovations and platform updates brought by future iOS and Android versions. They have to not only keep up with Apple and Google but also attract developers to develop apps for Windows 10, something that has to date proven near impossible.


Xamarin + Microsoft


Today it was announced that Microsoft is acquiring Xamarin. I’m well on the record as having some mixed feelings about the Xamarin platform. Details are still pretty few and far between about the structure of the deal (other than the obvious fact that it’s a straight acquisition) or what Microsoft intends to do with the platform once they have control of it. Hopefully, Microsoft can leverage its resources to resolve improve Xamarin’s core weaknesses: pricing and Xamarin Forms.

Far be it for me who has railed that we don’t charge enough for software in general to criticize a company’s pricing structure but Xamarin’s pricing really leaves a bit to be desired. My issue is not with the dollar price per se but with the fact that you can’t code in Visual Studio, a far superior experience to Xamarin Studio, with the Indie license and that fact that LINQ to SQL is only available at the Business tier. It would be much more appropriate for the tiers to be separated only by support and SLA’s rather than actual functionality provided in the tooling.

Xamarin Forms, though it has gotten better since I last looked at it, needs some attention. The truth is that most internal development projects don’t have a focus on the platform specific user experience and managers would love to deploy a write once run everywhere solution.

It’ll be interesting to see how Microsoft takes Xamarin and supports its developers and if you’re interested in getting a mobile development project done, please fill out the form on this page.

LOB in 2015

Line of business software development is one of the least discussed and least sexy areas of software development. Ironically, it is by almost any metric the largest. There are more HR applications that are succussfully running inside their organizations than there are indie apps that are successful business.  Why don’t we care about LOB software? Why isn’t there an LOB blog or podcasts about being LOB developers (or even “dark matter developers”), the tools they use, and the struggles they face? Well, LOB development has been boring at least up until now. 

2015 is going to be the year that all of those older LOB applications get brought into the modern world. This will be brought upong by a mixture of pressure to go mobile and the natural purchasing cycles of medium to large enterprises.  On this week’s Coder RadioChris Fisher and I, had a lively discussion about Xamarin.Forms and my less than stellar expereince with it. 

Purists will of course say that for the best expereince on a platform you have have to develop natively on the officially supported tools for that platform. I agree with that, but here’s the thing — not everyone wants or needs “the best”. We make compromises of this sort al the time. For instance, I can’t afford the best car, so I drive a car that’s good enough for me; if you must know, I drive an 08 Toyotal Corolla. You see, I made a cost / benefit analysis when purchasing my car all those years back and that’s the exact sort of calculus that business types make routinely when it comes to commissioning line of bussines applications; that might explain all the IE 6 and VB code that’s running around for sure….

Here’s where I get controversial — I think they are right and correct in their decision, at least in principle. The issue becomes one of balance. How do you balance quality and cost-savings? That’s the question (at least in the mobile space) that Xamarin and the various vendors of mobile web-based app development solutions will have to answer. I still hope that Xamarin gets their act together with Forms, since C# is a much more pleasant language to work in thatn Javascript, but only time will tell. 

Xamarin.Forms Review

A few months back in August I did a brief review of Xamarin in which I was pretty happy with the tool-kit and how it was helping the team at Fingertip Tech, INC
efficiently handle developing mobile apps for both iOS and Android. Now that we are about six months on and I’ve built a lot more expereince with the tooling I’d like to take a deeper look at Xamarin’s “write once run anywhere” offering Xamarin.Forms. 

I’ll be blunt — Forms is as immature as it is seductive. Don’t get me wrong, the things that Forms does support are great and work really well cross platform but the reality is that you can’t get very far without Xamarin.Forms Labs, an impressive open-source project that sadly suffers immaturity and having to keep up with Xamarin which has to keep up with iOS and Android. Additionally, if you really care about the user experience of your apps, then you will likely end up having to purchase some controls from Telerik or the like. To ble clear, I’m not just talking about complex charts or anything like that. To date, Forms doesn’t have an ImageButton class — you’ll need Labs for that.  

The work around for all this is writing custom renderers for each platform. The problem there is that basically defeats the purpose of using Forms, since you might as well use “classic” Xamarin at that point; the assumption being that you are using Forms to cut down on platform specific work. 

Having said all that, I was able (along with the awesome team at FTT) to ship projects using Forms but we ended up underwater financially on almost all of them, since we had to write “customer renders” for any non-trivial UIs. 

Forms is a great idea. Sadly, it’s the same great idea that Sun had for Java on the desktop in 1990’s. Xamarin could make Forms a great offering but would be wise to take the lessons of desktop Java and RealBasic to heart. 

Follow me on Twitter or Google+. Interested in getting your app project off the ground? Then, contact Fingertip Tech, INC and forget to follow us onTwitter!

Pallet Town: Xamarin.Forms Basic IOC

enter image description hereWelcome to Pallet Town! Pallet town is going to be an ongoing bi-weekly look at various development technologies and techniques from the perspective of someone new to that technology. For those who might know or (God forbid) are too young to get the reference, Pallet Town is the first town in the original Pokemon games for the Nintendo Gameboy.

Xamarin.Forms is a cross platform tool that allow code re-use for iOS and Android. It works by interpreting your C# code and layout it out using what are usually reasonable conventions for the specific platform’s UX paradigms. For example, a Forms Tabbar lays out on the bottom of the screen in iOS but the top on Android devices, thus following the conventions for both platforms correctly.

Forms makes good use of the common .Net inversion of control development technique. If you haven’t worked in the .Net space, then IOC may seem a bit strange – indeed, it has taken me some time to actually figure out how it works but it’s actually pretty simple to get started with and is extremely powerful in terms of code re-use and modular design. Forms.Labs, an open-source collection of classes designed to jump start your Forms development, uses IOC to great effect to help you easily access device specific functionality from your shared Forms code, rather than having to write platform specific code.

Let’s take a simple case of wanting to import an photo from your device and wanting to keep it as much as possible on the Forms level, rather than dropping to platform specific code. Here’s the shared code that would likely be on a Page in your app:

IMediaPicker picker = DependencyService.Get<IMediaPicker> ();  
MediaFile img = await picker.SelectPhotoAsync (new   CameraMediaStorageOptions {
                MaxPixelDimension = 100 // arbitrary size

OK, so you’ve picked an image. Now let’s take things a step further and say that you want to save it to disk for some other use, such as uploading it to S3 or maybe just to have for later:

var fileAccess = Resolver.Resolve<IFileAccess> ();
string imageName = "somename" + "jpeg"; // assuming jpeg
fileAccess.WriteStream (imageName, img.Source);

What we are doing is uses a shared / abstract interface to call onto both the phones image gallery in the first snippet and the filesystem in the second. So far so simple and I’m happy to say it really never gets much more complex. We just have to do a little platform specific code. First, let’s take a look at our AppDelegate for iOS:

var resolverContainer = new SimpleContainer ();
    resolverContainer.Register<IDevice> (t =>   AppleDevice.CurrentDevice)
            .Register<IDependencyContainer> (t => resolverContainer)    
            .Register<IFileAccess> (t =>; new FileAccess ());
Resolver.SetResolver (resolverContainer.GetResolver ());

You’ll either want to add this code to your ‘FinishedLaunching’ method or create a separate method and call that method from ‘FinishedLaunching’. Now, let’s take a look at Android where we will be working in our MainActivity:

var resolverContainer = new SimpleContainer ();
        resolverContainer.Register<IDevice> (t => AndroidDevice.CurrentDevice)
            .Register<IDependencyContainer> (t => resolverContainer)    
            .Register<IFileAccess> (t => new FileAccess ());
Resolver.SetResolver (resolverContainer.GetResolver ());

Notice that the code is just about identical with the obvious ‘AppleDevice’ versus ‘AndroidDevice’ difference. Basically, what we are doing is setting the correct platform specific objects upfront on application launch, so that when we call the first snippets in our shared code, we don’t have to care which platform the code is actually running on.

Developers experienced with IOC will note that this is a pretty simple example of IOC and it is capable of much more than just abstracting away the device platform. If you’re just getting started on your development journey and are having a hard time wrapping your head around the snippets here, don’t worry about it and come back to it later. This is just mean to be an introduction to IOC on Xamarin.

Hope this post helps you on your journey to become a Pokemon… err coding master! Please feel free to send any feedback to me on Twitter or Google+. Also, be sure to check out my company Fingertip Tech, INC on Twitter.