Understanding Some Essential Android Studio Components

I wanted to talk a bit about some of the problems that I ran into early on while learning to use Android Studio and the development library that comes with learning. I will also be providing some design hints, strategies, and resources for later android development that may be encouraging to a lot of us just starting out.

The standard library of Android Studio is often surprising in its flexibility and it truly rewards exploration. Some other times you may find it lacking in some specific function or behavior that you may need down the line. I’ve explored various possibilities through these lessons by making several copies of the project and trying different ideas in different ways. To start, I will be discussing some techniques that I have learned that may prove to be essential while progressing through these lessons.

ANDROID COMPONENTS

A brief summary. I will quickly list what I mean when I refer to android components. Often referred to as Android Application Components, an android component can be an Activity, a Service, a Broadcast Receiver, a Content Provider, or more. These are generally the major components. The smaller components include things more important to us now, such as Fragments, Layouts, Views, Intents, and Resources. Think of these as the basic building blocks of an Android Application. I am defining these so that we don’t confuse the definition with Android User Interface Components.

ACTIVITY

In short, an Activity carries out instructions in its onCreate() function (which you normally redefine to provide more than the basic functionality of an android library) before running on a continuous loop in its own thread until it is interrupted. The instructions that you layout specify what happens when the original activity is created, thus allowing you to define the ContentView, reference EditText or TextView components (or more obviously), and perform functionality based on your Layout View.

VIEW

Since we just used the term view a lot, let’s understand more of what it means. A view is a Android Component, often instantiated as an User Interface Component, that acts like a rectangular window would in normal java libraries. It acts like a container for various android-based objects, such as text, images, icons, buttons, containers, other views, and so on. A view is basically a window into your XML file, and we must instantiate XML items in our java code before making programmatic changes to them. For example, as we most of us have probably seen by now, if we have a TextView we might change its text by

TextView myTextView = this.findViewByID(R.id.my_text_view); (where thisis referencing another view to obtain id’s defined within the XML)

followed by something like

myTextView.setText("Hello World");

Less trivially, say we have something more unfamiliar such as a RelativeLayout defined within the XML. Android Views allow us to instantiate and act upon any kind of element defined in the android XML library, including something as seemingly abstract as a RelativeLayout. In this way, we barely ever have to use Buttons, because I can literally forget that Buttons exist and simply set a RelativeLayout that I made in the shape of a button (or an larger screen component) with an onClickListener. Now I can set any kind of functionality to that view just as if it was a button, simply because it is based off of an implementation of the Layout (which is a “View Hierarchy”, a layering of views much like the files or folders within a parent folder) Library defined within our development environment.

FRAGMENTS

Think of Fragments as mini-activities that can be placed inside other activities. In theory you could have a fragment of fragments all performing different activities within the same hierarchy on the same screen and in the same parent Activity. The most common use of fragments seems to be as dialogs, as additional window panes (for example within a ViewPager which lays out the space for the contentView of a Fragment) and after researching them myself I thought it would be very helpful to explain them seeing as it sucks to maneuver in an unknown environment. I personally like to get to know the person who is sitting next to me.

USER INTERFACE COMPONENTS

My intention is to grow this thread with discussion and further insights along the road. That said, for the moment I would like to include some lessons that I have learned while attempting various combinations with some of the UI components of Android Studio. In our assignments we may find ourselves working a lot with ListViews and ScrollViews.

LISTVIEW VS SCROLLVIEW

I ran into a mistake by assuming based on the name that a ListView was dependent upon ScrollView to Scroll. This is actually a fundamental misunderstanding of the functionality of these two components. By understanding the differences of these two components we may become better able to understand the Views themselves. I am taking this example as a martyr to encourage my fellow students to to compare components like these more often and increase their understanding of the underlying behavior of the Android Studio Library.

In beginning our examination of these two components, we can make a huge leap in understanding by observing that one is simply an abstraction of the other.

A ListView is a list of Views of the same type. Those views can be pretty much anything, and in my short designing experience discovered through this program I found that creating a ListView of Containers or other intentionally designed Layouts is the most aesthetically please and relatively advanced approach. It is certainly useful to approach programming android in this way to see what we’ll ultimately be capable of creating, since a ListView of simple TextViews seems pretty bland (and a math friend of mine who encouraged me to apply to this published an equations app that looked very bland with a ListView of plain TextViews down a long single column.)

A ScrollView, however, is like a ListView of different types of Views. Where a ListView simply lists the same type of a single item, a ScrollView lists different types of different items. I made a mistake that was very difficult to identify while playing around. I was attempting to create a ListView that scrolls by placing it inside of a ScrollView. From an initial perspective, that doesn’t seem crazy right? Well apparently it is! The effect that I got was a ListView of a static size that gave the illusion of scrolling from the ScrollView. However, it turns that the ListView ITSELF is meant to scroll, rather than the ScrollView scrolling for it. So while the attempt may have appeared successful, I was unable to create a dynamically sized list of views because the ScrollView had simply thrown the ListView in its place with its set size and treated as one of many Views that we were meant to scroll through. Moral of the story: the two work mutually exclusively, and if you want a linear layout within the ScrollView just use the LinearLayout container!

I have a few other hints and strategies to add to this, but I’ll leave it here for now and add to this later. If I helped at all, please leave a comment with feedback below, it would be very appreciated! I would love to talk more with fellow students and I look forward to any opportunity to help. Let me know if you have any questions (related or not) or a request.