This post documents some fundamentals of Android programming, for someone who’s already been programming in other languages. Here are things you should know:
Rage and Rant
The Android layout XML markup basically re-invents CSS. Fuck you, Google. Why can’t you have just extended open standards, and made it easier on all of us? “Do the Right Thing,” my sainted ass.
XML attribute to make your view be as big as its parent?
match_parent. Heard of
divs, Google? What’s wrong with fucking HTML
Bah. Anyway, smoke on that a bit first, and now let’s go on.
Activity is a class in the Android SDK. An activity is responsible for managing user interaction with a screen of information.
- Every widget is an instance of the
View class or one of its subclasses (such as
ViewGroup is a
View subclass that contains and arranges other widgets.
- Other ViewGroup subclasses are FrameLayout, TableLayout, and RelativeLayout.
- FrameLayout is the simplest ViewGroup and does not arrange its children in any particular manner. The arrangement will use the
android:layout_gravity attribute, instead of the ViewGroup’s pre-determined layout.
- Sometimes, you want your widgets to have “resource IDs.” To generate a resource ID for a widget, you include an android:id attribute in the widget’s definition.
- There is a + sign in the values for attributes that you are creating and not merely referencing.
- Some class names are food-themed. Why?
- Everything on screen is a “view”; that is, a
View. So to create an interaction, you have to get the view via its ID (that you set in a corresponding resource XML file), and then call a method on the appropriately-casted View object that sets an event listener. This means you have to learn a whole new vocabulary of event listener methods, instead of finding pleasantly that the methods are named the same as, oh I don’t know, some library that already implements event-based actions for a visual interface, now I wonder where one could find such a language…
- Pulling things into the view involves specifying them in your
content_*.xml file. These things are pulled in either as strings (
android:text=”@string/…) or images (
android:drawableLeft=”@drawable/…) I guess there are other possible “drawable” values you can set to put your images in different parts of a given widget. At least one of them is
drawableEnd, which I am guessing intelligently moves the right-most image object to the left-most spot, for right-to-left screens.
- The type of view used depends on the device configuration and other factors. The resources corresponding to each of these is in its own, appropriately-named, folder. There is a list of configuration qualifiers that Android recognizes and the pieces of the device configuration that they refer to.
Log.d(String, String, Throwable) signature logs the entire stack trace at the point the
Log.d function was called, if the third argument is simply a “blank” instance of
- One can debug using “exception breakpoints” which is nice – and is in fact a feature of Byebug too, one I wasn’t aware of.
I’ll say this about statically-typed languages, though – it’s nice to have an IDE that can do fairly complex code analysis. Knowing that static fields can be converted to local variables? Gold.
Some of the IDE actions could equally be done in dynamically interpreted languages – finding the library that defines a symbol name, say, or knowing that a defined variable has never been used (which is in fact something Perl will tell you in warnings mode, so it’s a pity other languages aren’t as good about it. (I’m looking at you, Ruby.))
- Oh yay. Java won’t apply the modulus operator to negative numbers to return a positive value. Which is exactly how none of the dynamically interpreted languages do it. Fun.
- To rotate, hit Fn-Ctrl-F12
Some of these resources will probably come in handy later: