First and foremost, the iPhone is way too small. The 3.5 inch screen is nice when I’m holding it 8 inches from my eye, but out and about it feels like my hands belong to Andre the Giant. I try to touch the screen and my thumb covers at least 10% of the surface area. How can you have accurate touches like that? I guess I should file down my thumbs and fingers. It’s so tiny that it killed all two-handed operations for me (especially since you can barely fit two thumbs side by side). I’ll admit that for some pockets, having a tiny screen is nice, but 4.3 inches might be better. This is just too small.

While the screen is too small, I’m happy that Apple has stuck to their decision to have one button that does different things depending on what version of the OS you have and how many times you press it and even how slow your presses are. It’s like opening a Christmas present every time I press the home button. Will I go to the home screen? The search screen? The recent apps? The Siri frontend for Wolfram Alpha? The music app?

To be fair, the small screen on the iPhone did introduce me to some new people. I heard that you can do a five-finger swipe to bring up the multitasking bar, but I couldn’t fit five fingers on the screen, so I had to go to Starbucks to find some fellow Apple users with smaller fingers to try. Then I found out that gesture just works on iPad. When will Apple develop a consistent user experience?

I like the missing software back button that is always in one place like on the Galaxy Nexus. On the iPhone, you can have it sometimes be in the top left with the word “Back” or “Home” or something else, or at the top right with the word “Done” or at the bottom as a “Cancel” button. This forces the user to be much more aware of the UI and whether something is a modal dialog, an action sheet, or whatever else. (Of course, the iPhone still has a power/wake button on the top.)

I also like the lack of indicator light on the iPhone. It’s helpful because I can make sure everyone knows I use Apple products since I have to always hold up my phone to turn it on to check for messages and people can see my important Apple logo and know that I’m creative. Why Samsung included a multi-color indicator light that tells me exactly what I missed without turning on the device, I will never understand.

The rest of the iPhone hardware leaves something to be desired. The Galaxy Nexus feels like a completely and thoughtfully designed product. By comparison, the iPhone is made of glass, something we intuitively think of as fragile. It’s also heavy/dense, giving it the consistant feeling of 80s technology that goes well with the click of the home button (or double click or long click or…). It’s not awful, but you’d think Apple could do better at this point. Some people will like not having the option to remove the back to get at the battery because that makes the iPhone almost as thin and as light as the Galaxy Nexus and gives you an excuse to buy a new phone every year.

The battery life itself is very good. I felt like the iPhone was lasting at least as long as the Galaxy Nexus on a fully charged battery, perhaps even a bit longer in some cases. Of course, I don’t have to worry about having the option of using it on 4G and possibly lowering the battery life.

The camera on the iPhone 4S is definitely worse than the Galaxy Nexus in both terms of front-facing camera (the 4S has a measly VGA camera and the Galaxy Nexus has a front-facing camera capable of 720p… a resolution the iPhone can’t even display) and in speed. If you want to get a picture of where something exciting was happening two seconds ago, the iPhone 4S will not let you down. Just press the shutter button when the scene is composed and you’ll get the scene that happens two seconds later. It’s like time travel.

And let’s talk about iOS 5. There is no question that the software is much improved over previous iterations in terms of copying Android’s notification system (though improved with X close buttons that are polished so much that they shrank to a size where you need a 2-year-old’s pinky to press them) and supporting Twitter. You know an OS has improved when Twitter is a selling point.

Unfortunately, the system still lacks much of the features that Android users enjoy. The majority of iOS users will probably think such criticism is bullshit, but that has always been the case. I imagine it’s probably pretty hard for a person who bought the car that made the most sense to him or her to explain to the person who bought a Prius because it was popular how perception affects the driving experience. The person with a personally-fitting car can attempt to explain why he or she likes a stick or more room, but the Prius owner will just believe that having the car pick gears for you is the best and would never spend enough time with any other car to appreciate the differences.

Still, if the iOS team ever wants to convert (or at least convice) most Android users, they still have quite a bit of work to do here. Then again, they probably don’t (or shouldn’t) care too much about converting Android users over to iOS. All the non-smartphone users out there remain the much bigger prize to go after (for both Apple and Google).

Other things that will sound like nits but drove me crazy with iOS 5 included having widgets only in the notification center. If I am adding a widget, I clearly want to see it where I want it. Why should I have to have it sit somewhere invisible that requires an extra swipe? What’s the different between being on my homescreen and having to open a full weather app (iOS4) and being on the home screen and having to swipe down the notifications to see the weather widget (iOS5)?

Another: why do I have to go into the Google Voice app to make a phone call using my Google Voice number? Google baked in support for alternate dialers into their OS; why didn’t Apple? If they’re worried about competition, why did they finally approve the app after a year-and-a-half and an FCC inquiry? Why is Siri letting people look at my private calendar while my phone is locked? And why on Earth is the web browser not the desktop version of Safari yet!?

The new WiFi-syncing is nice — I love not having to find the proprietary cable. But my god Apple needs help with iTunes. I have to reboot my computer into an OS they support and leave it on while my phone is plugged into a power outlet. As if iTunes weren’t already the worst software on the planet, I also have to waste a bunch of electricity keeping my computer on all the time in one of the two OSes Apple supports just to sync my data?

Apple’s universal support of voice dictation is a joke compared to Ice Cream Sandwich.

Some other authors have noted that iOS is ahead of Android when it comes to custom settings for apps, but I have to disagree. Why do I have to leave an app to go find the settings app to change the settings for the app I was just in? That’s completely illogical. Of course, some apps support changing their settings within the app and others don’t, so now we get back to the inconsistancy problem present in the iOS experience.

When it comes to web browsers, arguably the most important feature of any of these devices, there is no question that Android still has a big edge here. I’ve seen arguments on both sides for why iOS does not support third-party plugins–but doing a simple test proves that much of the web is still inaccessible from iOS. Worse, many pages render as large missing tiles featuring a checkerbox to keep the illusion of scrolling smoothly, even beyond the point at which the actual page ends. You try pinching to zoom and everything just stays fuzzy until your fingers stop moving. How am I supposed to know if the text is large and clear enough if it just zooms in and out on fixed pixels?

You’ll also see a bit of impossibility in iOS when you do simple things like trying to attach a file to an existing email draft or trying to attach a second file or trying to store any arbitrary data on your device. For the most part, iOS 5 does a good job of hiding its limitations, but there are plenty of times that you’ll still hit your head on a wall here and there.

The main problem I have with apps on iOS is that, well, they aren’t on iOS. I try to find my favorite keyboard replacement (SwiftKey) and it’s nowhere to be found. I try to get the ever-useful Wifi Analyzer, also not available. I’ve heard that the entire experience has a lot more polish on iOS, especially with the Twitter integration, so I gave it a try. I found one of my favorite links online and decided to open it on the Galaxy Nexus and the iPhone to verify it looked right. For the Galaxy Nexus, I simply clicked the Chrome to Phone button and it instantly popped up on my device. It looked good, so I long-pressed on the URL within the browser, picked share, selected my favorite Twitter app (hint: not the official one), and sent it with a tweet and a comment. I tried that on iOS, which involved trying to type the long URL in by hand in the stock keyboard. That was a pain, so I decided to long-press it in the Android browser again, share, and send it via Google Voice to the iPhone. I opened it in the iPhone, it looked pretty much the same as on the Galaxy Nexus (though tiny), so I copied the URL, pressed the clicky home button (just once), scrolled to the right through ten screens of apps, opened a Twitter app, pasted it into the new tweet box along with a comment, and tweeted.

It’s these tangibles where Android holds the huge advantage. And just like in sports, you can clearly teach the fundamentals. At some point, Apple may simple have to acknowledge that Android works better than iOS because Android’s entire open concept is woven into the product. Apps can properly communicate to each other without having to know of the other apps. The user can do what he or she wants. Even the launcher app can be replaced. Apple’s strengths are elsewhere; they should embrace that.

Apple has done some very nice work here. Both the iPhone 4S and iOS5 are a new pinnacle of the iOS platform. But in the end, it still comes down to something very simple: which device do I want to use day-to-day? Which phone do I reach for when I’m not doing a review? It’s still an Android phone. Without question.

Keep at it, Apple.

(For those who don’t know, this is a parody on the post MG Siegler did called “An iPhone Lover’s Take On The Galaxy Nexus.” I strongly recommend that you buy the phone that makes the most sense to you, whether it’s an Android phone, an iPhone, a Windows phone, or whatever. Any useful review will highlight the strengths and weaknesses of a given device and never tell you that it’s the one-size-fit-all solution.)

At the end of July, I moved on from Treemo Labs. I already had a one-month contract in place for some simple Android developer work, so I was not taking any time off (well, after the extent to which I had been working, dropping to 8 hours a day felt like taking time off). CBS Interactive also contacted me and talked to me about the possibility of a position there. I flew down to Los Angeles to quickly meet everyone and get a more detailed explanation of what they were looking for (and let them know what I was looking for). It was a great trip, and I finally got to put faces to many of the names I had worked with while at Treemo Labs via email and conference calls.

After a bit of negotiation, I accepted a position at CBS Interactive as a mobile developer, and I started to pack up, reserve an apartment, etc. That’s the position I alluded to at the end of the other post. Well, things changed rather suddenly when some contract agreements got in the way (business protection agreement legalese) that removed the posibility of me holding that position. It was an unfortunate and unexpected turn of events that forced me to take a seat and consider my options.

There is no shortage of mobile development positions out there, but I wasn’t interested in making unexciting apps and I started to question whether moving out of the Seattle area would be worth it for me. I was bombarded by recruiter emails offering great clients, unbeatable opportunities, and pleas to contact all my developer friends on the recruiters’ behalf. A few were interesting on the surface, and I pursued them while simultaneously considering the possibility of working for myself full time.

I created wireframes and documentation for a game I decided to develop (and tweeted about it). With my excitement for that app growing, I determined a timeline for the game with a mid-October alpha and calculated out how long I could live without income. Things were looking very positive. Even if I didn’t make much on the game, I had plenty of time to ensure it was done well before having to consider looking for a job. If nothing else, it would teach me a lot and be another bullet on the resume.

Then I was contacted by ARO, a stealth-mode startup in Seattle. I was intrigued, so I interviewed and found out about their goals–definitely some exciting stuff that could push mobile beyond where it is today. I received an offer from them the next day. Considering their goals, offer, and ability to move fast (vital for anywhere I work), I accepted the position.

So, I am a salaried employee at ARO, working on some awesome stuff and, now that I have time outside of work as well, I’ve been taking on some outside projects. I wrote about reviewing Android for Programmers recently. I am also going to be creating an Android video series for developers (details to come) that I’m very excited about. In the near future, the app I’ve been developing for Android Police will be coming out, and then I’ll spend a little more time on the Disease to Dust game (though I don’t expect a beta this year). I’m sure I’ll spend a little time here and there on other projects (such as prepping Predator Clock Widget for improvements), but life is good right now.

As a reviewer, I found it interesting to see other people’s approaches, offering just a bit of guidance here and there to follow common/best practices used my most Android developers. In one chapter in particular, you learn how to create a game called SpotOn that makes use of property animation (from Honeycomb) to create moving targets. This is a great use of property animation that not only demonstrates a core feature in Honeycomb, it also shows how easily you can use the SDK to accomplish what would otherwise take a lot more code.

If you’re considering learning Android app development or know the basics but want to broaden your understanding, definitely take a look at Android for Programmers: An App-Driven Approach. (And I don’t earn any royalties; I just love the “real code” approach that this book takes.)

The previous tutorial ended with a simple app built that could display a green screen with RenderScript. The next step to making RenderScript more useful is understanding how to interact with it when it’s already running. We want to be able to pass values to the RenderScript code and we also want to pick up on user interactions with the view.

Since we already know how to set a background color within the init method in the RenderScript file, lets build on that by learning how to set it from the Java side. Here’s where our RenderScript101RS class comes in handy. Just add this method:

	public void setBackgroundColor(Float4 color) {
		mScript.set_bgColor(color);
	}

This simple method takes a Float4 and passes it directly to the set_bgColor method. That method is automatically generated in the glue class and lets you set the bgColor value in RenderScript101.rs from Java.

In the RenderScript101View, we need to override onTouchEvent:

    @Override
    public boolean onTouchEvent(MotionEvent event) {
        super.onTouchEvent(event);

        if (mRenderScript == null) {
        	return true;
        }

        if (event.getAction() == MotionEvent.ACTION_DOWN) {
        	final Random random = new Random();
        	final Float4 newColor = new Float4(random.nextFloat(), random.nextFloat(), random.nextFloat(), 1.0f);
        	mRenderScript.setBackgroundColor(newColor);
        }

        return true;
    }

If the RenderScript101RS reference is not yet set, don’t do anything. If it is set, check to see if we’re getting an ACTION_DOWN event (e.g., touching the screen). If we are, then we create a new Float4 using three random float values and one hard-coded to 1.0f (the transparency/opacity to make sure it is fully opaque). Then, we just trigger our newly created setBackgroundColor method with the generated Float4.

If you run the app now, you can tap the RenderScript view to watch it change colors.

Well, that wasn’t too bad, was it? The next part is going to be a bit more challenging, so we will have a crash course on computer graphics terminology.

The Difficult Part

Three-dimensional graphics revolve around vertices (vertex is the singular form). These are essentially points in space that can be used to construct more complicated graphics. Moving the vertices around is called “transformation.” The mathematical construct that accomplishes this is called a “transformation matrix.” There have been many, many books written on these concepts, so it’s impossible to condense everything down into a blog post; however, here are some specific terms for understanding RenderScript for Android:

• ProgramStore – This controls how the framebuffer is used. For instance, you can enable or disable depth testing which controls what happens when one pixel is closer to the camera than another (e.g., whether it should blend or just overwrite).
• Sampler – Samplers are used by ProgramFragments to determine how to get the pixels of a texture
• ProgramFragment – The Android-equivalent of a fragment shader
• ProgramVertex – The Android-equivalent of a vertex shader

If you want to learn more about computer graphics, I recommend learning about OpenGL. It’s extremely valuable to learn and many of the concepts from OpenGL apply to RenderScript.

Here is the updated RenderScript101.rs file:

#pragma version(1)
#pragma rs java_package_name(com.iangclifton.tutorials.renderscript);

#include "rs_graphics.rsh"

float4 gBgColor; // Background color as xyzw 4-part float
rs_allocation gBgImage; // Background image
rs_sampler gLinearClamp; // Sampler used by the program fragment
rs_program_fragment gSingleTextureFragmentProgram; // fragment shader
rs_program_store gProgramStoreBlendNone; // blend none, depth none program store
rs_program_vertex gProgramVertex; // Default vertex shader

static const float3 gBgVertices[4] = {
        { -1.0, -1.0, -1.0 },
        { 1.0, -1.0, -1.0 },
        { 1.0, 1.0, -1.0 },
        {-1.0, 1.0, -1.0 }
};

static void drawBackground() {
	if (gBgImage.p != 0) {
		rs_matrix4x4 projection, model;
		rsMatrixLoadOrtho(&projection, -1.0f, 1.0f, -1.0f, 1.0f, 0.0f, 1.0f);
		rsgProgramVertexLoadProjectionMatrix(&projection);

		rsMatrixLoadIdentity(&model);
		rsgProgramVertexLoadModelMatrix(&model);

		rsgBindTexture(gSingleTextureFragmentProgram, 0, gBgImage);

	    rsgDrawQuad(
			gBgVertices[0].x, gBgVertices[0].y, gBgVertices[0].z,
			gBgVertices[1].x, gBgVertices[1].y, gBgVertices[0].z,
			gBgVertices[2].x, gBgVertices[2].y, gBgVertices[0].z,
			gBgVertices[3].x, gBgVertices[3].y, gBgVertices[0].z
		);
	} else {
		rsgClearColor(gBgColor.x, gBgColor.y, gBgColor.z, gBgColor.w);
	}
}

void init() {
	gBgColor = (float4) { 0.0f, 1.0f, 0.0f, 1.0f };
	rsDebug("Called init", rsUptimeMillis());
}

int root() {
	rsgBindProgramVertex(gProgramVertex);
	rsgBindProgramFragment(gSingleTextureFragmentProgram);
	rsgBindProgramStore(gProgramStoreBlendNone);

	drawBackground();
	return 16;
}

Note that I’ve updated all of the global variables to start with “g” in order to keep things a bit more clear. The root() method has been updated to bind the ProgramVertex, ProgramFragment, and ProgramStore right away. Looking at the drawBackground() method, you can see that the old code falls under the else statement. Everything else happens when gBgImage.p is not equal to zero (in other words, the gBgImage has been set).

We create a four-by-four projection matrix and model matrix. The projection matrix is passed by reference and is turned into an orthographic matrix with rsMatrixLoadOrtho. An orthographic matrix is essentially a flat representation of points in space (e.g., the HUD in a first-person shooter). Most commonly, the points are -1 to +1 in each dimension (though we use 0-1 for one here). In graphics hardware, it is common to represent everything with floats because they give more precision than an arbitrary system (e.g., think of how colors are commonly represented by 0-255; in OpenGL and other languages, they are represented by floats because hardware can create an unknown number of unique colors in the future). Then the matrix is passed to rsgProgramVertexLoadProjectionMatrix so that the 3D points can be flattened to 2D points.

We pass model by reference to rsMatrixLoadIdentity which makes model an identity matrix. An identity matrix is essentially a matrix that does not affect other matrices in multiplication (think of it like a 1 where 1 times X results in X). With this identity matrix, we call rsgProgramVertexLoadModelMatrix to avoid manipulating the vertices.

Next, we call rsgBindTexture, which takes a program fragment, an unsigned int (slot), and an rs_allocation. This is essentially where we are setting up our texture (Bitmap) to be drawn. Now that the texture has been set up, we can draw the quad on which it will appear. The gBgVertices are defined on lines 13-18 but we’re essentially passing the top left, top right, bottom left, and bottom right points of the screen. The Z position for all of them is -1, which we set as the maximum Z-depth in our rsMatrixLoadOrtho call. Therefore, this texture spans the whole view but appears at the very “back” of it.

Now we have to update RenderScript101RS to set these new values:

package com.iangclifton.tutorials.renderscript;

import android.content.res.Resources;
import android.graphics.Bitmap;
import android.renderscript.Allocation;
import android.renderscript.Float4;
import android.renderscript.Matrix4f;
import android.renderscript.ProgramFragment;
import android.renderscript.ProgramFragmentFixedFunction;
import android.renderscript.ProgramStore;
import android.renderscript.ProgramVertex;
import android.renderscript.ProgramVertexFixedFunction;
import android.renderscript.RenderScriptGL;
import android.renderscript.Sampler;

public class RenderScript101RS {

	private Sampler mLinearClamp;
    private ProgramStore mProgramStoreBlendNone;
    private ProgramVertex mProgramVertex;
	private RenderScriptGL mRS;
	private ScriptC_RenderScript101 mScript;
    private ProgramFragment mSingleTextureFragmentProgram;

	public RenderScript101RS(RenderScriptGL rs, Resources res, int resId) {
		mRS = rs;
		mScript = new ScriptC_RenderScript101(rs, res, resId);

		initProgramStore();
		initSampler();
		initProgramFragment();
		initProgramVertex();
		mRS.bindRootScript(mScript);

	}

	public void setBackgroundBitmap(Bitmap bitmap) {
		if (bitmap == null) {
			return;
		}
		final Allocation bitmapAllocation = Allocation.createFromBitmap(mRS, bitmap, Allocation.MipmapControl.MIPMAP_NONE, Allocation.USAGE_GRAPHICS_TEXTURE);
		mScript.set_gBgImage(bitmapAllocation);
	}

	public void setBackgroundColor(Float4 color) {
		mScript.set_gBgColor(color);
	}

	private void initProgramFragment() {
        final ProgramFragmentFixedFunction.Builder pfBuilder = new ProgramFragmentFixedFunction.Builder(mRS);
        pfBuilder.setTexture(ProgramFragmentFixedFunction.Builder.EnvMode.REPLACE, ProgramFragmentFixedFunction.Builder.Format.RGBA, 0);
        mSingleTextureFragmentProgram = pfBuilder.create();
        mScript.set_gSingleTextureFragmentProgram(mSingleTextureFragmentProgram);
	}

    private void initProgramStore() {
        mProgramStoreBlendNone = ProgramStore.BLEND_NONE_DEPTH_NONE(mRS);
        mScript.set_gProgramStoreBlendNone(mProgramStoreBlendNone);
    }

	private void initProgramVertex() {
        ProgramVertexFixedFunction.Builder pvb = new ProgramVertexFixedFunction.Builder(mRS);
        mProgramVertex = pvb.create();
        ProgramVertexFixedFunction.Constants pva = new ProgramVertexFixedFunction.Constants(mRS);
        ((ProgramVertexFixedFunction)mProgramVertex).bindConstants(pva);
        Matrix4f proj = new Matrix4f();
        proj.loadProjectionNormalized(1, 1);
        pva.setProjection(proj);
        mScript.set_gProgramVertex(mProgramVertex);
	}

	private void initSampler() {
		mLinearClamp = Sampler.CLAMP_LINEAR(mRS);
		mScript.set_gLinearClamp(mLinearClamp);
	}
}

Looking at the constructor, we can see that first the ProgramStore is initialized, then the Sampler, then the ProgramFragment, and finally the ProgramVertex. Each of these has an init___ method that you can look at. The initProgramStore just sets a ProgramStore that does no blending and no depth testing since they are not needed for the background. Then initSampler just creates a CLAMP_LINEAR Sampler. The initProgramFragment method creates a simple fragment shader. Lastly, the initProgramVertex method creates a simple ProgramVertexFixedFunction (vertex shader) without any custom GLSL.

If you’ve never done any OpenGL or other 3D computer graphics, you’re probably lost by now. Sorry! It would take a few hundred pages to truly clarify all of this, but hopefully some of it is making sense.

Finally, we just updated the RenderScript101View class’s onTouchEvent method:

    @Override
    public boolean onTouchEvent(MotionEvent event) {
        super.onTouchEvent(event);

        if (mRenderScript == null) {
        	return true;
        }

        if (event.getAction() == MotionEvent.ACTION_DOWN) {
        	mRenderScript.setBackgroundBitmap(BitmapFactory.decodeResource(getResources(), R.drawable.icon));
        }

        return true;
    }

We simply update this method so that tapping the view will set the background Bitmap to the default icon. Yup, it looks terrible, but you’ve now experimented with the key features of RenderScript and you might even understand a thing or two.

Note: The source code for this tutorial is available in on GitHub.

We’ll be creating four files:

• RenderScript101.rs – The actual RenderScript code
• RenderScript101RS.java – A helper class to simplify interaction with RenderScript
• RenderScript101View.java – An RSSurfaceView that handles setting up the view and can capture touch events
• RenderScript101Activity.java – Main Activity and it’s even simpler than a typical one

When you create a new project, select a target of at least 11 and let Eclipse generate the Activity for you (ignore it for now). We’re diving right into the actual RenderScript code, so create the RenderScript101.rs text file (in the same folder/package as the Activity). The first things we have to do are to specify the version of RenderScript we’re using (1) and specify the package (I’m using com.iangclifton.tutorials.renderscript).

#pragma version(1)
#pragma rs java_package_name(com.iangclifton.tutorials.renderscript);

#include "rs_graphics.rsh"

float4 bgColor; // Background color as xyzw 4-part float

static void drawBackground() {
	rsgClearColor(bgColor.x, bgColor.y, bgColor.z, bgColor.w);
}

void init() {
	bgColor = (float4) { 0.0f, 1.0f, 0.0f, 1.0f };
	rsDebug("Called init", rsUptimeMillis());
}

int root() {
	drawBackground();
	return 16;
}

When your RenderScript code is first initialized, the init() method will run once. Then the root() method will run repeatedly. The return value for the root method is an int specifying the number of milliseconds before root() should run again.

Looking first at init(), you can see we are setting the bgColor (a 4-part float defined on line 6) to 0, 1, 0, 1. This is in RGBA format, so we’re saying no red, maximum green, no blue, and full opacity. In the next line we call rsDebug with the message “Called init” and the current uptime in milliseconds. Think of this as an easy way to call Log.d("RenderScript", your_message_here). This call is not necessary, but you should definitely get used to adding debug messages into your RenderScript early on. For reference, rsDebug is defined in rs_core.rsh and rsUptimeMillis is defined in rs_time.rsh (both are available in your sdk directory under platforms/android-11/renderscript/include and are included automatically for you).

Jumping down to the root method, we see that it calls drawBackground() and returns 16 (16ms for a frame is close to 60 frames per second). The drawBackground() call only does one thing right now; it clears the screen using the bgColor we set in init(). The rsgClearColor method takes four floats (R, G, B, A) and is defined in rs_graphics.rsh. Remember that RenderScript can also be used for calculations, so you have to specifically include the graphics header file (line 4). If you’re new to computer graphics, the use of the x, y, z, and w properties of bgColor might seem strange. Without getting into the details, this is a convention in graphics where a four-part float is represented with these four letters (as you can probably guess, x, y, and z are typically coordinates. The w is usually for projection where the values are actually represented as x/w, y/w, and z/w. There’s a lot more to it than that, but the important part is knowing the letters right now).

Alright, so all that code does is define a background color from four floats (x, y, z, and w) and then it clears the screen to that color every 16-ish milliseconds. Pretty simple, but it’s a good start.

Next, you want to create the RenderScript101RS.java file to simplify interaction with the RenderScript. It should look like this:

package com.iangclifton.tutorials.renderscript;

import android.content.res.Resources;
import android.renderscript.RenderScriptGL;

public class RenderScript101RS {
    private RenderScriptGL mRS;
    private ScriptC_RenderScript101 mScript;

    public RenderScript101RS(RenderScriptGL rs, Resources res, int resId) {
    	mRS = rs;
    	mScript = new ScriptC_RenderScript101(rs, res, resId);
    	mRS.bindRootScript(mScript);
    }
}

All we are doing for now is setting a reference to the RenderScriptGL (the graphics derivative of RenderScript), instantiating the “glue” class ScriptC_RenderScript101, and binding the script. The glue class is generated for you by Eclipse. If you have automatic builds on and saved the .rs file we just worked on, you might have noticed the class being added to the gen folder along with your R class. This glue class lets you interact with your RenderScript code via Java (such as if you want to set the background color from Java instead of within the RenderScript). We’ll get to it later. The bindRootScript() method simply tells Android which script should handle rendering to the surface.

Next up, RenderScript101View.java:

package com.iangclifton.tutorials.renderscript;

import android.content.Context;
import android.renderscript.RSSurfaceView;
import android.renderscript.RenderScriptGL;

public class RenderScript101View extends RSSurfaceView {
	private Context mContext;
	private RenderScript101RS mRenderScript;
	private RenderScriptGL mRS;

	public RenderScript101View(Context context) {
	    super(context);
	    mContext = context;
	    ensureRenderScript();
    }

	private void ensureRenderScript() {
		if (mRS == null) {
			final RenderScriptGL.SurfaceConfig sc = new RenderScriptGL.SurfaceConfig();
			mRS = createRenderScriptGL(sc);
		}
		if (mRenderScript == null) {
			mRenderScript = new RenderScript101RS(mRS, mContext.getResources(), R.raw.renderscript101);
		}
	}
}

This is the RSSurfaceView that essentially works like other views in Android. In fact, it extends SurfaceView, so if you’ve used SurfaceView or GLSurfaceView, you have a pretty good idea of what this is.

All we’re doing here is following the convention of having an ensureRenderScript() method that sets up the RenderScriptGL and RenderScript101RS class instances. This method can be called when the view is first set up or when it changes. If mRS is null, we create a SurfaceConfig (this can be used to control the bit-depth for colors, the depth buffer, etc., but we’re just using the defaults). We use the SurfaceConfig in our call to createRenderScriptGL() to generate the RenderScriptGL. If the mRenderScript reference is null, we simply construct a new one by passing the RenderScriptGL, a reference to the Resources, and the resource identifier for our RenderScript file (this bytecode file is automatically generated for you in res/raw).

And, finally, RenderScript101Activity.java:

package com.iangclifton.tutorials.renderscript;

import android.app.Activity;
import android.os.Bundle;

public class RenderScript101Activity extends Activity {

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(new RenderScript101View(this));
    }
}

Yeah, that’s all there is to this Activity. We’re simply constructing a new RenderScript101View and using it as the layout. Run the app on your Honeycomb device and you should see a horrendous green screen like this:

If your eyes are burning, you did it right. If you don’t see a green screen, check DDMS for anything suspicious in the logs.

That concludes part one of the RenderScript 101 tutorial. Next up, RenderScript 101, Part 2: RenderScript Interaction.

I ended up at Treemo Labs by way of a buddy I had worked with at Western Washington University where we were web developers. I had finished my teaching internship, but the economy was weak and teaching jobs (particularly for someone with such limited experience) were not easy to come by. Fortunately, I started up at Treemo doing web development and ended up leaning toward my current passion, mobile development.

I truly enjoy learning and tackling new challenges as well as working with technology and sharing that knowledge and experience with others.  One of the great things about mobile development is the unbelievable pace of change.  It wasn’t long ago that I could name all relevant Android devices and their specs, now it’s simply impossible to keep up.  Now I focus more on the software side of things, playing with all the newest OS features both announced and slipped in.

When I started at Treemo, the G1 and iPhone 3G were the primary devices.  The G1 could do far more than the iPhone and even had some features current iPhones still don’t have, but the iPhone’s narrower list of capabilities was generally executed much more smoothly.  The contrast was intriguing to me–and still is.  In 2009, we saw the Palm Pre come and go, the 3G update to the 3GS, and the G1′s angular cousin, the Motorola Droid, take off.  I had the opportunity to work with all of these devices and many more while at Treemo.  I also got to see the evolution of my skills alongside these changing devices.  I worked on the CBS News app for both Android and iOS as my intro into mobile development, not a bad start!  I developed a variety of Android apps (CNET News, Survivor, Rick Steves’ Audio Europe, etc.), learning from each experience.  Even the last app I developed at Treemo Labs was an opportunity to learn and grow; developing Big Brother gave me the chance to learn more about Honeycomb (and RenderScript in particular) than I would have thought possible, given the time constraints.

As much as I enjoyed working with the people at Treemo, it came time for me to move on. I won’t go into the details, but a lot of signs pointed to the need for a change. Fortunately, Android developers are in high demand, and an excellent opportunity has already come my way. I’ll have a separate post about that later on.

I wrote a review called [Review] ASUS Eee Pad Transformer – A Month With A Tablet In Disguise at Android Police, so I will not go into excessive detail here. If you are looking for a tablet that can actually be used to create real content, particularly for typing on the go, take a look at the Asus Eee Pad Transformer.

OMG! The emulator is slow!

There are two things to note here: the default AVDs tend to have limited resources and the devices you’re targeting are likely running with a different chipset than the computer you’re developing on. The first limitation can be easily overcome; the second is a much bigger issue, particularly with Android 3.x and attempting to develop for Honeycomb tablets without actually having a Xoom, Asus Eee Pad Transformer, etc. Currently, it’s not very feasible to develop a 3.x app without a tablet.

Back to that first limitation: When creating a new AVD, you can specify hardware settings, which can dramatically improve performance. The most important setting is the device RAM size; I tend to want the emulator to be as fast as possible, relying on on-device testing for a sense of “real-world speed,” so I usually give my phone emulators 512MB of RAM. That’s the equivalent of most good smartphones from 2010. The 1.x AVDs seem to run fine on 256MB, so you can potentially drop to that if your machine is limited (the Motorola Droid/Milestone had 256MB of RAM as well). You can also try upping the cache partition size (128MB is a good start) and the max VM application heap size (48 is plenty) for a minor improvement.

LinearLayout mistakes

LinearLayout is a very useful and very simple ViewGroup. It essentially puts one View after another either horizontally or vertically, depending on the orientation you have set. Set an orientation!

LinearLayout defaults to horizontal, but you should always manually specify an orientation. It’s very easy to throw two Views in there and not see one because the first View is set to match_parent for width. That said, LinearLayout also processes layouts linearly, which is what you’d expect, but that means that setting a child View to match_parent can leave no room for subsequent Views. If you aren’t seeing one of your Views in a LinearLayout, verify you’ve set the orientation and that none of the Views are taking up all the available space. Within a LinearLayout, you should generally rely on layout_weight to “grow” the View. Here’s an example:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:layout_height="match_parent"
  android:layout_width="match_parent"
  android:orientation="vertical"
>
    <SomeView
      android:id="@+id/childview1"
      android:layout_height="0px"
      android:layout_weight="2"
      android:layout_width="match_parent"
    />

    <SomeView
      android:id="@+id/childview2"
      android:layout_height="0px"
      android:layout_weight="3"
      android:layout_width="match_parent"
    />
</LinearLayout>

The heights are set to 0, but both child Views have weights. The first has a weight of 2 and the second has a weight of 3. Out of a total of 5, the first is taking 2 (40%) and the second gets 3 (60%), so their heights will actually use that portion of the parent View’s space (if that View has a 100px height, the first child will be 40px tall). The weights are relative, so you can set whatever values make sense for you. In this example, the second layout could have had a set height and no weight and the first could have had a weight of 1, which would have made the first take up all space that the second didn’t use.

Stupid Android! It keeps restarting my Activity!

The default behavior when a configuration change happens (e.g., orientation change, sliding out the keyboard, etc.) is to finish the current Activity and restart it with the new configuration. If you’re not getting any dynamic data, such as loading content from the web, this means you probably don’t have to do any work to support configuration changes; however, if you are loading other data, you need to pass it between configuration changes. Fortunately, there’s already a great post on Faster screen orientation changes. Read it and remember that you should not pass anything via the config change methods that is tied to the Activity or Context.

Density

Density should only be considered in terms of density not size. In other words, don’t decide that MDPI means 320px wide. It doesn’t. It means that the device has around 160dpi like the G1 (320px wide) and the Xoom (1280px wide). Fortunately, you can combine multiple qualifiers for your folders to give precise control, so you can have a drawable-large-land-hdpi/ containing only drawables that are used on large HDPI devices that are in landscape orientation.

One other important thing to note: Support for different screen sizes and densities came in Android 1.6. Android 1.5 devices are all MDPI devices, but they don’t know to look in drawable-mdpi/ because there were no different densities then. So, if you’re supporting Android 1.5, your MDPI drawables should go in drawables/. If your minSdkVersion is 1.6 or above, put the MDPI drawables in drawable-mdpi/.

What the heck is ListView doing?

A full explanation of ListView would take quite a while, but here’s a quick summary: A ListView’s associated Adapter’s getView method is called for each child View it needs to construct to fill the ListView. If you scroll down, the top View that leaves the screen is not garbage collected but is instead passed back to the getView method as the “convertView” (second param). Use this View! If you don’t, not only does it need to be garbage collected, you have to inflate new Views. You should also use the ViewHolder paradigm where you use a simple class to store View references to avoid constant findViewById() calls. Here’s an example:

@Override
public View getView(int position, View convertView, ViewGroup parent) {
    final ViewHolder holder;
    if (convertView == null) {
        convertView = mInflater.inflate(R.layout.some_layout, null);
        holder = new ViewHolder();
        holder.thumbnail = (ImageView) convertView.findViewById(R.id.thumbnail);
        holder.title = (TextView) convertView.findViewById(R.id.title);
        convertView.setTag(holder);
    } else {
        holder = (ViewHolder) convertView.getTag();
    }

    final MyObject obj = (MyObject) getItem(position);
    holder.thumbnail.setImageDrawable(obj.getThumbnail());
    holder.title.setText(Html.fromHtml(obj.getTitle()));

    return convertView;
}

/**
 * Static ViewHolder class for retaining View references
 */
private static class ViewHolder {
    ImageView thumbnail;
    TextView title;
}

This method is first checking if the convertView exists (when the ListView is first laid out, convertView will not exist). If it doesn’t exist, a new layout is inflated with the LayoutInflater. A ViewHolder object is instantiated and the View references are set. Then, the holder is assigned to the View with the setTag method (which essentially allows you to associate an arbitrary object with a View). If the convertView already exists, all that has already been done, so you just have to call getTag() to pull that ViewHolder out. The “bulk” of the method is just grabbing MyObject (whatever object your Adapter is connecting to) and setting the thumbnail ImageView and the title TextView. You could also make the ViewHolder fields final and set them in the constructor, but I tried to keep this example as simple as possible. This method no longer requires View inflation while scrolling nor does it require looking through the Views for specific IDs each time. This little bit of work can make a huge different on scrolling smoothness.

One last thing about ListViews… never set the height of a ListView to wrap_content. If you have all your data locally available, it might not seem so bad, but it becomes particularly troublesome when you don’t. Consider the above example but instead of the setImageDrawable call, it triggers an image download (though it’s better to have the Adapter handle that). If you use wrap_content on your ListView, this is what happens: The first getView call is done, convertView is null, and position 0 is loaded. Now, position 1 is loaded, but it is passed the View you just generated for position 0 as its convertView. Then position 2 is loaded with that same View, and so on. This is done to lay out the ListView since it has to figure out how tall it should be and you didn’t explicitly tell it. Once it has run through all of those positions, that View is passed back to position 0 for yet another getView call, and then position 1 and on are loaded with getView and no convertView. You’re going to end up seeing getView called two or three times as often as you would have expected. Not only does that suck for performance, but you can get some really confusing issues (e.g., if you had been passing a reference to an ImageView with an image download request, that same ImageView could be tied to all of the download requests, causing it to flicker through the images as they return).

A very common UI pattern for lists and menus is to have some kind of icon on the left, text in the center, and an arrow or other indicator on the right to signify that it can be tapped. In this first example, the layout is created in the most obvious way: a single vertical LinearLayout, containing three horizontal LinearLayouts. Each of those LinearLayouts contains an ImageView, a TextView (with a weight of 1 to stretch as needed), and another ImageView.

We can profile this layout with Hierarchy Viewer to see that it consists of 18 views, the measure time takes 2.399ms, layout uses just .36ms, and drawing time is 9.322ms. Not bad, but not great, especially when you consider only half the screen was used. The hierarchy view shows the level of depth, which is really just 3 levels for this layout (the rest is from the system), but it’s easy to see how this approach can start to create a lot more Views with more depth than desired.

Here’s the sample XML:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:background="#FF333333"
  android:layout_height="match_parent"
  android:layout_width="match_parent"
  android:orientation="vertical"
>
    <LinearLayout
      android:background="#FF003333"
      android:gravity="center_vertical"
      android:layout_height="wrap_content"
      android:layout_width="match_parent"
      android:orientation="horizontal"
      android:padding="5dp"
    >
        <ImageView
          android:layout_height="wrap_content"
          android:layout_width="wrap_content"
          android:src="@drawable/ic_contact_picture"
        />
        <TextView
          android:layout_height="wrap_content"
          android:layout_marginLeft="5dp"
          android:layout_weight="1"
          android:layout_width="wrap_content"
          android:text="@string/menu_item_1"
        />
        <ImageView
          android:layout_height="wrap_content"
          android:layout_width="wrap_content"
          android:src="@drawable/ic_menu_forward"
        />
    </LinearLayout>
    <LinearLayout
      android:background="#FF006666"
      android:gravity="center_vertical"
      android:layout_height="wrap_content"
      android:layout_width="match_parent"
      android:orientation="horizontal"
      android:padding="5dp"
    >
        <ImageView
          android:layout_height="wrap_content"
          android:layout_width="wrap_content"
          android:src="@drawable/ic_contact_picture_2"
        />
        <TextView
          android:layout_height="wrap_content"
          android:layout_marginLeft="5dp"
          android:layout_weight="1"
          android:layout_width="wrap_content"
          android:text="@string/menu_item_2"
        />
        <ImageView
          android:layout_height="wrap_content"
          android:layout_width="wrap_content"
          android:src="@drawable/ic_menu_forward"
        />
    </LinearLayout>
    <LinearLayout
      android:background="#FF003333"
      android:gravity="center_vertical"
      android:layout_height="wrap_content"
      android:layout_width="match_parent"
      android:orientation="horizontal"
      android:padding="5dp"
    >
        <ImageView
          android:layout_height="wrap_content"
          android:layout_width="wrap_content"
          android:src="@drawable/ic_contact_picture_3"
        />
        <TextView
          android:layout_height="wrap_content"
          android:layout_marginLeft="5dp"
          android:layout_weight="1"
          android:layout_width="wrap_content"
          android:text="@string/menu_item_3"
        />
        <ImageView
          android:layout_height="wrap_content"
          android:layout_width="wrap_content"
          android:src="@drawable/ic_menu_forward"
        />
    </LinearLayout>
</LinearLayout>

Some of the attributes in this layout should be defined externally in a real application, but I’ve defined them all here to make it clear how they’re defined when we optimize the layout.

The big improvement to be made here is to eliminate each of the horizontal LinearLayouts, replacing them with the TextViews. We can also eliminate the two ImageViews by using the android:drawable properties. Here’s the new XML:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:background="#FF333333"
  android:layout_height="match_parent"
  android:layout_width="match_parent"
  android:orientation="vertical"
>
    <TextView
      android:background="#FF003333"
      android:drawableLeft="@drawable/ic_contact_picture"
      android:drawablePadding="5dp"
      android:drawableRight="@drawable/ic_menu_forward"
      android:gravity="center_vertical"
      android:layout_height="wrap_content"
      android:layout_width="match_parent"
      android:padding="5dp"
      android:text="@string/menu_item_1"
    />
    <TextView
      android:background="#FF006666"
      android:drawableLeft="@drawable/ic_contact_picture_2"
      android:drawablePadding="5dp"
      android:drawableRight="@drawable/ic_menu_forward"
      android:gravity="center_vertical"
      android:layout_height="wrap_content"
      android:layout_width="match_parent"
      android:padding="5dp"
      android:text="@string/menu_item_2"
    />
    <TextView
      android:background="#FF003333"
      android:drawableLeft="@drawable/ic_contact_picture_3"
      android:drawablePadding="5dp"
      android:drawableRight="@drawable/ic_menu_forward"
      android:gravity="center_vertical"
      android:layout_height="wrap_content"
      android:layout_width="match_parent"
      android:padding="5dp"
      android:text="@string/menu_item_3"
    />
</LinearLayout>

This drops from 18 Views to 9. Although you can’t necessarily compare exact values for measure/layout/draw times between layouts (you’re never going to have a perfect benchmarking environment), it’s worth noting that the measure time is .952ms (vs. 2.399ms with the 18 Views), layout is .171ms (vs. .36ms), and drawing time is 8.347ms (vs. 9.322ms). That means the overall time went from 12.081ms to 9.47ms (2.611ms difference). Raw numbers are nice, but sometimes a visual says things better:

From that image alone, it’s clear that the layout is much simpler hierarchically and in total Views. But how does that affect the actual display? Compare the 18 View version (left) with the 9 View version (right):

Knowing how to make use of each View can simplify your layouts both for you creating them and for the device calculating their positions and displaying them. Reviewing each of your layouts in Hierarchy Viewer is a good habit to have. Although your improvements won’t always be as drastic as shown in this post (especially once you’ve become familiar with the Views in the SDK and common UI patterns), seeing the hierarchical structure of your layout can definitely help catch areas that need improvement.

Wait a minute! That’s a ridiculously small number! Yes, Justin decided to use a very scientific process of finding tablet apps via “market descriptions, youtube searches, google searches” and he decided to exclude “games or existing Android apps that are just upconverted to take advantage of the existing screen real estate.” In fact, Justin (indirectly) admits to not even owning a Xoom: “Short of buying a Xoom, I am unable to find a decent way to scour the Android marketplace other than browsing it.” People on Twitter have offered suggestions (me included) for the list that haven’t been added. In other words, Apple Insider (among other sites) has taken an inaccurate listing of Android tablet apps that was written by someone with an artificial criteria and who doesn’t even own a Xoom…. and treated it like fact. Oh internet…

Here’s the problem (or at least one of them) with that: Android doesn’t just have two device types like iOS (iPod/iPhone vs. iPad). It has multiple physical sizes (small, medium, large, x-large), multiple densities (ldpi, mdpi, hdpi, xhdpi), and other attributes developers can use to customize an app for different devices. Android automatically selects the correct assets (layouts, images, etc.) based on the device and even scales as needed (a medium-density drawable is scaled up 50% for hdpi devices). Therefore, all apps targeting Android 1.6 and above are inherently “universal binaries” rather than being the complete pixel-by-pixel phone-app-on-a-tablet experience that most iOS apps are. In fact, just 8% of iOS apps were universal binaries as of December.

I think it’s fair to say there are more iOS apps designed specifically for iPad than Android apps designed specifically for Android tablets. It’s also fair to say that the average Android app makes better use of the space on a tablet than the average iPhone app on an iPad. I am guessing that no Android tablet in the near future will sell more than the iPad, but it’s likely that several will come to market and their combined numbers will soon challenge the iPad. That growth will fuel better tablet experiences and the initial limited number of apps will grow exponentially.

In other words, Justin’s article is not just inaccurate and misleading; it will be irrelevant soon.