Android's XML layouts are built to be easily manipulated from code. For instance, it is very common for applications to selectively inflate bits of a View hierarchy by using a LayoutInflater. Other APIs, like ViewStub and findViewById(), help bridge the gap.
One of the most important reasons why we encourage developers to use XML layouts instead of code is to better support multiple configurations. While you might not care about supporting multiple locales, the XML layouts system makes it very easy to support multiple screen resolutions, densities and orientations. (And of course you can use other qualifiers like whether or not the device has a touch screen, a keyboard, a dpad, the API version number, etc.) You can do all of this from code of course, but it's much more work. But you don't have to use XML if you don't want to. On Mon, Jan 17, 2011 at 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<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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
