Introducing Mvpc

Mvpc (Model View Presenter Command) is a new design pattern and reference library for designing and building software applications and mobile apps.  The design pattern has been in circulation for a little while, but its true impact is only beginning to be understood and as the creator of Mvpc I’ve been asked a number of times to explain its origins, why a new approach was required, and how we arrived at the breakthrough.

Over the coming weeks and months we’ll take a look at specific usage of the pattern and each of it layers and techniques in detail; but this post is designed to lay out the basics and help you understand where the thinking behind the new pattern came from.

If you want to look at the reference implementation of the technology contact me or anyone at Ambidect.

The Origins of Mvpc – The Multi-device future

Whenever you are faced with a problem you should always look at how others have approached the problem before, and see what lessons can be learnt from these previous attempts, however successful or otherwise.

One of the biggest problems facing the software industry at present is: how do you create software that can run on any device, without having to build separate programs or apps for each platform?

It used to be that everybody expected to do “real work” on a Windows PC.  But now people want to do real work anywhere, and everywhere.  It started with the advent of smart phones first, and then doubled as tablets started to dominate the living room computing experience.  And those changes have had unexpected and unpredictable impacts on business impact with the establishment of BYOD polices and the significant growth in Macs returning to the workplace.

This all means that not only can we now not expect a single type of operating system, but we can’t specify a minimum screen size any more, or even assume a keyboard or mouse are available.  With new devices hitting the market every day has the problem  significantly worse; and if left unaddressed would become a threat to the entire software industry, not just individual companies.

Businesses buying software are left in a position of having to predict which devices they will want to use three or five years from now and tie the success of their business into those platforms.  How can they make an investment decision with such uncertainty?  Can they even find two experts that agree on which devices will still be around ten years from now?

Businesses wanting to reach a large audience are having to spend large amounts of money, often with different developers or development companies, to keep up with the demand of consumers.  With many people now having access to two or three devices of different types and wanting to access your service on whichever one happens to be closest to them right now.

Software developers and companies are being forced to specialise in an individual platform to be able to hire and train staff efficiently enough to keep ahead of a demanding changing environment.  This gives a growth to a growing number of small development companies specialising only in one platform. iPhone App development companies, Web Development companies, Linux Developers, Windows Phone Specialists and the list goes on.

This proliferation means businesses are being forced to repeat the same work with multiple companies at great expense.  And just when the development feels complete, the combined quotes for the first major enhancement brings the eye-watering reality of the unsustainability of the approach.

Despite all of this, us as users are constantly expecting more and more from each device we carry.  We are frustrated when our phone can’t open an attachment to an email because the program isn’t available.  We feel restricted when we sit at a Mac and try to do our accounts.  We get asked “can you put this on my iPad” and have to spend hours trying to explain why its not possible because the great application just doesn’t work on iOS yet.

Mvpc is designed to solve this.  Its designed to change the way people look at software development.  As its principles get adopted across the software development industry it will allow one development to be undertaken that does run on all platforms.  It will reduce development costs without reducing your potential market.

Most importantly of all, it will put the power back in the end user’s hands.  When you find the right piece of software, you won’t even ask if it will work on your new phone, tablet, friends PC, or at an internet café in an airport; because in our vision of the future everything will work everywhere.

We genuinely believe that one day all software will be developed using the principles that drove us to put together the Mvpc design pattern.  I hope we’ll look back to the days of awkward single-platform development with same nostalgia, some look back at Assembler, Smalltalk, and Windows 3.1.  Each was a significant in the way it got us to the next page of the technical future, and we are about to turn another page to a world where software is independent of device.  A future where users make the choice on how, when, and where to use a service, not developers, and not budgets.

What Others have Tried and Failed

People have been trying to solve the problem for years, even before we all got so many devices around us.  All these attempts I have come across however can be grouped together under three broad categories:

1. Creating applications that execute on a server and use a web browser to connect and view information.
2. Providing a cross-platform GUI toolkit.
3. Encouraging libraries to be built with reusable methods, and then trying to keep the platform dependent code as small as possible.

Each of these approaches have a lot of good in them, and can be useful.  But on their own they provide significant drawbacks.  I’ll address a few of the pros and cons of each here briefly, but in time I’ll add individual posts that go into the details of the points made here:

Creating browser based applications

Responive Web Design is becoming a very popular buzzword in the technical and marketing industries right now with a growing number of browser applications that are appearing in the SaaS arena but the idea of solving the problems of platform independence with a web browser predates even the start of “the end” of Microsoft’s monopoly on the devices we use.  Going back five to ten years, many IT departments decided to adopt a ”browser only” policies to introducing new software.  What has this experience taught us?  How does this mean response web design if left alone will manage?

Pros

• Existing skills can be used to create screens that are easier to use on different screen sizes.
• Browser compatibility can be checked with the new software, rather than checking OS compatibility.
• Can be used from any PC or device with a reliable internet connection.

Cons

• Application can’t be used and data loss can result if connection to the internet is interrupted or unavailable.
• As the number of users grow server farms and load balancing are required to handle the growing demands as all processing takes place on the server.
• Developers are required to learn to work with an ever increasing complexity of pre-built scripts, techniques, languages, and browser oddities, to try and make the user experience as rich as possible over the limited stateless request-response drive technology.
• Applications do not feel native on any platform.
• Applications have to be tested on all browser platforms and version before release which can be costly.  More often they tend to end up branded with “Best viewed in Internet Explorer 8 or above” or “For best results use Firefox” as each browser comes with its own set of limitations and problems.  At its most extreme I’ve seen whole IT departments unable to upgrade from IE4 or IE6 because its the only browser all the historical application work reliably under.  This also limits the ability to adopt new applications that understandably require newer browser versions.

Providing a cross-platform GUI toolkit

For people not satisfied with the limitations of a web browser, the primary approach has then been to look at  creating a common API across all platforms.  Sometimes this is done by creating a whole environment and GUI toolkit, as was done with Java and swing, others have focused primarily on the GUI such as Qt and Gtk+ only later extending to non-GUI operations.

To date these tend to focus on the desktop rather than mobiles, although some do exist for mobiles.  At their heart they often require the learning of a specific object model, and the creation of code that is heavily tied into the toolkit via inheritance.

Pros

• Application runs natively on the device and does not require constant internet connectivity.
• Application works identically on each platform with all features available.
• The GUI toolkits tend to be quite larges and provide a good selection of controls to build custom interfaces they way you want them.

Cons

• Application often doesn’t feel native on any platform or feels built to other platforms GUI guidelines (what platform does GIMP feel native on for example?)
• Cross platform experience works across the desktop, but doesn’t address tablets, or mobile well.
• Can’t be used from a friends PC or internet café as most require installation of the application and its toolkit.
• Developers are restricted in the libraries they can use to provide underlying functionality to avoid introducing a tie back to a single platform again.

Encouragement to keep GUI code minimal

Another way of trying to solve the problem is to accept that the GUI and some base functionality is always going to need to be built separately for each platform.  Teams of developers are encouraged to keep the platform specific code as small as possible and usually need to be organised into groups based on the platforms they can work on.

Its normal that the platform with the biggest initial target market tends to get the majority of developments, with other platforms playing catch up (for example have noticed the difference between using Skype on Windows or on Linux?).  In fact often features simply never make it to these “second class” platforms.

Generally by choosing this approach the decision is made at the start to either target a stateless environment such as the web, or a state-full environment such as a native GUI client.  Once made this decision is hard to reverse.

Pros

• Developers creating a version for a specific platform can use all the tools available for the platform.
• Applications both look and feel native to the platform they are running on.
• Code that is able to ignore the GUI and file system altogether can be shared across platforms as a cross-platform library.

Cons

• Development team needed for each platform and sharing of code between platforms is limited.  With mobile becoming increasingly important and competitive, and Macs making a come back in business that means four full development teams are required just to handle Windows, Mac, iPhone/iPad, and Android before you even look at platforms like Windows Phone, Surface, Windows 8 and RT applications, Linux, and blackberry.
• Usually development takes place against the primary platform, often Windows, or iPhone depending on the nature of the program.  Users using other platforms often feel second class and unimportant and many times migrate to an alternative that targets their platform as its primary platform.
• Every development and enhancement needs to be performed and tested on every platform making it very expensive to enter the market and keep your product updated.

So why is Mvpc Different?

To understand why Mvpc is different you both have to understand what it does, and also what it doesn’t try to do.

Mvpc Does Not

Mvpc does not try to repeat the mistakes of the past by creating a new library or a specialist way of development that requires full retraining of developers and the throwing away of old code and applications.

Mvpc does not try to compete with the three previous approaches in the hope of having a longer “pro” list and a shorter list of “cons”.

Mvpc Does

Instead with Mvpc what we tried to do is embrace how developers already want to work and how users already want to use their devices; and look instead at the fundamental question of how we understand the software design and development process.

Mvpc actually embraces all three of the above described ideas as part of a successful solution, rather than a past failure.

Applications built for example with Mvpc work both natively and are also available separately in a browser.  This means they are available online and offline.  Giving the best of browser based and native applications.

Not only is the GUI completely responsive in its design.  But the application can automatically make use of platform specific features such as GPS or click to dial capabilities.

By following Mvpc 80 to 95% of the code you write will work across all platforms and all device types out of the box.

As the reference implementation of Mvpc (licensed commercially as Ambidect Technology) is built with C# and compatible with any Microsoft .NET language letting you use the skills you already have in your team without significant retraining.

A cross-platform toolkit libraries is included alongside the Mvpc reference library, giving you the benefits of cross-platform libraries, but without forcing you to use a foreign looking GUI as there are built in native GUIs for each platform that can be expanded using the normal platforms GUI toolkit, not a custom one.

Because of this you will be able to use your existing .NET libraries, and applications and most cases port substantial portions of them to be cross platform.

You can access the full native API safely when you are working on a platform specific enhancement, and know that you will be protected from those APIs when working in the portable code.

Using Rapid Prototyping, as is built into the Mvpc design from the ground up, you will be able to create working applications in days not months, and see how applications work on every platform from day one.

Using our Cross-Build-it service you will be able to produce native clients for every platform from a single code base as well as a separate fully functional web site version.

Because your apps are native you can publish them through the Apple iTunes App Store, Windows Store, Mac Store, and various Androids stores.  This opens your apps for maximum discoverability and the most native feel possible.

Mvpc Embraces Existing Design Patterns

Once developers realise the benefits of Mvpc and want to use it for themselves I often get asked “how does Mvpc compare to MVC” or “I’m used to MVVM and I don’t want to waste all the time I’ve put into learning the pattern and toolkits.”

Many platforms use a GUI toolkit that not only works better with a specific design pattern, but now days require it.  With Mvpc we don’t try to fight against this, and we don’t want to loose or ignore existing skills that you have worked hard to gain.

The Rapid Prototype and native GUIs we provide are all built using the native design pattern of the GUI.  You will also use the toolkit and pattern you are already familiar with for the GUIs you provide for yourself.  This is possible because Mvpc is completely compatible with the MVC, MVP, and MVVM design patterns.  If you are used to working in any of those patterns, you can continue to code pretty much as you have before.  With just a little bit of learning and thinking the extra features of Mvpc become available to you and the transition into fully portable software will be very natural.

As you can imagine at this point the developer talking to me lets out a big sigh of relief knowing Mvpc is not about forgetting what you know, its about learning a new way of positioning the puzzle pieces you already have.

Why is Mvpc Succeeding Where Others Failed?

I believe Mvpc is succeeding because it hasn’t tried to compete with others but views all past approaches as stepping stones that when positioned correctly form part of the best possible solution.

Rather than providing a strange new design pattern and asking you to forget your past learning, we’ve designed the new pattern so it follows all the core principles of the leading design patterns developers already use, but helps position the logic correctly to automatically create portable software.

Rather than joining the decade long argument of the pros and cons of native applications vs Response Web Design and browser based solutions; we claim both sides are right, and ensure your application is available both: natively, and as a responsive web application.

Rather than creating a new language, or asking you to learn an obscure toolkit or pre-processor built on top of C or C++; our reference implementation library adopts Microsoft flagship development environment the .NET Framework.  We give you the choice of language with C#, VB.NET, J#, F#, and managed C++ all supported; and thereby keep all the existing libraries for those languages and platforms available to you.

Rather than asking you to carefully pick from a list of pros and cons and hope your customer or developer agrees, we put the choice back where it belongs: You to develop the way you like to develop.  Your customer uses the software however and on whatever they want to.

If you stop and think about it, we shouldn’t be asking why Mvpc is succeeding; the real question is why has it taken so long for our industry to understand two very simple principles:

The end user should have the choice of what they do with their software, and the developer should also have the choice of how they develop the software.  These two things are not mutuality exclusive as we have been told in the past, but part of a win-win solution.

Second, we shouldn’t complete with failed passed attempts based on their “cons”.  Instead we should combine them based on their “pros” so they can make up for each-others weaknesses.

You see Mvpc, as great as it is, isn’t really some magic new way of doing things.  Its the simple idea letting you make a choice that’s right for you, and making sure your choice doesn’t restrict somebody else’s freedom to choose in the future.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.