RSS

Category Archives: Windows Phone

MonoCross 1.0 Released

After many months of intense development sprinkled-in between our client obligations, we have released MonoCross version 1.0!  Many thanks to Ben, Kenny and John, as well as the rest of the team at ITR Mobility for your help pulling this together.

Here some highlights:

  • Core Navigation Re-factor:  added multi-threading support to navigation, and re-worked the navigation logic to be available directly from your Views.
  • Enhanced iPad Support: extended iOS navigation to enable large form-factor concepts for iPad.
  • WebKit State Management: added multi-session support to MonoCross.WebKit; previously state management was entirely the responsibility of the application developer.
  • MonoDroid.Dialog Updates: new element types, and enhanced support for dialog development on Android.
  • WebKit.Dialog: added a new project and elements to support for dialog development on WebKit.
  • Data Management Samples:  a new sample, (CustomerManagement), that demonstrates common data management operations, (List + CRUD), in a simple three-view application.
  • Data Management Services Sample:  a new RESTful services sample built in WCF to show device/server interaction.
  • Windows Phone Support: added support for Windows Phone, including XAML-based views, navigation helpers, and containers for both the BestSellers and CustomerManagement samples.
The download is available at monocross.net, and if you like what you see come join us.

Now here’s where I make a shameless plug for the book ;^)

Professional Cross-Platform Mobile Development in C# from Wrox Press is available for pre-order at Amazon.com for delivery in early 2012.  In it we’ll cover even more ideas to make your MonoCross development efforts successful, such as:

  • Choosing the Right Archtecture:  considerations for mobile architecture decision making.
  • Designing your UI: best-practices in mobile user-experience design and prototyping.
  • Cross-Platform Development with MonoCross: details on successfully using the MonoCross MVC pattern to deploy your apps.
  • Building and Consuming Data Services: how to build RESTful services that are optimized for mobile applications, and how to consume and process data, even when you’re disconnected.
  • Accessing the Device: tips and techniques for accessing device features such as audio-video, contacts, messaging, geo-location and more.
  • Using MonoCross Utilities:  how to incorporate MonoCross.Utilities into your shared application for a unified approach to storage, threading, network, cryptography, serialization and logging — all from your shared, cross-platform applications.
  • Building Hybrid Applications:  how to get the best of both the web and native worlds by using techniques like custom URI schemes, and device function hooks.
  • Delivering your Application to the Enterprise: how to extend your mobile application to the enterprise desktop, web, and even the cloud; plus advanced techniques for sharing code including view-abstraction and mixed-view-models.
Thanks to everyone in the community who have shown such tremendous interest in MonoCross; we’ll continue to move it forward, and hope to build a vibrant community of propeller heads!

Advertisements
 
 

Tags: , , ,

MonoCross – The Technology

Many of you have expressed an interest in the details of the MonoCross technology. The intent of this post is to do that, but only at a high level. I won’t be conducting a bit-by-bit tour of the pattern in this post, since the source is available for review by interested persons in the Project on Google Code. So if this narrative piques your interest, please go check out the details there.

A Little History

It started about two-and-a-half years ago when we were heavy into iOS development using Objective-C. At that time we started to hear from more and more clients that were interested in cross-platform applications. At the time we saw HTML 5 and WebKit as the best option, (as many large organizations still do today). Having done so much native development up to that point gave us a unique perspective on the capabilities of HTML 5, and we quickly realized that there were many things it did well– but there were other things that it did not do as well. The HTML 5 frameworks available for mobile development at the time were limited, and the same rich user experience that was available in native iOS applications was difficult to achieve. We also learned that although HTML 5 provided for offline applications using the cache manifest specification, there were still significant use-cases that required more sophisticated offline capabilities than were available in the browser.

As we were diligently working to solve cross-platform problems with HTML 5 we discovered MonoTouch, and a whole new possibility emerged. We had been working with C# and .NET for years, and the foundation of our mobile practice was in Windows Mobile development in CE and .NET CF. Within a few days of downloading the evaluation we had ported several client projects from .NET CF into MonoTouch, and were able to prove the concept of code portability. For the first time in my career I was seeing true code-reuse in heterogeneous platforms — it was very exciting! When Novell announced Mono for Android we immediately joined the beta, and began to put together our vision for cross-platform mobile development.

Code Portability

I’ve been in software a long time, and since before I joined the profession people have been talking about code re-use and portability, but the discussions have been largely theoretical. Most large enterprise software organizations tend to create homogeneous development environments. “One Language, One Platform” has been the mantra of most shops because its easier to manage things that way. You settle on a single technology stack, and build your applications on it. The organization also dictates the infrastructure needed, and the devices that will be supported, and most of those decisions are made after the technology stack is chosen.

Then Apple came along with the iPhone — then Google with the Android, and these organizations started having these decisions made for them by their employees. This consumerization trend has turned corporate IT on its head. The status-quo is no longer sufficient. “One Language, One Platform” doesn’t work anymore in the rapidly changing world of mobility. Suddenly these enterprises were facing problems they’d never had before. Supporting multiple, heterogeneous platforms had become a necessity, but very few organizations had the expertise to do so because of their homogeneous platform strategies of the past.

Fortunately for most of my clients, who have already made significant investments in C# and .NET as their language and platform of choice, Mono provides a compelling path forward. Those theoretical discussions around layered architectures and re-use of code became real, and the benefits apparent in this new world order. With MonoTouch and MonoDroid we could clearly demonstrate that the millions of dollars spent on existing applications could be leveraged and brought to these new platforms; and with the application of a few proven enterprise design patterns, significant modules could be shared across them all.

.NET Developers now had a choice. They could deliver native applications in MonoTouch and MonoDroid, or they could deliver web applications using HTML 5 and ASP.NET– but a new choice was also available. From our experience delivering HTML 5 applications with ASP.NET and PhoneGap, we saw a new pattern emerging. Native device integration could be achieved in HTML 5 via JavaScript interface, and custom URI schemes. Now developers could build applications across the hybrid spectrum, delivering as much or as little native vs. web functionality as their use-case required. Web techniques could be used where they were strongest, and native techniques where they excelled. Not only had Mono enabled cross-platform development in C# and .NET, it had enabled cross-architecture development.

Code Portability

This code portability model has become the foundation upon which we have built the MonoCross pattern. The core principles of code-reuse not only across platforms, but across architectures became our rallying cry. It remains our vision moving forward.

Coding Across Platforms & Architectures

This realization of code portability across both the platform and architecture dimensions was exciting, but we knew there were some practical problems that still needed to be solved. Most business and data access code could be ported and shared easily. We had proven this in our initial experiments with MonoTouch. But the UI paradigms exposed by the various native SDK’s were decidedly different. Beyond that we had to solve the problem of workflow and navigation. How do you enable cross-architecture development when the fundamental construction of application screens varies so much between web and native implementations? Finally we needed to provide a mechanism to handle changes to objects that were in-play, and successfully communicate changes from the UI to the shared application.

Separating the UI

The solution to the mismatch in UI paradigms was obvious. We needed to provide for fully customized views in the presentation layer, while sharing as much of the other application code as possible.

Separating the UI

To accomplish this we settled on a modified Model-View-Controller pattern that uses a separated view-interface to loosely couple the View and Controller. As long as the custom view implements the correct interface, the shared Controller code can interact with it as needed.

Defining Application Workflow

We also needed a mechanism to define the application workflow in a manner that would easily translate from native to web-based architectures — this was an absolute necessity in achieving our vision of cross-architecture portability. We knew we needed to provide for stateless navigation to support web architectures, but needed a way to accommodate the event-driven application interaction model in the native platforms. We settled on a URI template navigation model in the shared application. This model provides for seamless integration in web scenarios, while exposing hooks to the native views to initiate actions in the shared controllers. Controllers are registered with one or more URI endpoints that follow RESTful design principles to enable multiple workflow paths, and full CRUD data operations.

NavigationMap.Add("", new CategoryListController());
NavigationMap.Add("{Category}", new BookListController());
NavigationMap.Add("{Category}/{Book}", new BookController());

The Navigation Map is shared across platforms, and the use of a URI-based navigation scheme further extends the MonoCross architecture to support URI-based device API’s, web links, and deep-linking to other MonoCross applications by registering your own custom URI schemes.

MonoCross Containers

Much of our work of late has been continually refining the container concept in MonoCross. A container is a platform/architecture specific executable that runs a MonoCross application. The container is where calls between the shared application, (i.e. Model and Controllers), are marshalled to and from the platform specific UI implementation, (i.e. Views). The purpose of the abstract MXContainer class is to provide the base interface and implementation that is extended to each specific platform target. These concrete containers, one per platform, mitigate much of the mismatch between platform UI paradigms. They serve as an application wrapper, message broker, and utility interface, and are a critical component to the MonoCross pattern.

Handling Changes

To achieve the necessary communication of changes, including validation and CRUD operations, we settled on an Observer pattern on the container to notify the shared controllers of changes to the model. The MXContainer implements a NotifyViewModelChanged() method that is exposed to the Views.

private static void NotifyViewModelChanged(IMXView view, object model)
{...}

While this pattern is working well in our current client implementations, we’re exploring a move toward a pseudo-MVVM pattern to achieve synchronization of model changes in the shared application. This is actively evolving as we speak, and input from qualified contributors is welcome.

Moving MonoCross Forward

We continue to refine and evolve the pattern– and we want your help! So visit the MonoCross project, and get involved. The current roadmap is published there, and there is plenty of opportunity to help us take this into the future. Suggestions are welcome, and our hope is to build a vibrant community around MonoCross. So come join us!

 

Tags: , , ,

Mono @ Microsoft

I wrote last week about C# and .NET for mobile development, since they are currently the only language and framework that is portable across the major mobile platforms, (iOS, Android, and Windows Phone). Well it looks like the idea is gaining some momentum in Redmond.

Both Rabi Satter and Rob Tiffany have been blogging on the subject, and the two have even ported their Mobile Line of Business Accelerator over to MonoTouch.

Rob even speaks of Mono as a key component of what he calls the Microsoft MEAP. For those unfamiliar, MEAP stands for Mobile Enterprise Application Platform — a term coined by Gartner in an attempt to provide a definition for software vendors who offer a packaged enterprise mobile solution. Currently Microsoft is listed as something of a “niche player” on Gartner’s MEAP Magic Quadrant due to their support for only a single platform. Mono would make support for multiple platforms simple, and greatly strengthen their MEAP offering. I for one hope Mr. Tiffany is successful in the bid to make his vision a reality.

 
1 Comment

Posted by on March 28, 2011 in Android, iOS, Mobile Development, Windows Phone

 

Tags: , , , , , , ,

C#/.NET: The New Mobile Standard?

Miguel de Icaza made a bold statement last month after Nokia announced they would be replacing Symbian with Windows Phone 7. He made the assertion that C# and .NET, via the ECMA CLI standard, is becoming the de facto language for cross-platform mobile development. As you can imagine, this resulted in some rather lively discussion in the open source and mobile development communities.

Politics and Religion aside, I think he makes a strong argument. Despite their recent troubles, and their virtually non-existent U.S. market share, Nokia still has more mobile devices in the market worldwide than any other manufacturer. The WP7 announcement advances the portability of C#/.NET code to these devices, and offers a world of possibilities across all of the major players in mobility today, as Miguel’s chart clearly shows:

Portability of C#/.NET code

Now I can already hear the arguments that HTML 5 provides the same portability, and is an open standard without all the excess baggage, (read: Microsoft), of C#/.NET. In fact, many clients I speak to today hail HTML 5 as the answer to their mobile prayers, but the reality is often not so rosy.

Don’t get me wrong, I love HTML 5. It brings incredible flexibility and power to mobile devices, and the apps you can write with frameworks like SenchaTouch, and JQuery Mobile are truly impressive. But there are just some things a web-based application cannot do. The HTML 5 Cache Manifest standard provides for disconnected capabilities, but it is still difficult to support full offline transactions without some intelligence to manage them outside the browser. Access to the device’s native features, (GPS, Camera, Accelerometer, File and Storage), all require native interaction via frameworks like PhoneGap; and despite the advances in the HTML 5 user experience it still cannot provide the same richness that the native platforms can.

HTML 5 can provide an elegant, cost-effective solution to many cross-platform problems, and I counsel my clients to take a long, hard look at it as a first step in any assessment of their mobile application strategy. Most enterprises already have an army of web developers who can be re-trained to develop mobile-optimized web applications, and this often provides a critical first-step for many of them into the mobile world. But as soon as the problem at hand requires disconnected transactions, or access to the device, or a rich user-experience that HTML cannot provide, native options have to be considered.

C#/.NET and Mono are my first suggestion for organizations who already have a significant investment in Microsoft technologies. They offer full access to the device, and all the native capabilities of Obj-C on iOS, and Java on Android — plus C# and Silverlight for WP7. What’s more, they can still deliver HTML 5 web applications via ASP.NET while leveraging existing investments in the .NET platform.

Time will tell if C#/.NET and Mono will become as Miguel puts it the “lingua franca of all major mobile operating systems”, but for most of my clients it is their best solution for their cross-platform mobile problems.

 
 

Tags: , , ,

 
%d bloggers like this: