July 01, 2015

In 2011 when Xamarin was founded, if someone told me the story of a .NET and C# platform that could create native mobile apps I would have thought it sounded great. Objective-C was a nightmare for C# aficionados and creating Android apps was no picnic either in spite of using Java which is similar to C#. The total learning curve was massive for developers who wanted to try their hand at mobile apps. The story of Xamarin made perfect sense, or so it seemed.

Fast forward to 2015 and a lot has changed. Xamarin developers have grown into a large and active community, which is incredibly important for any platform in it’s own right. We now have the experience to know it’s possible to build non-trivial native apps successfully with it. The company is heavily investing in new products and services to make it easier to embrace Xamarin for the entire product life cycle.

The biggest problem in all of this is that the original premise (and promise) never held up. In a recent discussion with someone from Xamarin they suggested the product could save having to “re-write your app…from scratch” three times (iOS/Android/Windows). This is partially true, and therein lies the rub. I explained to this person that creating apps for iOS, Android, and Windows has multiple, very different challenges. Xamarin solves some of them. Unfortunately, these are the smaller parts of the problem.

The Good Stuff

Let’s start with the tangible benefits of Xamarin. Writing in a single language is pretty luxurious. iOS and Android projects can coexist in the same solution. With muscle memory in full force mistyping is less common. Syntax, language conveniences, and data collections are familiar and intact. One of my favorite things in Xamarin is being able to whip out something like this from memory and have it work perfectly on all platforms:

.NET collections are fast, powerful, and easy to understand.

Using Java to develop Android apps can get annoying. Imagine having spell out get and set for every property accessor.

Smaller, cleaner code in C# compared to Android/Java

more C# elegance, is vs instanceof

Refactoring is another thing that’s better in Xamarin C# compared to Xcode (iOS). Ironically it’s not as good as using Microsoft C#, because Visual Studio, ReSharper, and CodeRush have reduced functionality with Xamarin projects. For example, you can’t use refactoring to clean namespaces. However Swift in version 2.0 still does not support any refactoring via the latest Xcode beta. This is a big weak spot for Apple and honestly a little embarrassing at this stage.

Speaking of Xcode, a benefit of Xamarin, the biggest I think, is that you do not have to learn or code in Objective-C. Objective-C is actually fairly productive once you’re experienced with it, but the language is both dated and weird compared to what most developers are used to given its Smalltalk/NeXTSTEP roots. When I first learned Objective-C, I resented having to use it and the Xcode IDE which was years behind Visual Studio in many respects.

Support

Whether you use Xamarin as a freelance developer or on an enterprise team, good support is important. While the sample size is small I can easily say my support encounters with Xamarin folks were top notch. I talked to smart people who knew how to work through issues. They were also open to discussions on general topics such as when is it a good fit to use Forms. As you might hope they are passionate about their products, believe in them, and want you to be successful.

The Problems

The biggest disadvantages of Xamarin come down to small productivity increases and stability of the overall platform.

If you try to develop a great app for iOS and Android with a nice, native UX, it turns out the biggest problem is the vast difference in UX architecture between platforms. This is a problem Xamarin doesn’t help you with much. Since these differences are 80%+ of the difficulty, the maximum value Xamarin can offer is really constrained by the 20% of the problem they are addressing.

It’s hard to understate the part of the problem Xamarin does not solve. The difference in UX coding, animation, resources, synchronization, views, workflow, etc., is really night and day between iOS and Android, let alone .NET. While Xamarin allows C# everywhere, it's often C# using two different frameworks with different classes and semantics.

Even if you target only one mobile platform, the benefit of knowing .NET cannot help you with something as simple as loading an image. You learned about the .NET Bitmap class, GDI, etc.? That knowledge is really not very useful for mobile apps. So a key issue here is that Xamarin touts “leveraging existing .NET knowledge”, however this comes with the huge asterisk. A significant part of your .NET knowledge won’t apply here.

When Apple released the Swift language in 2014, it meant that no one is forced to use Objective-C anymore. Swift is a nice, modern language that makes sense intuitively. Unlike Objective-C, I learned Swift easily and naturally. I suspect other C# developers would learn it just as easily. Really the hardest part of C# is mastering concepts like closures (then lambdas come easily) rather that syntax details. Once you understand the concepts the syntax is trivial. Swift is hugely important in terms of development platforms. Swift means one of Xamarin’s biggest benefits, the right to not use Objective-C, is now already provided by Apple.

Stability

After using Xamarin for an extended time it becomes clear the level of quality and stability is significantly below that of Apple’s or Google’s development tools (I would rate Microsoft’s tooling above everyone else’s).

In Xamarin there are bugs, inconsistencies, and limitations that you will come across frequently. No doubt competitors have these problems, but the problem with Xamarin is how often they impact your work which in my experience is every ~2.5 days on average. This subjective formula implies after few months of working on a Xamarin project of significant complexity you will have dealt with a few dozen issues specific to the tooling. I stopped counting mine at about a dozen. Of course this is just a heuristic specific to me and my projects. However, on Apple or Microsoft tooled projects my numbers are an order of magnitude lower. On the contrary it is relatively rare that I find a bug in Visual Studio. In Xcode it’s not super common but not unusual. In Xamarin Studio it’s to the point it significantly impacts productivity.

To provide some sample data, I encountered all of these known Xamarin issues without trying. The coup de grâce was the last one, which actually caused data corruption in files and cost quite a bit of time to recover from:

Other Points to Consider

Brief points that may affect productivity depending on the circumstances:

There is no TFS support on Mac in Xamarin Studio. Accessing TFS requires downloading other clients like Eclipse, or running Visual Studio in a virtual machine.

Don’t be misled by the checkbox that Xamarin Studio has UX designers. They are limited in functionality and Xcode and Android Studio are still required. For example, RecyclerView, a primary Android control is not supported. There are important limitations on iOS as well. The iOS designer became available on Windows with Xamarin 3.0 for Visual Studio in May 2014.

Xamarin Studio works differently from the Xamarin Visual Studio plug-in. If everyone on your team does not use the same environment, then expect to take some time talking things out. For example, the project file serialization is different between the two, which can confuse source control.

The edit/build/debug cycle is much slower than working with Apple or Google tools alone. This will depend on your personal cadence, but since I like to iterate a lot this made me feel like I was waiting on the computer too much. Doing a build (not build all) with an empty Xamarin iOS project takes ~20 seconds. This is a long time to build an empty project, even on a 2011 MacBook Pro (Core i7, 16GB RAM, SSD hard drive). By comparison the same system builds an Xcode project with a dozen Swift code files in ~2.5 seconds.

Consider Xamarin Forms a work in progress. It can be useful if you want to crank out business apps that no one expects users to love, but no one will win an Apple Design Award using Xamarin Forms.

The list of limitations is long. First, not having any designer at all is pretty serious for a UI platform. It's not compatible with Microsoft XAML so this means all of the tooling that exists for it can’t be used right off the bat. It also has feature limitations. For example in XAML or HTML, we simply add an attribute to get hardware accelerated shader effects. This is not possible in Forms.

It’s not that you can't develop apps with it, but it's more of a lowest common denominator approach to UX. Essentially it is not well suited to non-trivial, arbitrarily designed UX. In talking to developers at Xamarin they seemed to agree but that was not an official company statement.

If you are a developer, you probably use Stack Overflow…a lot. When cutting and pasting useful bits of code often there is no Xamarin version and you have to “port” the samples and tutorials found online. The Xamarin community has grown large, but the amount of community content out there is not even close to that supporting the primary vendors.

It costs money. Comparing productivity of Xcode to Xamarin Studio is one thing, but remember you have to pay for a subscription to get the most out of Xamarin. The prices for the dev tools, not including services, can be found on their site. The price for the entire suite of Xamarin tools and services can run about $4,000 per year, per developer. However as with Microsoft the prices change a lot and can vary between customers.

Conclusion

The biggest arguments I hear for Xamarin are about the benefits it offers. Indeed, Xamarin has many benefits including a cross platform language for native apps and a suite of products and services that fit nicely with their tools. Xamarin can produce top tier apps (although not with Forms) that will go in the app store and look as good as anything out there. This is all true and good.

However, what really matters is the net gain in productivity after all points are considered. I believe the current value of Xamarin to .NET developers is oversold. Much of .NET doesn’t apply to mobile. With Swift there is no longer a need to use Objective-C with Apple’s tools. Java is outdated but trivial for C# developers to understand.

The stability of Xamarin is a real problem. That alone is enough to disqualify it in choosing a new platform. If I recall correctly the last dev tool that actually corrupted my files was Borland Turbo C.

Most importantly, the problems Xamarin solves are not the hardest ones in mobile development. They are solving problems on the wrong side of the 80/20 rule based on what’s difficult in mobile today. I still cannot recommend Xamarin at this time, but as ever remain open to reevaluating as they progress.

Testing Notes

For this review most of my time with Xamarin Studio was with version 5.71 (build 661-17). Hardware used was a 2011 MacBook Pro (Core i7, 16GB RAM, 1TB Samsung 850 SSD hard drive). For the Xamarin plug-in Visual Studio 2013 was used under VMWare Fusion 7.1.1, allocated with 4GB RAM and 2 CPU cores. Benchmarking was not done in a VM and only reflects Xamarin Studio.

Comments

Comments are welcome but those without verifiable email addresses will be deleted to reduce spam and trolling. Thank you.

Changelog

7/15 - Update to reflect designer for iOS became available on Windows with Xamarin 3.0 for VS.

January 21, 2015

When building an Android app, how should you choose the minimum Android version? This choice determines the oldest version of Android that your app can be installed on. For example, if you choose a minimum version of 4.1, then none of your potential customers with Android version 4.0 or lower can use your app.

At first glance the answer may seem obvious. More potential users is good so all versions should be supported. However, this is a naive viewpoint as your project will be impacted in other ways.

Active devices January 7th 2015 as measured by the Google Play Store

Generally speaking, the more versions an app supports the more expensive the development will be. One reason for this is that there are more moving parts. All APIs used must be level checked and if an API is not available, it may require creating work arounds or changing which components are used. Google does provide a pretty good backward compatibility layer but it’s not comprehensive.

QA is also impacted with more OS versions to test, more devices to test, and more bugs to report. Then developers have to fix those additional bugs, which may only occur in obscure situations or edge cases. Development is already expensive so this is a significant impact. Since time is closely related to cost the other side of the coin is it can take longer to ship an app when supporting more versions.

User experience can also be affected by minimum version. One example of this is project butter which came in Android 4.1. Techradar explains, project butter “answered complaints that Android wasn't as smooth as it could be by making everything faster and more responsive. The effects were profound and brought Android a lot closer to the slickness found on Apple devices.”

Bluetooth low energy (aka Bluetooth 4.0, Bluetooth Smart) devices were not supported until Android 4.3. Android supported older versions of Bluetooth before this. However, BTLE is the standard being supported by almost all new companion devices: fitness bands, healthcare devices, watches, etc.

Finally, another factor on the development side is support for the Chrome engine (Blink) in web views, which was added in Android 4.4. Whenever HTML5/Javascript are used, this brings many benefits in terms of compatibility, features, and performance.

As for the best choice, it's hard argue for anything less than 4.1 (Jelly Bean, level 16) given that this reaches over 85% of the market already and this number is still growing. As for the brand new Android 5.0, even with miniscule market share this is actually a great choice when you have a captive audience, like an internal app at a company that is standardizing on new devices. Going 4.2 or higher is hard to justify as the user base quickly starts to approach 50% or less. Normally this would only be justifed if a specific feature was essential to the app and no workaround was available.

There are other factors in choosing one of the 21 API levels of Android, but hopefully you’ll agree this is not a one size fits all decision. Be sure to always check the latest Android version market share numbers. Also note the market share numbers here are cumulative to show the total user coverage you’ll get, while Google’s numbers apply to a particular version.

September 05, 2013

If you are a developer who hates JavaScript it’s most likely
due to ignorance, or because you value purity over pragmatism.

As of 2013 there are important reasons for developers to understand
the good things JavaScript has to offer.
But before diving in let’s make clear the ignorance premise is not an insult, and is not
implying certain people have less ability as software architects. All good developers intentionally place
themselves in a never-ending cycle of ignorance/discovery/learning/experience. On the contrary, if you have never felt ignorant
as a developer you’re probably not pushing the boundaries of your talent.

So on to the ignorance. The three most common reasons I believe some
developers still rail against JS are:

JavaScript Did Actually Suck in the Past

Functional Languages are Painful

Concern that Language X is More Elegant

JavaScript Did
Actually Suck in the Past

Lots of people first tried JS back when web sites first
started becoming interactive. Coding JS web
pages back then was indeed a nightmare.
The browser consistency alone would make you pull your hair out (before
JQuery helped normalize things). The
language itself also had much less functionality at that time. For example, there was no exception handling
and not even decent string handling. Oh,
and you didn’t mind not having a debugger right? I had lots of frustration with JavaScript
myself back then, but things have changed.

First off, the language is now based on standards and ECMAScript has been actively
making improvements to the language for the last 15 years. ECMAScript 6 and other standards like CommonJS
are making JS suitable for larger scale software development.

By chance, JavaScript is the only language to have native support for JSON, which has become one of the
most popular data formats for web services.

The tooling has vastly improved. There are first class developer tools
available in the browser and also for JS outside of the browser. Microsoft has made JS a first class citizen
for it’s the most strategic platform to build native mobile apps. There are many nice IDE’s to choose from like
WebStorm. Collaborative debugging and protyping is
excellent due to tools like Plunker and JSFiddle.

Perhaps most importantly, the ecosystem of frameworks,
libraries, and components available for JS in 2013 is incredibly rich. Ecosystem directly drives productivity.

Functional Languages
are Painful for People Experienced with Imperative Languages

This is a real problem because JavaScript looks very similar
to C based (imperative) languages but actually behaves very differently as a
functional language. Developers can
quickly feel an initial level of familiarity, and then get a jarring, bad taste
in their mouth when forced to retrain their basic expectations. It’s a cruel trick to be lured in with
comfortable curly braces and then be forced to learn what a closure is.

The key here is to not fall for the trick, and instead
simply read
a tiny bit on the differences between JavaScript and other languages. This won’t make you an instant functional
programming expert, but you’ll know exactly what to look out for and won’t be
burned by false expectations.

There are other comfort issues, such as static vs. dynamic
typing that may seem like a philosophical schism, but are actually more about
time in the saddle. After you’ve written
a certain number of lines of JS code the discomfort will simply disappear,
believe it or not.

Concern that Language
X is More Elegant

Being concerned about what is the absolute most elegant
programming language is valid and critically important for language
designers. If you’re not a
theoretician, you’re an engineer, and we know good engineering is the art of
compromise. This doesn’t mean
engineering isn’t or can’t be elegant.
It means we don’t think about the elegance of one component in a
vacuum. It’s our job to weigh many
factors and optimize for the big picture.

Is Dart a more
elegant language than JavaScript (not to pick on Google but Dart has received a
lot of positive press recently)? Maybe. Should I learn Dart in my spare time? Probably.
Should I use Dart for my next work project? Not necessarily.

Besides the advantage conferred by the massive JavaScript
ecosystem, you can’t underestimate the power of ubiquity. JS started as a browser scripting
language, and now it’s used in node.js to
drive some very large and scalable server applications. It’s also big in mobile app development where
it’s built-in as a hybrid app solution for Android and iOS, and a native
solution for Windows 8 mobile devices.

If nothing else, think of your return on investment as a
developer. Once you learn JavaScript
well, you have the option to use it for a wider range of problems than almost
any other language. A corollary to this
is you have more options to participate in work you really care about.

This is not a JavaScript
Love Fest

In the same spirit of why we shouldn’t hate JavaScript, we also
shouldn’t become too attached to it, or any other tool or technique. JS is useful for many scenarios and is relevant
to the world as of this moment. When (not
if) the world is different next year, we should neither hate or love it. We should just start asking the right
questions again as good engineers are supposed to do.

August 27, 2013

The best way to develop mobile apps may be to combine native and hybrid architectures

Amazon recently moved to provide direct support for HTML5 web apps in its app store. It makes you wonder why the benefits of web standards still aren’t pushing more apps away from tedious device specific UI development. One factor is that while Amazon is giving a boost to HTML5 mobile apps, Apple’s iOS (still with the largest app catalog by far) actually penalizes them. You can choose the speed that comes with native or the standards and portability that come with hybrid apps but not both.

But there is a way to get HTML5+good mobile app performance. What if we could combine the best aspects of native and hybrid apps by compiling Javascript into fast native code while retaining all the advantages of HTML5? This could be thought of as an accelerated hybrid mobile app.

Fixing the Right Problems

The biggest problem with native apps is the weak story around user interface development. For example, not much of the work can be cross platform. Developers have to be involved in tasks that should be able to be handed over to designers with no coding experience. Moreover, the incredible toolchain and ecosystem that exists around HTML5 and CSS3 cannot be exploited.

On the other hand, hybrid solutions like trigger.io and PhoneGap solve these user interface problems by embracing HTML5 and JavaScript, however JavaScript is not as fast as native code. Even worse, much worse in fact, is that Apple limits these solutions by removing many optimizations from UIWebView, the component that enables HTML5 rendering in iOS hybrid apps. The result is that CPU bound JavaScript in a hybrid app can be up to 300% slower compared to JavaScript in mobile Safari.

So developers are kind of damned if they do, damned if they don’t. The end result is significant but different flaws in both native and hybrid approaches.

The table below compares the strengths and weaknesses of different approaches to building mobile apps. The scoring details could be debated ad nauseam, but the point is to note the broad implications. Included for comparison is Xamarin, a native app solution that uses clever technology to allow C# and .NET to be compiled into native code.

some strengths and weaknesses of native and hybrid architectures

Accelerated Hybrid Mobile Apps

An accelerated hybrid mobile app is one that uses HTML5 for rendering and JavaScript that is statically compiled to native code. Typical hybrid apps do not compile to native code and use an interpreter to run JavaScript.

One of the columns in the chart above is Xamarin for HTML5 Mobile Apps. This is not a real product. It’s a hypothetical solution to show how existing technology could be used to create an accelerated hybrid mobile app. I might be the last person on earth Xamarin would ask to announce a real new product given that I recently critiqued their product. However, Xamarin is a good example of how a non-native programming language can be ahead of time compiled into native device code.

Compiling JavaScript

Compiling most JavaScript to native code could bypass the artificial performance limitations in UIWebView, and potentially increase performance on all mobile platforms. Once the JavaScript is compiled to native code the biggest remaining factor is rendering the HTML. This is not as fast as bare metal native UI widgets, but the interesting part is browser based rendering is continually getting faster as more and more browser display functionality becomes hardware accelerated. While the gap between HTML display rendering and native rendering may never go away, it is steadily shrinking.

Technologies like asm.js are also intended to speed up JavaScript but do so by restricting language features to make life easier for the interpreter and optimizer. However, as mentioned, many optimizations are turned off in UIWebView, making it questionable how much asm.js could actually help in a hybrid scenario.

Why hasn’t this been done already?

Certainly one reason this hasn’t already be done is the difficulty of statically compiling a dynamic language. For example, JavaScript requires no type declarations. When a compiler first sees a variable, it’s sometimes hard to tell even if a string operation or arithmetic will be needed during execution.

Another issue is JavaScript’s eval function that can run arbitrary code fragments passed to it. It can be hard to statically compile code when part of that code could come from something the user pastes into an input field at runtime.

One way to address these challenges is to constrain the problem space with respect to typing and eval functionality. Microsoft’s TypeScript shows how a superset of JavaScript can be used to provide more type information to the toolchain, while allowing annotations and compatibility with existing libraries. TypeScript is also attempting to be compatible with ECMAScript 6 which adds a non-trivial amount of sanity to JavaScript development in general. So one compromise might be to allow hybrid app code to be statically compiled for modules that use type annotations and that restrict use of eval to JSON input rather than allow arbitrary code execution.

When I mentioned this to Miguel de Icaza on Twitter he responded that he thought it would be possible but that the compiled Javascript might still not be fast enough. Not sure if he was comparing the prospect to 100% native code, but even to match the performance of mobile Safari could be a huge win (vs. UIWebView without optimizations).

To put into perspective the potential of modern Javascript, Microsoft is putting it forward as an equal alternative to .NET for building Modern UI apps on Windows 8 mobile devices. Google’s V8 engine is legendary for it’s performance. Asm.js has shown JavaScript done right can hold it’s own as a 3d gaming engine. These are all examples of Javascript only using an interpreter, albeit in concert with great run-time optimizers.

Bypassing some of the significant Javascript performance limitations on mobile devices, especially iOS, could end up vastly growing the class of apps that might be appropriate and practical for an HTML5 hybrid architecture.

May 30, 2013

Let me say right up front, I have a lot of respect for Xamarin as a company and for Miguel de Icaza as a developer and as a person. I like Microsoft, .NET, and C# and have used .NET since it’s release.

None of that withstanding, I don’t believe Xamarin to be the best choice for mobile development in most cases.

For development platforms the subtleties matter a lot. It’s not just about the problems solved but the problems created. Likewise it’s not just about the benefits for a team but the benefits of others working and integrating with that team. We should consider the size of the ecosystem and support communities and how productivity of designers and QA team members are affected. All of these factors combined with immediate developer productivity determine time to market, quality, and user experience.

Taken separately the reasons below would not necessarily lead me to this conclusion, but in totality they argue against standardizing on the Xamarin toolchain.

App Overhead

Xamarin based apps have a built in overhead that makes them larger on average. This affects download time and storage used on a device. The minimum additional size is usually a few megabytes and can grow proportionately as the code uses more of the APIs. This is due to the way code from .NET assemblies is statically linked (as native code) into apps as the assemblies are referenced. On Android there is also an extra startup delay for apps for OS specific reasons. To Xamarin’s credit this overhead used to be much greater and the company has made great strides in reducing it. However, the impact on app users is still measureable.

Limited Sharing of UI Code Across iOS and Android

User Interface development is not portable between iOS and Android. This means APIs, event logic, widgets, and designers must be used and coded differently for each platform. There are a few exceptions to this for common, low level operations.

Xamarin would argue that trying to abstract UI APIs across very different platforms can create unnecessary complexity or lead to a poor user experience with an LCD (lowest common denominator) design. They have a point here. Titanium tries to do this partially, and the result has made many developers unhappy with the inconsistent or unpredictable results. HTML5 apps are more successful at pulling off this UI abstraction without forcing an LCD design, but they do not have the native performance of Xamarin.

UI problems can be some of the most time consuming aspects of developing mobile apps. Despite having a good justification, the important takeaway is that for many mobile UI problems, Xamarin will not save developers or designers time.

Limited Sharing of Code Outside of Xamarin

Xamarin does not allow creation of reusable components or modules outside of it’s own environment. For example, code written in Xamarin cannot be used in native or HTML5 apps. This means any code developed by a team using Xamarin cannot be shared or reused with teams using any other tooling for iOS and Android. How much this matters depends on the situation, but the problem with development is we can’t predict all of our situations. So it’s an uncomfortable limitation to have right out of the gate.

Ecosystem and Community

This is something that is not really Xamarin’s fault. What company has a mobile ecosystem that matches Apple, Google, or HTML5? However, it matters. When developers are 10 times more likely to find results when searching the web about an issue, it directly impacts productivity. The ecosystem of available support, services, and 3rd party components, and related tooling is, and will continue to be, significantly smaller than for native or HTML5 based apps.

Xamarin introduces it’s own set of bugs that affect product quality and developer productivity. The problem is not that Xamarin has a bad product, but that adding any large or complex system to the app toolchain comes with problems and bugs that do not exist in native apps.

Yes, all software has bugs. The point is when you measure the advantage of adding new tools; the disadvantage of new problems must be factored in.

Summary

In the end we have to try and quantify the benefits of a development abstraction like Xamarin over other abstractions, or over native development. Is C# better than Objective-C? Yes, by far in my opinion, but that’s only one factor. When you add everything up it tips the scales away from Xamarin in favor of other approaches to mobile development. As of 2013 (this stuff can change quickly) I tend to choose a native code solution or an HTML5/Cordova solution. I like both for different reasons and will try to explain some of the decision factors in another article.

February 07, 2013

AngularJS is the highest trending JS MVC Framework right now with lots of people picking it up. However as elegant as angular is you have to come to terms with what all the braces mean and when to use them. So finish the angular starter tutorial and then ask your self if this question:

No braces are used for directives
accepting a single value argument. An
example is data binding like this: ng-model=”dataItem”

Single braces are used for
directives accepting an object parameter (more than one value). In this case the single braces are just
defining a JSON object. An example is
using ng-class like this:
ng-class="{ boldCss: true, blueCss:true }"

Double braces are used to represent
an AngularJS expression. An expression
can be used by itself like this:

<div>{{ dataItem.name
}}<div> (evaluates
to someone’s name)

<div>{{ dataItem.name ==
“Jim” }}<div> (evaluates to true or
false)

Bonus points #1:

What’s the difference between these
two inputs? Both start out displaying
someone’s name.

<input value="{{
dataItem.name }}" />

<div>{{ dataItem.name
}}</div>

<input
ng-model="dataItem.name" />

<div>{{ dataItem.name
}}</div>

In the first example typing in the
input field will not change the div tag below it. It’s using an angular expression that
evaluates to plain old string.

In this second example the
variable name dataItem is actually being passed as a parameter into
ng-model. This binds changes in the
input field and changes the variable in the div as you type.

Bonus points #2:

Above we said directives take
parameters with either no braces (single value) or single braces (JSON,
multi-value). However it’s still
possible to use a angular expression with double braces as part of a directive
argument.

So both of these are valid:

ng-class="{
boldCss: true, blueCss:true }"

ng-class="{
{{ dataString }} }"

The second form uses a controller
to assign $scope.dataString = “boldCss: true, blueCss:true”, making the
directive parameters equivalent after the expression is evaluated.

The last example is contrived but
is meant to point out that even though
directive parameters use no braces or single braces, they can still use
expressions to partially construct their parameters.

For example when comparing Javascript frameworks we can see that knockout.js has a bigger community, but angular.js is growing more quickly. angular.js has a bigger community and is growing more quickly than backbone.js.

The mass is the total number of posts and the momentum is a weighted average of growth over the last six months.

Mass and momentum are key factors to knowing which developer trends will turn into decisive shifts.

July 10, 2012

Many mobile apps could benefit from working without an Internet connection. Here, we take a look at how offline capabilities affect the decision of developing native apps vs. mobile web based apps.

Apps that continue to work while “offline” or “disconnected” have been important since laptops first became common. A classic example is a salesperson that wants to enter data while travelling, and then have that data automatically sync with a server when they get back to the office. Even with Wi-Fi and cellular broadband, there are many scenarios (airplanes, Wi-Fi only devices, remote areas) where people still need to work without a connection. So, when offline access is needed should we develop a native app or web app?

May 10, 2012

The only way to build a mobile tablet app for all versions of Windows 8 will be to use the new Metro application framework, and it’s much different than previous Microsoft platforms. Developing Metro apps for Windows 8 is a combination of leveraging your existing skill sets and learning concepts that are new to the platform.

Following are five things that make developing Metro apps new and different. Food for thought as you dive into new waters and create the next great app that will earn you fame and fortune.

1. Programming language now determines your presentation layer

Previously Windows developers could choose a programming language like C# or VB, and separately choose a presentation layer like WinForms or DirectX.

When developing Metro apps, if you choose C#, VB, or C++ you automatically buy in to XAML as the presentation layer. If you choose Javascript, your destiny is tied to HTML5 and CSS3. There is no mixing of C# and HTML5, and no mixing of Javascript and XAML.

This coupling of language and presentation increases the importance of making the right language decision for your project. Deciding which is better largely depends on what the priority is for your project.

Javascript and HTML5 are a great investment when you want to build skills that can be reused on widely diverse projects. For example Javascript can be used to build Metro apps, HTML pages, native apps for all mobile devices, and even server side systems like NodeJS.

C# and XAML have the advantage of a large number of developers already being experienced with the technology. My sense is that with respect to a Microsoft platform like Metro, more developers know how to animate with XAML than with CSS3. Not having to relearn the basics on a project with a tight schedule can be a lifesaver.

Choose your language strategically based on existing skill sets and what future projects you want to be ready for.

2. NoSQL has a new meaning

Metro apps are unique in that they do not have easy access to a SQL based relational data store. Most existing Microsoft platforms can directly use some flavor of SQL Server such as Express, Compact, or CE, but this is currently not the case in the Metro sandbox.

Even if you downloaded and integrated an open source database like SQLite, there may be problems getting your app approved because of security requirements. Most databases have not yet been designed to run within sandboxed environments.

So how do you manage data in a Metro app? Of course data can be written to the file system and manually managed, and there is also an interface to an ISAM data store (ESE, Jet Blue). However probably the most common approach will be to use one of the semi-structured data storage mechanisms.

Metro apps have access to IE10 local storage technologies such as IndexedDB, which is an emerging standard. It is also very simple to use a cookie style local storage mechanism for key-value pairs. Finally, it’s still possible to call web services that make use of SQL on a separate server, but that doesn’t help with local data storage.

So all is not lost, but this is definitely a different world for developers, plan your data management accordingly.

3. Background tasks work differently

Running code in the background has always had rules. One rule that has always been intuitive to most developers is that once you start a background process it will continue to run until you stop it. This is no longer true.

With Metro, apps that are in the background do not automatically continue to run. Instead they are suspended until the user brings them to the foreground. By default only the foreground Metro app will be running and taking CPU resources at any given time. This is not a limitation; it’s by design and is a new model for app behavior on Windows. The idea is to maximize responsiveness for the user, and to conserve resources for mobile devices.

If this all sounds familiar it’s very similar to the way iOS works. When Apple added multitasking to the iPhone, it only allowed for background tasks to run in very specific scenarios, and so it is with Metro apps on Windows 8. Metro apps can request to run in the background for audio playback, data transfer, and notifications.

This new model is primarily motivated by mobile scenarios, however it is also the model for Metro apps on the desktop.

4. Don’t expect to have all of .NET’s functionality

We’ve come to rely on the greatness of .NET, but in Windows 7 the .NET framework was built using the entire Win32 API. With Metro, everything is built (including .NET libraries) on the new WinRT API. The bottom line is that .NET functionality for Metro will be a subset of all that is available with the full framework.

For example, is WCF supported for Metro apps? Yes and no. The core client scenarios all work, but the WS* specifications like WS-Security are not supported. The MTOM binary attachment encoding is not supported.

The good news is Microsoft has chosen the subsets carefully to maximize what is possible. It’s just a good idea to double check what’s supported if you have specific needs.

5. The new UX is not just new controls

Previously new versions of Windows added new controls (widgets), but the core idioms stayed the same. Windows 1.0 (released in 1985) and Windows 7 both have menu bars, captions, and resizable app windows. Windows 8 Metro apps have none of these. Even the Metro-ish UX on Windows Phone 7 is different, it has things like the panorama control while Windows 8 does not. Our cheese has been moved.

Because of this our job description now includes learning about the new UX idioms in Metro so that we can know when they make sense for our apps. Some of these include the AppBar, Semantic Zoom, Partial Page Docking, and Charms. There is a dedicated MSDN area that covers all of these here: http://msdn.microsoft.com/en-us/library/windows/apps/hh779072.aspx.

You probably don’t need all of these new features in your first Metro app. However if you don’t take advantage of the ones that are appropriate it could make for a less than perfect fit with Windows 8.

Onward and upward

Windows 8 is not just about technology changes for change sake. All of the items above are part of a bigger picture to enable better apps and faster development. Visual Studio 11 is the primary tooling for Metro development, and fortunately it retains the title as the best development platform on the planet. Overall Metro is calling us to create the next killer Mobile apps.