Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

June 05 2012

Developing cross-platform mobile apps with C#

Building a mobile app that runs on more than one platform, with minimal code changes, is a technical Holy Grail. The HTML5 stack (using CSS and JavaScript, among other standards) and Java are two solutions. Another is Microsoft's .NET plus C#, a combo that's been overlooked outside the Windows Phone 7 developer community despite its potential to create apps that can run natively on Android and iOS.

In the following interview, software engineer Greg Shackles (@gshackles) aims to expand the potential of this platform. Shackles is the author of "Mobile Development with C#" and maintains a blog focusing mainly on .NET and its related technologies.

We hear a lot about using C++ to build mobile apps, so why use C# — and the associated .NET?

Greg Shackles: There are various ways to share code across different platforms. Unfortunately, many approaches will abstract away the user interface from the developer in order to achieve a "write once, run anywhere" solution, making it easier to release an application quickly on many platforms. This sounds great, but often it will lead to a degraded user experience since the app won't look and feel native to that platform. The user experience is the most important thing to consider when designing an application.

Using C# and the Mono Tools allows the developer to share a large subset of an application's code across multiple platforms while still building a completely native user interface on top of it for each platform. Applications created with this approach will look and feel native because they're using the exact same APIs and toolkits exposed by the platform. In some cases, the Mono tools even help to clean up the platform APIs to make them easier to work with than those exposed by the native languages.

This approach allows developers to concentrate on solving business problems rather than having to manage multiple languages and reinvent the wheel every time they want to expand to a new platform. Going even further, the code that is shared across platforms isn't limited to mobile applications. It can go pretty much anywhere that C# and .NET are supported, such as ASP.NET, Silverlight, or WPF. Developers already familiar with these technologies can easily hit the ground running and start targeting these new platforms while reusing the skills they already have.

What else makes the .NET Framework well suited for mobile development?

Greg Shackles: C# and .NET are both very mature and powerful technologies. They have evolved over the years to provide support for things like asynchronous programming and memory management, and features like LINQ help make them great to work with as a developer.

For example, there is no garbage collector when writing iOS apps with Objective-C. That's a feature .NET developers are used to having. MonoTouch actually brings a garbage collector along with it, making it much easier to work with, without having to worry about manual memory management.

What are a few of the technical weaknesses of C# or .NET?

Greg Shackles: There aren't too many technical limitations, but whenever you place another layer between you and the native platform, some problems are unavoidable.

One example is that on iOS, you are not allowed to dynamically execute code at runtime, meaning that the standard .NET style of just-in-time compilation is not permitted and that aspects of .NET that rely on runtime code compilation are not possible, such as Reflection.Emit and the Dynamic Language Runtime. To get around this, MonoTouch compiles the application down to static code ahead of time. This particular limitation does not apply on Android, which does allow for just-in-time compilation.

For those who are already developing native apps for Android or iOS, what benefits would they gain from using C#?

Greg Shackles: For developers who have already built their apps in Java in Objective-C, the case for switching to a new set of tools definitely becomes more difficult to make. The benefits they would get from making such a move would largely be in the ability to share code across all of the platforms rather than have to rewrite it in a different language every time. Both MonoTouch and Mono for Android offer the ability to interact with code written in Objective-C and Java, so code already written in those languages could still be leveraged.

What kind of cross-platform mobile apps are easy or best to make under C#?

Greg Shackles: I don't think there's any particular category of app that's obviously more difficult to write in C#. For extremely simple applications that don't have much logic, it becomes more of a decision of preference for the developer rather than a strategic advantage. In reality, not many applications fall into this category. A majority of applications will need to perform tasks like accessing the Internet or saving to a database, and that is where it becomes beneficial to be able to write that code once and share it across all platforms. Personally, I find C# to be a much nicer language to work with than Objective-C and Java, so that alone becomes an advantage of using it.

.NET is native on Windows Phone 7, but it's not on Android or iOS without the use of MonoTouch or Mono. What are the performance issues or differences across these mobile platforms when you're developing for all three at once using C# through .NET and its unofficial variants?

Greg Shackles: The addition of another layer between you and the platform will have its consequences, but by and large, it's not something you'll notice or need to worry about as a developer. Since MonoTouch applications are run through its ahead-of-time compiler, their performance is already highly optimized. Mono for Android applications include their own instance of the Mono runtime that .NET code is run against and includes an intelligent garbage collector that is optimized for managing objects across the different runtimes. In general, you won't be able to see any difference in performance between an app written in C# and one that is not.

One other common concern is the size of the application, since the .NET Framework is not known for being minimal. Both Mono for Android and MonoTouch ship with a tool called a linker that is included as part of the build process. The linker is a static analysis tool that scans the compiled assemblies in the application and actually strips out any pieces of the framework that are not referenced. As a result, your application will only ship with precisely the pieces of the .NET Framework that you actually use, which drastically cuts down the size of the application. With each release, the Mono team seems to find new ways to optimize the linking process, so this size overhead continues to dwindle down further, even though it is already rather minimal.

This interview was edited and condensed.

Mobile Development with C# — This hands-on guide shows you how to reuse one codebase across iOS, Android, and Windows Phone by combining the business logic layer of your C# app with separate, fully native UIs.

Related:

April 26 2012

Commerce Weekly: Mobile commerce is on the rise globally

Here are a few of the stories that caught my eye in the commerce space this week.

Survey shows global rise in consumer desire for mobile commerce

TNS Global's recent Mobile Life Survey, which surveyed the mobile habits of 48,000 people in 58 countries, shows that global interest in mobile commerce is on the rise. The screenshot of the survey's interactive results map below illustrates levels of interest for different commerce features — in this case mobile wallets:.

Mobile Life Survey screenshot
A screenshot of the TNS Global Mobile Life Survey results map. See the interactive version.

In a post for stuff.co.nz, William Mace took a deeper look at the survey results concerning the mobile commerce status in New Zealand. The results showed a bright future for mobile commerce, especially in the feature areas of mobile wallet and mobile banking. Mace reports:

"TNS New Zealand director David Thomas said New Zealanders surveyed liked the convenience of 'mobile wallets' — essentially using a smartphone to pay for goods and services — and placed the greatest trust in banks to provide such a service."

Thomas explained to Mace that technology and infrastructure are speed bumps to mobile wallets, much like here in the U.S. He said, "Mobile wallets generally require smartphones and generally a near-field communication chip in your phone which is still relatively unusual. The technology has driven mobile banking to come first but we can see with the developments of people like PayMark, Telecom and Vodafone are talking about we can see that the infrastructure for mobile wallets will come soon."

X.commerce harnesses the technologies of eBay, PayPal and Magento to create the first end-to-end multi-channel commerce technology platform. Our vision is to enable merchants of every size, service providers and developers to thrive in a marketplace where in-store, online, mobile and social selling are all mission critical to business success. Learn more at x.com.

EU investigates possible mobile wallet monopoly

Mobile wallet news wasn't all positive across the globe this week. In the U.K., where mobile retail is up 254% from last year and up 300% year over year for the first quarter of 2012, the European Union might become an additional speed bump to mobile wallets.

According to a report at Internet Retailer, the EU is looking into three U.K. telecommunications companies — Telefónica, Vodafone and Everything Everywhere — that announced a mobile wallet plan last June called Project Oscar. Plans were submitted in March. A press release from the EU explained that the problem lies in the potential monopoly:

"The Commission's initial investigation revealed that the joint venture and its three parent companies may have the technical and commercial ability and incentive to block future competitors from offering their own mobile wallet services to customers in the UK, or to degrade the quality of these competing mobile wallets so that they become less attractive."

According to the release, the commission has until the end of August to make a final decision.

Boston rail commuters get a paper ticket alternative

Consumers can buy a cup of coffee with an app (even in the drive-thru!) or a hammer with a phone number, and several companies offer local smartphone payment options for breakfast, lunch or dinner. By this fall, commuters in the Boston area can add "buying commuter rail tickets with an app" to that list. According to a post at Boston.com, the MBTA signed an agreement Friday that will allow "[c]ustomers with an iPhone, Android, or BlackBerry who download the free app [to] buy one-way, round trip, 10-ride, and monthly tickets and passes using debit or credit cards." The app will have a scannable QR code. The post describes how it will work:

"Riders will activate their pass when the conductor approaches, and it will generate a one-time image lasting long enough to be checked on the trip but not reused on another ride ... Though the mobile tickets will contain QR codes, the T will not initially equip all conductors with hand-held scanners, using them only for spot checks. Instead, digital watermarks, such as changing colors and animation, will help deter fraud while allowing passes to be verified at a glance."

The post pointed out that similar mobile payment options are common in England, "but the T would be the first major US commuter rail to offer passengers an alternative to paper." MBTA officials also told Boston.com they will use the new app to gather more accurate ridership data.

Related:

January 25 2012

Four short links: 25 January 2012

  1. Mobile Overtaking Web -- provocatively packaged extrapolations of ComScore and similar numbers to conclude that Americans spend more time interacting with mobile apps than with web sites. I'm sure you could beat an iPhone developer to death with the error bars.
  2. Best Privacy Policy Ever -- satiric privacy policy from a Firefox plugin.
  3. The Time for Libraries is Now -- forceful presentation on the need for librarians (aka "information professionals") in an age of excess information.
  4. Google 2011 vs Microsoft 1995 (Nelson Minar) -- interesting analysis which prompted Andy Baio's comment Google will be in trouble if their strategy succeeds, or if it doesn't.

December 19 2011

Six API predictions for 2012

For businesses, APIs are clearly evolving from a nice-to-have to a must-have. Externalization of back-end functionality so that apps can interact with systems, not just people, has become critical.

As we move into 2012, several API trends are emerging.

Enterprise APIs becoming mainstream

I see a lot of discussion about Facebook, Twitter and other public APIs. However, the excitement of these public APIs hides the real revolution. Namely, enterprises of all sizes are API-enabling their back-end systems. This opens up the aperture of the use of back-end systems, not just through apps built by the enterprise, but also through apps built by partners and independent developers.

For example, several large telecom enterprises, like AT&T, are embracing APIs because, even with their abundant resources, they cannot match what the world outside the enterprise can do for them — build apps that, in the end, bring in more business. Today, I estimate that 10% of enterprises are doing APIs, and another 10% are considering it. In 2012, I predict that these percentages are more likely to be 30% and 80%, respectively, reflecting the pace at which APIs are going mainstream.

API-centric architectures will be different from portal-centric or SOA-centric architectures

Websites (portals) are for people integration. Service-orientated architectures (SOA) are for app-to-app integration. While both websites and SOA use back-end systems through "internal" APIs, the new API world focuses on integration with apps and developers, not with people (via portals) or processes (via SOA). There are three specific things that are different:

  1. Enterprises need to think outside-in as opposed to inside-out. In an outside-in model, one would start with easy consumption (read REST) of perhaps "chatty" APIs and then improve upon them. This is in contrast to thinking performance first and ease of use second.
  2. Enterprises have to be comfortable handling unpredictable demand and rapidly changing usage patterns as opposed to the more predictable patterns in the enterprise software environment.
  3. Enterprises will need to make websites and even some internal processes clients of the "new" API layer instead of having them continue to use back-end systems directly. In this way, APIs will become the de facto and default way of accessing the back-end systems. Also, increasingly, the API layer will be delivered through a cloud model to handle the more rapid and evolving provisioning requirements.

Data-centric APIs increasingly common

Siri and WolframAlpha are great examples of data-centric APIs. There is a huge market for data, and today it is mostly made available through custom feeds (for example, Dun & Bradstreet) or through a sea of xls/csv files on a website (for example, Data.gov). The former is a highly paid model, and the latter is free-for-all model. Clearly, a new model will — and already is — emerging in the middle. This is the model in which data is brokered by APIs and free and freemium models will co-exist. Expect to see more examples of enterprises for which data is the primary business and where using the data through apps is the new business model.

The first thing enterprises like this are doing is to API-enable their data. Now, RESTifying data is not easy, and there are as many schools of thought on how best to do it as there are data providers. However, I expect some combination of conventional and de facto standards, such as the Open Data Protocol (OData), to become increasingly common. I do not believe that the semantic web or the Resource Description Framework (RDF) model of data interchange is the answer. It goes against the grain of ease of use and adoption.

Many enterprises will implement APIs just to get analytics

A common theme in enterprise technologies is that a spend happens first in business automation and second in business optimization. The former enables bottom-line improvements; the latter enables top-line improvements. The API-adoption juggernaut is currently focused on business automation. However, as more and more traffic flows through the APIs, analytics on these APIs provides an increasingly better view of the performance of the enterprise, thereby benefiting IT and business optimizations. If this trend continues and if business optimization is the ultimate goal, a logical conclusion is that APIs become a means to the end for optimization. Therefore, all enterprises focused on business optimization must implement APIs so they have one "choke point" from which a lot of business optimization analytics can derive data.

APIs optimized for the mobile developer

Mobile apps are becoming recognized as the primary driver for API development and adoption. There are many different devices, and each has its own requirements. Most mobile apps have been developed for iPhone (iOS) and Android devices, but the next big trend is HTML5/JavaScript for apps that can run on any device.

Mobile devices in general need to receive less data in API responses and should not have to make repeated API calls to perform simple tasks. Inefficient APIs make things worse for the app developer and the API provider because problems are multiplied by mobile demand patterns (many small API requests) and concurrency (the sheer number of devices hitting the API at once). In 2012, many providers will realize they need to:

  • Let developers filter the size and content of the API response before it's returned to the app.
  • Give developers the right format for their app environment — plist for iOS and JSONP for HTML5/JavaScript.

OAuth 2.0 as the default security model

Apps are the new intermediaries in the digital world, enabling buyers and sellers to meet in ways that make the most sense. In the context of APIs, the buyer is the end-user and the seller is the API provider. Good apps are the ones that can package the provider's API in a great user experience that encourages the end user to participate. The growth of apps as intermediaries with valued services like Salesforce.com, Twitter, Facebook, eBay, and others requires a way for users to try the app for the first time without compromising their private data and privileges.

OAuth 2.0 makes it easy for end users to adopt new apps because they can test them out. If they don't like or don't trust an app, users can terminate the app's access to their account. In 2012, this will be the default choice for securing APIs that enable end-users to interact through apps with their valued services.

Strata 2012 — The 2012 Strata Conference, being held Feb. 28-March 1 in Santa Clara, Calif., will offer three full days of hands-on data training and information-rich sessions. Strata brings together the people, tools, and technologies you need to make data work.

Save 20% on registration with the code RADAR20

Related:

December 16 2011

Top Stories: December 12-16, 2011

Here's a look at the top stories published across O'Reilly sites this week.

Five big data predictions for 2012
The coming year of big data will bring developments in streaming data frameworks and data marketplaces, along with a maturation in the roles and processes of data science.

A war story, a Kindle Single, and hope for long-form journalism
Instead of walking his latest long-form story door to door, freelance journalist Marc Herman decided to blaze his own trail — he published the story as a Kindle Single. In this interview, he talks about the Kindle Single experience and offers his take on the future of journalism.

You can't get away with a bad mobile experience anymore
Mobile used to carry built-in caveats around speed and design, but those excuses are now wearing thin. In this interview, Strangeloop's Joshua Bixby examines the evolution of mobile expectations and how companies should adapt.

An angel who bets on women-led companies
Joanne Wilson discusses becoming an angel investor, how investors can help change the ratio of women CEOs, and the Mars versus Venus approach to entrepreneurialism.

Where is the OkCupid for elections?
What will be the "OkCupid for elections" in 2012? Open-source app OkCandidate.com offers one approach, and startup ElectNext is applying data analysis with an issue-matching engine.


Tools of Change for Publishing, being held February 13-15 in New York, is where the publishing and tech industries converge. Register to attend TOC 2012.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
Get rid of the ads (sfw)

Don't be the product, buy the product!

Schweinderl