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
