Reputation: 9786
I have been reading a little on Monocross and it seems to support a model very similar to ASP.NET MVC. It can use HTML5/CSS/Javascript as the UI.
Looking initially directly at MonoDroid and MonoTouch, it encourages the developers to develop with controls native to the device. Am I correct in saying the Monocross supports a HTML/CSS/Javascript with HTTP/GET/POST on all devices? MonoDroid/MonoTouch supports cross platform development all the way up to the UI, but this approach seems like I get theoretically get 100% (or near) code reuse. Is this correct?
Upvotes: 4
Views: 1047
Reputation: 268293
MonoCross is a very thin layer on top of Xamarin's code. (See that Xamarin sticker in the top right corner?)
They offer to reuse the same MVC code across different implementations, such as MonoTouch and MonoDroid.
Abstracting away MVC works for small samples but these guys seem to religiously believe in 100% code sharing—something I don't subscribe to. It is a beautiful concept, but it never worked in the real life.
Making great apps is hard, but I don't think it's hard because database technologies differ, or because you have to write similar classes for ASP .NET MVC, MonoTouch or MonoDroid. If that was the real challenge with software development, we'd have solved it many years ago.
MonoCross seems to be an exercise in premature generalisation—something that all programmers love.
But abstraction isn't free. Consider this anecdote by Eric Gunnerson:
I've know teams where this snowballed - they ended up with a "swiss army knife" component that was used in a lot of different scenarios. And like many components that do a lot, it was big, complex, and had a lot of hard-to-understand behavior. But developing it was an interesting technical challenge for the developers involved (read that as "fun and good for their careers"...)
The problem came when the team found that one operation took about 4 times as long as it should. But because of the generalized nature of the component doing the operation, there was no easy way to optimize it.
If the operation had been developed from scratch without using the "uber-component", there would have been several easy optimization approaches to take. But none of those would work on the generalized component, because you couldn't just implement an optimization in one scenario - it would have to work for all scenarios. You couldn't afford the dev cost to make it work everywhere, and in this case, even if you could, it would cause performance to regress in other scenarios.
(Emphasis is mine.)
While MonoCross developers seem enthusiastic about it, there doesn't seem to be a community around the project, and I couldn't find a single app built on top of iFactr or MonoCross.
That being said, I don't think they offer anything valuable over MonoTouch or MonoDroid.
On a sidenote, Miguel approves :-).
Upvotes: 1