All layout elements are descended from the “View” object, and these form the basis of any Android UI. To get this lingo out of the way from the get-go then, there are three terms that you’ll need to know when designing the presentation layer of an Android application;
Widget: A term used to describe UI elements. Note that there is no “Widget” object, it’s the name of a package.
View: A “thing that gets plonked on the screen”. Buttons, spinners, textboxes etc. will all inherit from the View object.
ViewGroup: A special kind of View object (direct descendant) that can have other views nested inside it (like HTML!).
The other bit of lingo that will be used here is “Activity”. I will go into more detail on this in a later article, but for now just think of it as “Something the user can do”.
Firstly we’ll be looking at the ViewGroup object, which in the standard API contains six direct subclasses (with further subclasses beyond that). We will be looking at three of them in particular;
There are a bunch of subclasses of each of those too. If you’re interested in seeing all of those, the API page is here. Subclasses include the “Gallery” widget, and the “DatePicker” widget. Basically, the sexy ones. For now, we’re going to focus on these base classes though.
We are going to focus on these ViewGroup objects for now, and come to other types of widget later on. ViewGroups possess the ability to have other Views “nested” within them. Although the term ‘nested’ is generally only used when referring to markup languages, I’m going to use that term throughout even though you can develop your UI programatically too (in which case they’d be “arrays of pointers within the object”, but we’re going with “nested” m’kay 🙂 ) .
These articles will go over the types of ViewGroup available, how you use them, and also some of the basic settings you can use for each of them. In keeping with the idea of making these articles friendly to those migrating to the platform from a web development background, I’ll try to reference each ViewGroup back to a web equivalent. I will also go over how to achieve layout both programmatically and in XML.
Two ways to build your layout
Well, I say two ways but you are actually free to use a mixture of both as well (these methods certainly aren’t mutually exclusive). The two methods are as follows;
Define your UI programatically: This is where you build up the views from within the Activity by instantiating objects and eventually passing them to theActivity’s setContentView method. This way, the UI can be built at runtime. This approach will be familiar to swing programmers.
Define your UI in XML: Where you use the android schema to define your layout in XML and then reference this from within the Activity. This way, the UI is separated out from the application logic (a very desirable trait in modern architectures) and you can change the UI without having to rebuild your application. This approach will be familiar to XHTML designers.
There is no right or wrong method: each of the above approaches has an appropriate usage. Some users (particularly swing programmers) will prefer the programmatic approach, but generally it makes more sense to use the XML method. When you see the amount of work required for each, you’ll see why.
All ViewGroup objects implement a nested class that extends the “LayoutParams” class. This class specifies the various layout related properties of any ViewGroup such as width or height. You can specify these either programatically or as xml attributes. Each widget will extend this LayoutParams class to add on its own features, but some features are common to all Views (those in the LayoutParams base class).
The parameters “layout width” and “layout height” are two examples of this. These must always be specified in ViewGroups, so I just want to go over them a little before we get cracking. You can specify the following values;
"fill_parent" / "match_parent"
This value will cause the View to be as large as its parent view allows it to be. These two are actually the same command, but the syntax was changed to “match parent” in API level 8. Similar to, but not exactly like, setting a contained <div> to have a 100% width style.
This value will cause the View to be as large as the content view requires it to be. Similar to having a <div> in HTML with no height or width styles specified.
So those are mandatory, but otherwise these layout parameters generally come with default values that are used if none are specified.
Each of the base ViewGroups will be covered in a separate article. The reason for this is because I am going to be demonstrating how to create layouts programmatically in a very verbose fashion, so the pages may become quite long. Before We get on to that though, let’s have a quick look at the documentation available to you. To most programmers, a new language generally isn’t a big problem to learn; The general principles of programming languages tend to hold fast and all you’re faced with is a new syntax to get used to. New APIs, however, are always the trickiest part about learning a new platform. Fortunately, the android API is incredibly well documented. It all starts here;
That page details every single package included in the android SDK. These pages tell you what any object does, how to use it, and in the case of views it tells you the xml attributes you can add to a layout AND shows you the programmatic equivalent. Take the “TextView” object for example;
Obviously we haven’t come on to any actual examples yet, but if you look at the guide it tells you everything you’d need to know to incorporate this control into either an XML layout or a programmatically generated layout. I never thought I’d say this, but if you ever find yourself stuck, consult that API before consulting search engines!
On to the ViewGroups!
I am going to cover each ViewGroup in the articles that follow this one. When I’ve done one, I’ll put a link to it here. When I’ve done them all, I’ll probably delete this paragraph, so don’t get too attached to it 😀
I may also move on to other items in the meantime, instead of just focussing on layouts. Each layout will therefore not constitute another “Part” of this series, but will be featured here none the less.