You MUST be Cross Platform

Visual Studio Magazine just posted on their site that Android will ship in One Billion devices in 2014.  The article is based on the following report from Gartner.  The key takeaway is that we no longer live in a "Windows World."  There are devices of all type that users are using.  As a result, developers must be knowledgeable on these devices and be able to develop for these platforms.  I would suggest subscribing to our VSM monthly column on "Cross Platform C#."  Not only does Android have a large, ok huge, set of numbers, but iOS has a large number of units shipped.  At the same time, one can not forget Windows.  What about the Web?  How can you support all of these platforms?  Tune into our Cross Platform column and you will see. 

PS.  I have a cross platform article coming up in Visual Studio Magazine that is really big.  I think you will like it.

PSS. Many thanks to Kurt Mackle for inspiring me on the graphic.

Mobile Web HTML5 Training with jQuery Mobile - January 28, 2014

Link: http://devproconnections.com/mobile-web-development-featuring-jquery-mobile?promo=WP3AM1

Mobile development is a hot item. Customers are buying iPhones, iPads, Android devices, and many other mobile computing devices at an ever increasing record pace. Devices based on iOS and Android are nearly 80 percent of the marketplace. RIM continues to be dominant in the business area across the world. Nokia's growth with Windows Phone will grow on a worldwide basis.

At the same time, clearly web development is a tremendous driver of applications, both on the public Internet and on private networks. How can developers target these various mobile platforms with web technologies? Developers can write web applications that take advantage of each mobile platform, but that is a lot of work.

Into this space, the jQuery Mobile framework was developed. This eLearning series will provide an overview of mobile web development with jQuery Mobile, a detailed look at what the jQuery Mobile framework provides for us, how we can customize jQuery Mobile, and how we can use jQuery Mobile inside of ASP.NET. 

Session 1: Mobile Web Development - 11am ET

Are you wondering what web developers can do in the mobile world? This session will focus on:

• What web developers need to know about the idiosyncrasies of mobile development
• Tools to use for mobile development
  • ASP.NET development options: Webforms v MVC v Web Pages
  • Web browsers
• Javascript language features useful for mobile web development
• Integrating with the phone
• Meta tags to improve the user experience

Session 2: jQuery Mobile - 1pm ET

You are probably aware of the jQuery javascript library. This seminar will introduce jQuery Mobile, a library that will make the development of web applications for mobile devices easy. We’ll look at the basics of jQuery Mobile, including

• Page Setup
• Toolbars
• Navigation
• Integrating basic controls with jQuery Mobile
  • Buttons
  • List Components
  • Form/UI Components
• Basic options for jQuery Mobile
• AJAX operations with the ListView 

Session 3: jQuery Mobile Advanced with ASP.NET - 3pm ET

jQuery Mobile allows developers to create an application with a mobile-specific user interface. There are many options to optimize and change the default behavior of jQuery Mobile, as well as how ASP.NET developers can easily integrate with jQuery Mobile. This session will look at:

• Creating a Template for ASP.NET developers
• Creating a custom theme
• Build one ASP.NET Page with jQM Themes to target multiple devices
• Offline operation and the application manifest
• Plug-ins and optimizations for tablets
• jQM Events

#5 Article in Visual Studio Magazine for 2013

Greg Shackles and I write the Cross Platform in C# column for Visual Studio Magazine.  This column started in January 2012 with an email from Keith Ward regarding my interest in a monthly column on what was then called Mono for Android.  He had seen several of my articles already (I'm shocked he was interested because he HAD seen the articles) and had seen a good number of page views associated with them.  First off, I was pleasantly surprised.  It is an honor to have anyone think highly enough to want a guy that failed english in high school to want to write a column.  Secondly, I had to think on this for a while.  My friend Doug Turnure had asked me about joining a secret project at Microsoft to pump up the number of Windows 8 apps at launch.  Thankfully, that did not happen, at least they did not want me on it.  I never recieved any more info on it, so I just considered that they had enough people and weren't look for any more. 

Thinking through the specifics of the column, I knew that I could not do everything.  There would be times that I was off doing something and would not be available.  I spoke to a few people, but Greg Shackles expressed the most interest.  Greg was on board.  In April, 2012, the first article was published.  By the fall of 2012, I knew that the column needed to change to include MonoTouch for iOS.  At the time, MT only supported MonoDevelop.  We knew that the iOS Plugin for Visual Studio was coming (even though it was NDA at the time).  About 10 days before the announcement of Xamarin 2.0 (with the iOS Plugin for VS, the name changes, and the product enhancements), we got the confirmation that the actual product would ship in late February.  Unfortunately, due to things that our outside of our control, an article on the Xamarin.iOS Plugin for Visual Studio was not actually posted until April, 2013.  It is that article that is the #5 article on the VSM web site in 2013.  I assume that this is just for articles posted in 2013, but don't really know all of the specifics.

There are several groups that I would like to thank for this:

• Keith Ward for the initial interest in the column.
• The editors that have to read through my material.  They make Greg and I look good.
• Greg Shackles for being my co-author on the column.  Greg and I work from a 2:1 split approximately on articles.  Without Greg, I would not be able to do this continually and the column would probably not exist.
• The folks at Xamarin.  I know a good number of people there.  I am friends with many of them.  The reason I am friends with them is not because I somehow knew them before.  I am friends with them because based on my background, they are solving the client's problems in a way that makes sense.  These guys listen to the client and solve the problems that they can.  That is what I want in a development tools partner!  I especially want to thank Joseph Hill.  He has always been helpful to me.  He really has gone above and beyond what I would expect.

Having said all of this:

• Here are the top 10 articles on the VSM web site for 2013. 
• Here is the article on Xamarin.iOS.

Once again, thank you for your help in 2013.  I hope that Greg and I can continue to earn your trust in 2014.

Take Advantage of iOS 7's New Features

Link: http://visualstudiomagazine.com/articles/2013/12/01/take-advantage-of-ios-7s-new-features.aspx

On Sept. 18, Apple formally began distributing iOS 7 to users. Within one month, iOS 7 was running on 69.3 percent of iOS devices, according to app monitoring company Fiksu. On Sept. 20, Apple began selling the new iPhone 5s and 5c. While excitement surrounds the release of any new operating system, Apple creates additional excitement for developers, due to the rapid uptake of each new version of iOS.

With iOS 7, Apple has provided a number of new features worth getting to know. Since this column is called "Cross-Platform C#," the question of the length of time it takes Xamarin to provide support for new features comes up frequently. There's good news on that front, because Xamarin has provided same-day support for the latest version of iOS. This article will take a look at some of these new iOS features

Building Native User Interfaces is the Right Way To Build Cross Platform Style Apps

I hear a few developers getting down on Xamarin because they are required to:

1. Create different projects for the various mobile platforms that they want to target.
2. Learn the particulars of a given platform, or as I term them, the “isms.”

Interestingly, these are not negatives to going with a Xamarin style cross platform solution; these are most definitely positives in their style of solution.  Wait, how can this be?  Developers have been training to think that sharing as much code as possible (including the UI) is a good thing.  In this blog post, I’ll try to explain the issues of cross platform development, what users want (yes, I do tend to do crazy things like talk to users), the problems in cross platform development, and finally why presenting the user with a native solution is just plain better than a mobile web based solution.
What Users Want
Users want solutions to their problems.  It is pretty simple.  Solve a user problem, don’t create more problems, help the business cut costs, be a net positive in an organization, add value.  These are fairly simple items.  Unfortunately, a number of developers don’t quite understand this.  Many developers just want to write code, “But Wally, I just want to write code.  It is why I got into this job.”  Or, you may be a part of some IT group where you are seen as a cost center.  Whatever your position within the organization, getting out and talking to users has resulted in my finding the following items:

• Users want applications that look just like all of the other applications on their platform.  Giving a user an application that looks like a Windows application while running on the Mac can result in some interesting feedback.
• Users want applications that act just like all of their other applications on their platform.

Basically, this means that an application must call platform specific APIs and must do so fairly close to the application logic.  By doing this, the application will look, smell, and taste just like every other application on a platform.  An iOS application will look like iOS.  An Android application will look like Android.

History’s Lessons
I’ve done a little bit with cross platform tools in the past.  Early on in my career when I worked at The Cola-Cola Company, there was some involvement with:

• PowerBuilder for the Mac.
• Visual C++ for the Mac.  While this never shipped, it existed to the point of us getting an NDA. It may have only existed to create FUD.

After talking to users and working through some options, this is where I learned how important it is for apps to look like the other apps that users use.
A few years later, Java came on the scene.  Unfortunately, Java ran into several issues:

• Java apps didn’t look like other apps on a given platform.  Swing came out later on and it provides a much more platform specific look/feel to it.
• Early on, Java wasn't very fast, let's just be honest about it.
• Java had small incompatibility issues between platforms.  Its promise of “Write Once Run Anywhere” had become “Write Once Debug Everywhere.”
• There was no guarantee that the Java framework was on a device.  Expecting a user to install the framework was no realistic.

As we know from history, Java, while being widely used in the development area, never saw a great uptake in the consumer space.

Not long after Java, Microsoft .NET came on the scene.  Unfortunately Microsoft .NET never took over outside of the Windows space.  Its cross platform capabilities never really came about.

Now, I am sure that there is someone jumping up and down widely waving their arms and screaming “HTML5, HTML5 will save us.”  Ultimately, HTML was designed for the display of documents and content to users.  Back in the mid 1990s, the reason why HTML took off was due to:

• Deploying most custom apps within a business was a nightmare.  Deploying apps to a web browser was much easier.  No dll hell, no installation programs to run, life was much better.  Imaging trying to do this outside of a company without a support staff?
• Early web sites were much more about marketing.  Very few public web sites back then were about applications.  It took a few years for web sites to take on more of an application feel to them and now many have an app feel to them.

While there have been many attempts to give an HTML file device like capabilities, these capabilities always seem to be lacking in something.  Mobile web apps with HTML5 are no different.  There is always something that they can't do.  For example, I’m working with some folks that are trying their hardest to get out of phonegap due to limitations of the platform.  Now, I’m not going into the specifics on that, merely that there are issues and these aren’t the only folks with them.

Just so that we're clear on things, HTML web apps work out really well in a lot of situations.  I've written a lot of them.  I'm a Microsoft ASP.NET MVP (well at least for a little while longer).  I continue to work on several.  They just aren't the go to platform for mobile.

Developer Productivity
One of the big arguments I hear regarding using a single set of source files to build an application, is that this is more efficient for developers.  I agree, this is absolutely true.  Unfortunately, user productivity is 10-100x more valuable than developer productivity.  Increasing user productivity by a small percent multiplied by the number of users results in a greater increase in productivity.

But, But, But HTML5……While I will argue the point about user productivity increases dwarfing developer productivity, I’m not going to be unrealistic regarding what is happening in the marketplace.  There are some places where having a single set of course files is valuable.  These typically are:

• The client only has a few shillings to pay for a solution.  The cost of an HTML5 mobile web solution is lower, let’s be honest about it.  You can get your neighbor’s kid to do the work.  This has a tendency to drive down the price. I’m just sayin’.
• If your IT department is considered to be a cost center.  Build something, deploy it to a bunch of platforms, later, rinse, repeat.

Unfortunately, the problem with HTML5 is that you just can’t integrate with the platform as well as the client wants to.  Because HTML5 fits in a low cost area doesn’t mean that it fits everywhere.  A secondary issue is that as a client wants an application to grow and provide more functionality, a continually higher cost must be paid for this functionality.  Eventually, you will reach a point where the cost of a mobile web html5 solution meets and passes the cost of native mobile apps and still not providing the native experience.  What happens with that mobile web html5 solution?  It becomes a sunk cost.  You will end up throwing it away and pretty much starting over on the client side..

PhoneGap Will Save Us
Sorry folks, but PhoneGap isn’t the be all and end all.  PhoneGap is a container that embeds HTML, JS, and CSS content.  It allows access to device APIs in a cross platform way.  Unfortunately, you get access to content via a web view, so you are limited to what can be provided in the web view.  
I almost went down the PhoneGap route back in 2009, until I read the first announcement of MonoTouch (now Xamarin.iOS).

But I do Java, ObjectiveC, or something else
Ok, great.  There are tools for Java that allow you to write for iOS.  Unfortunately, that won’t help you with WP.  The same is true with ObjectiveC.

Why XamarinWhen Xamarin.iOS was first announced, I knew that was where I needed to be.  It provides:

• Access to the native APIs directly from an application via the bindings contained in the various namespaces in Xamarin’s products.  If your application isn’t calling native APIs, your application will most likely have small things that are out of place in some way.  This immediately solved the problem that I had 20 years ago.
• Access to the .NET framework that I already know. I don’t have to go learn ObjectiveC, Java, Xcode, Eclipse, or Android Studio.  I can use Visual Studio to develop apps for multiple platforms. I don’t have to go learn a new IDE.
• Sharing non-device specific code between iOS, Android, WP, and other .NET platforms.
• Learning the UI specifics and platform-isms allows you to build an application that integrates with the platform better than a shared application.

I have heard the chimes at midnight.  I have gone through the cross platform battles in the past.  The bottom line is that you have to create platform specific versions of your app.  I think that Xamarin is the right place for me.  I’ve learned my lesson. I’m calling native APIs with my language of choice, C#.

If you are interested in a discussion regarding Xamarin vs. Vendor Directed solutions, I suggest this discussion in the Xamarin forms:http://forums.xamarin.com/discussion/comment/36834  

Cross Platform with Visual Studio 2013 & Xamarin Meetup - Atlanta - December 11

I'll be at a Meetup in Atlanta on December 11, 2013.  I'll be talking about:

• What is cross platform?  What is meant by it?
• What are the options for cross platform?
• What is Xamarin/what do they provide?
• What can I do with Visual Studio 2013?
• What are PCLs/linked files?  How to share business logic?
• What about shared APIs?  What is Xamarin.Mobile?
• What about Data?

For more information, check out the meetup site.

Webinar on Cross Platform Development with MonoTouch for the iPhone and Mono for Android on Wednesday

The iPhone and Android are dominant in the marketplace. The two platforms currently have 85% of the smartphone marketplace and are continuing to grow that marketshare. Developers are being tasked with targeting these two platforms. In this session, we’ll take a high level look at how we can use c# and .NET knowledge to share code between iOS and and Android. We’ll look at linked files, using the Xamarin Mobile API, the challenges of running across platforms and frameworks, as well as other features of Visual Studio, Monotouch, MonoDevelop, and Mono for Android that allows us to write as much code that can run on both platforms.

Here is the registration link: https://www302.livemeeting.com/lrs/8001676474/Registration.aspx?pageName=2w197495hzh0t56g