'Obsolete' may be overstating the case. But not by that much. After all, MVC dates back to Smalltalk days! You would HOPE that someone would have come up with a better design pattern by now.
But what in fact happened was different. Two big things happened: 1) since everyone knew MVC was desirable, but not everyone really understood what it really was, lots of people started calling different things (some not very good things) 'MVC'. So the name has suffered from pollution. 2) even the original MVC became subject to fully justifiable criticism that the Controller did not interface well with modern UI component libraries, where it is the Component that handles input, not a central Controller. So a variation of MVC now called MVP "Model View Presenter" has now become even more popular than the original MVC. http://www.martinfowler.com/eaaDev/uiArchs.html is still an excellent article on the two -- and other architectures. On Jan 17, 11:40 am, Bob Kerns <r...@acm.org> wrote: > MVC separation of View and Controller -- Obsolete????? That is > something I have never heard of. Could you elucidate? What replaces > it? The separation in MVC exists for very specific benefits. If you > view it as obsolete, you must have a New Idea -- MVC started as a New > Idea, and I like New Ideas.... (Don't worry about whether the idea is > good enough. The courage to be wrong is the best tool for both > learning and creating something new). > > A key one of those benefits is that the separation allows you to > substitute alternate views. This can come up during localization, and > when accommodating different device sizes and geometries. With > localization in particular, having it be part of the XML is an > important advantage, as you don't want a localization service altering > your Java code! > > At the same time, the ability to do it from code is there to give > flexibility when the XML falls short. But it needn't be all one or the > other! For example, it is quite usual to use XML to describe the items > in a ListView, and inflate the appropriate XML file for the items from > Java code. You can apply the same strategy at any level -- for > example, an outer template that gives the outer structure, select the > components that plug into it via Java code, and then inflate those > components, and plug them into the outer template. > > This is very easy to do. You use ID's on the parents of items in the > template, and findViewFromId to locate them, and inflate the children > (perhaps a variable number of children), make any adjustments, and add > them. > > Re: your second sentence: You HAVE the power to create your own layout > classes. Use it! If you want to create a Carousel layout that arranges > a set of views into a carousel, write that algorithm in Java as an > actual layout class, then reference it in your XML. If the set of > views in the Carousel is dynamic, make it work with an Adapter, > similar to how ListView works, and inflate each subview dynamically. > > Oh, and a postscript: I use XSLT to strip out or disable unwanted > views in the free and paid versions of my app. (Views related to > features not present, or ads). This is harder to do reliably with Java > code. > > In general using declarative languages where possible is a time-tested > strategy for making software simpler to work with, both for humans and > programs, and making it easier to be consistent. This is a matter of > *deliberately* giving up certain flexibility, compared to imperative > programming. By giving up the unfettered flexibility of a Turing > Machine, you gain a host of benefits and lose a ton of potential > complexity. (An infinite amount of potential complexity, really!). > > It is not ALWAYS the choice you want to make. But if what you want to > do fits within the declarative framework, you are almost always better > off sticking within the declarative framework, and if it doesn't QUITE > fit, you're better off using the declarative framework, with a minimum > of imperative programming where necessary. > > On Jan 13, 7:04 pm, Toby <t...@tobiah.org> wrote:> Ok, we've thought about > MVC paradigms for our company, > > but unless you really need to hide the code from some > > "Designer" I can't see the benefits. > > > I want the power of the computer language at hand to allow me > > to create layouts dynamically. I've been scolded about > > that by one most learned participant of this list. I don't see > > why. I want to use the base language (here java) to > > create layouts. Why on earth does Google go for what > > I (Certainly Erroneously given the body of individuals > > to which I am now speaking) perceive to be an obsolete > > separation between Controller and View? > > > Please enlighten me, you undisputed masters of this > > newly found world of which I hope to convincingly call > > myself a member in short. > > > Thanks, > > > Tobiah > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
