RSS

MonoCross – The Technology

20 Apr

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!

About these ads
 

Tags: , , ,

8 responses to “MonoCross – The Technology

  1. Pedro Galván

    April 24, 2011 at 2:53 pm

    Hello. I am editor at Software Guru magazine in Mexico (www.sg.com.mx).

    I’d like to publish an article on monocross. Possibly even translate this post and publish it providing the credits and reference to here.

    Please send me an email with your permission if you agree to this.

     
  2. Jacobo Polaviejaacobo

    June 9, 2011 at 5:04 am

    Hello,

    Im’m sorry because I know this is not the place for this but I haven’t found any forum or mailing list of the project.

    After reading the sample at http://code.google.com/p/monocross/wiki/UsingMonoCross I wonder about two things:
    1. You say you follow a RESTful API design but I don’t see how you differentiate between POST and GET actions on each URI you define. In the example there’s just retrieval of information and no example of submitting any changes… How do you manage that?
    2. How do you manage architectural differences? I believe what you create with MonoCross is a self contained application so I wonder how do you treat the case where you want a webapp where the views area webpages and make the calls to the restulf API through HTTP calls to a server.

    Maybe I’m asking stupid things but I haven’t found out any hint for these through your wiki or anything I’ve read about the project. It seems a very interesting one and one thing I may have been looking for a long time, just those two issues arose in my head.

    Thanks if you don’t mind replying and thank for the great contribution of MonoCross.

     
    • vagabondrev

      June 9, 2011 at 4:24 pm

      Hi Jacobo –

      No need to apologize. We’ve been working to get more support information on the MonoCross site, but we need to balance it with our client commitments, and it isn’t getting done as quickly as we’d like. Good questions; I’m happy to respond:

      1. We’ve been debating on whether to add a verb to the MXContainer.Navigate() method, but haven’t agreed on an approach. Currently The RESTful design only applies to the parameterized URI scheme used to build the NavigationMap. We handle transactions differently for each client, but generally use an {Action} parameter on the URI, (for example Customers/{Action} or Customers/{Id}/{Action}), where the action is set to something like “Add” or UpdateWithValidation”. The parameter is passed to the MXController.Load() method in the Dictionary parameters argument. You are then free to apply whatever logic you need on the Model based on the action requested.

      2. You are correct that a MonoCross application is delivered in a self-contained deployment. You must host your shared MonoCross application in a platform-specific container. There are three architectural options:

      Option one is a native application that runs entirely on the device; the Droid and Touch containers in the Best Sellers sample illustrate this approach.

      The second option is a pure web application that runs entirely on the server, and is delivered in the browser application on the device; this approach is illustrated by the Best Sellers WebKit sample.

      If I read your questions correctly, you are asking about option three, which is a hybrid application that uses native and web functionality in conjunction with one another. This approach starts with a native container that will be installed on the device, and run any native functionality, (Models, Controllers and native Views), for whatever features you need to deliver natively, while any web-based content is delivered from the server in a native web-view. The source of this content could be an existing web server, that already provides that functionality, a new web application developed in ASP.NET, Java, or some other technology, or it could be a customized MonoCross WebKit container of the same shared application running on the server. We don’t yet have an example of this approach, but are working on one and plan to include it in an upcoming version.

      I hope this helps. Let me know if you need any further clarification.

       
      • Jacobo Polavieja

        June 10, 2011 at 3:19 am

        Hi and many thanks for answering; I know you have to be very busy. I look forward to when you can open a forum/group if you want and when you are able to.

        Question 1 was totally clarified.
        About the second question I think I messed up. I thought of containers as just views, without platform specific relevance. After reading your comment and having a look at the code of the sample you mentioned I realized that when a Webkit.Container is used you use ASP.NET MVC to support it the server side, am I right?
        If that is so, does the framework translate the declared routes to asp.net mvc routes so that the produced html calls the right link?

        I also believe you build the HTML code through C#, no template engine used, is that true?

        Thank you very much and don’t hurry in answering, first things first ;).

        Cheers!

         
      • vagabondrev

        June 10, 2011 at 6:02 am

        Yes, we are using ASP.NET MVC on the server-side for the WebKit.Container, but only for the routing function. All endpoints are routed to a single ASP.NET MVC Controller where the URI is passed to the MonoCross navigation framework.

        That reminded me of another aspect of URI based navigation in MonoCross: navigation links on the WebKit target are all web-links, (i.e. http://…), and correspond directly to the entries in your NavigationMap. However, you can register your own URI schemes, (i.e. mymxapp://…), and write a custom handler for it in your hybrid applications. This enables even more flexibility in mixing web and native functionality. It also enables deep-linking into web applications, and other MonoCross applications running on the same device. We will have examples of this approach in time too, but have to fit it in with everything else.

        I am planning on starting a forum for the pattern on Google groups; I’ll put a link on the code site when it’s up.

         
  3. Jacobo Polavieja

    June 12, 2011 at 3:35 pm

    Oh, that clarified everything that was left… many thanks for taking the time to do it.

    You’ve got a very interesting project and I’ll follow it and hopefullly start playing with it (and contributing if I can) soon. I’ve thought so many times I wished something like this existed… and now it’s here!

    All the best,

    Jacobo

     
  4. Simon Jackson

    October 21, 2011 at 2:06 am

    Hi,
    Thanks for your work on MonoCross, I hope it will be really useful to me for Android Development.
    Regarding CRUD operations, is it possible to provide a snippet of example for the console app to show how the objects interact to say:
    1. Display a prompt
    2. Validate a response
    3. Update a model

    Many thanks

     
    • vagabondrev

      November 14, 2011 at 1:48 pm

      Hi Simon —

      I just updated the MonoCross codebase at monocross.net to include a new sample, Customer Management that shows an implementation of CRUD operations. I hope this helps.

       

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

Join 89 other followers

%d bloggers like this: