MVC is yet another good concept gone buzzword. The idea of "separation of concerns" and "modularity" is critical to the design of complex programming systems -- by splitting an application along the RIGHT boundaries you can vastly reduce its effective complexity, improve maintainability, and prevent/remove errors. But cleaving an application on an arbitrary "book" boundary isn't always the right approach, and especially with modern dynamic UIs, it's not always possible to tell where the boundaries are or ought to be.
That said, generally the more compact a notation is for stating the same semantics, the better. (Which is to say that designing your UIs in JSON would probably be better than XML, but that's a topic for another time.) Way back in the olden times there were mainframe tools like the S/38 Screen Design Aid that produced a tabular (non-"code") screen definition and it worked well, but for reasons not entirely clear UNIX and PC systems went off on a tangent with their "object- oriented", code based UI schemes, and things have been screwed up ever since. (Keep in mind that one can easily design a tool to translate an XML or JSON description of a screen into code, but going the other way would be nigh to impossible.) However, what has happened is that UIs have become more "active", with bits that wink into and out of existence at the wave of a cursor, and tabular approaches have thus become more difficult. (Not that folks haven't tried to fix this. Concepts like JSP are mostly "tabular" with embedded code fragments to handle the dynamics. But most are saddled with the incredibly ponderous HTML notation, so they're starting out with a handicap.) So, having gone around in circles, the important point is this: Choose a notation that will allow clarity and brevity, but still with the flexibility you need. Create boundaries or "firewalls" in your logic at appropriate points, but don't obsess on following some textbook description of where they should be or how they should work. Try to pick concepts that are a bit bigger than your project (and definitely bigger than a single component), so that there is some hope that components of your code might be "reusable", and some hope that too many warts won't need to be added to accommodate future enhancements. On Jan 13, 9: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
