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:
Once again, thank you for your help in 2013. I hope that Greg and I can continue to earn your trust in 2014.
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
I hear a few developers getting down on Xamarin because they are required to:
- Create different projects for the various mobile platforms that they want to target.
- Learn the particulars of a given platform, or as I term them, the “isms.”
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
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
- Users want applications that act just like all of their other applications on their platform.
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.
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
- PowerBuilder for the Mac.
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.
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
A few years later, Java came on the scene. Unfortunately, Java ran into several issues:
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.
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.
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:
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.
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
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
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……
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:
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
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
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
When Xamarin.iOS was first announced, I knew that was where I needed to be. It provides:
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.
the UI specifics and platform-isms allows you to build an application
that integrates with the platform better than a shared application.
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
One of the great things about the .NET Framework is that Microsoft has worked long and hard to improve many features. Since the initial release of .NET 1.0, there has been support for threading via .NET threads as well as an application-level threadpool. This provided a great starting point when compared to Visual Basic 6 and classic ASP programming. The release of.NET 4 brought significant improvements in the area of threading, asynchronous operations and parallel operations. While the improvements made working with asynchronous operations easier, new problems were introduced, since many of these operations work based on callbacks. For example:
- How should a developer handle error checking?
- The program flow tends to be non-linear. Fixing bugs can be problematic.
- It is hard for a developer to get an understanding of what is happening within an application.
The release of .NET 4.5 (and C# 5.0), in the fall of 2012, was a blockbuster update with regards to asynchronous operations and threads. Microsoft has added C# language keywords to take this non-linear callback-based program flow and turn it into a much more linear flow. Recently, Xamarin has updated Xamarin.Android and Xamarin.iOS to support async.
This article will look at how Xamarin has implemented the .NET 4.5/C# 5 support into their Xamarin.iOS and Xamarin.Android productions. There are three general areas that I'll focus on:
- A general look at the asynchronous support in Xamarin's mobile products. This includes async, await, and the implications that this has for cross-platform code.
- The new HttpClient class that is provided in .NET 4.5/Mono 3.2.
- Xamarin's extensions for asynchronous operations for Android and iOS.
FYI: Be aware that sometimes the OpenWeatherMap API breaks, for no reason. I found this out after I shipped the article in.
I recently did an online webinar regarding the new iOS7 and Xamarin.
In it, I covered the basics of what is new in iOS7 along with what is
new in Xamarin's developer platform. Please take some time and view this webinar. The items that were covered include:
- What's new in iOS7.
- The XCode Design Surface.
- An example showing new iOS7 View Animations.
- What's new with Xamarin and async, await, and HttpClient.
- A demo of Razor Templating.
- The Xamarin.iOS Plugin for Visual Studio.
** The video only works in Windows. I don't control the content, so I have to go with what I am given. :-( **
In a previous article,
I looked at the HTML5 <video> tag and History object, two of the
many features that developers have started to implement to give users of
their apps new input controls, jQuery Mobile features, location and
mapping, and much more. In this article, I continue exploring HTML5
features with a look at Web Workers, which let you speed up your
client-side applications, and Indexed DB, a client-side data storage
mechanism that is the preferred storage approach going forward in HTML5.
(Before Indexed DB—also known as the Indexed Database API—work was
focused on a standard named WebSQL. That work was discontinued in the
fall of 2010. IndexedDB is the result of follow-on work to create a
standard for data storage in Web browsers.)
The APIs for HTML5 vary slightly across different versions of browsers
and different implementations. Because HTML5 is still in the
recommendation phase at the W3C, you should think of it as a draft at
this point. Because these APIs may change before they become a final
standard, I cover only the version of HTML5 implemented in Internet
Explorer 10. Every opportunity will be made to test the code across
other browsers to verify that it works.Url: http://msdn.microsoft.com/en-us/magazine/dn423698.as
Images taken with the camera are rather large in the iPhone. How do you shrink them down? I need to shrink them because I am going to send them to a web service and I want to spend as little time as possible in the upload process. While I am not sure that this is the best code, it seems to be working for me. I want to put this out for sharing and if you have a suggestion on how to make it better, please let me know.
UIImage img = UIImage.FromFile (fileName);
var width = img.Size.Width;
var height = img.Size.Height;
var newWidth = defaultImageWidth;
var newHeigth = height * newWidth / width; // I always hope I get this scaling thing right. #crossedfingers
UIGraphics.BeginImageContext (new SizeF (newWidth, newHeigth));
img.Draw (new RectangleF (0, 0, newWidth, newHeigth));
img = UIGraphics.GetImageFromCurrentImageContext();
Who hasn’t started looking at the mobile Web and HTML5—features like the
viewport, new HTML5 controls, geolocation and many others that are part
of smartphones, tablets and advanced browsers? With these features,
developers have started to provide users with fairly common, new input
controls; jQuery Mobile features; location and mapping; and much more.
In this article, I describe two features that you might not be familiar
with: the <video> tag and Web history. The <video> tag lets
you display video without the need for plug-ins like Flash. Web history
allows users to use the Back button to return to the previous page in an
AJAX application.Url: http://msdn.microsoft.com/en-us/magazine/dn423697.aspx