Welp, it looks like it has been about a year since my last post, so I figured I’d get something up here before a full year went by. Today, I’ll be going over some code I put together to make a paged level selection screen with LibGDX’s Scene2D package. I endearingly refer to this as Angry Birds style, but it’s obviously not exclusive to Angry Birds and has found it’s way into countless games and apps. Anyway, continuing on…

First of all, a screenshot of what we will be making. Note, I am not an artist, so I will just be using the basic skin as can be found in the LibGDX Tests project. You’ll obviously want to use your imagination to make it nicer looking.

There, isn’t that nice? Still pictures don’t really do it justice but I am on a time limit here so they’ll have to do.

The best part is, Scene2D already provides most everything we need to accomplish this so we’ll have very minimal code to introduce the concept of pages, handle centering on the nearest page after completing a scroll or fling, and loading a button will all of our fancy images and text.

First, we’ll make a subclass of ScrollPane so we can add the concept of pages and centering on the nearest page.

package com.example.gdx.scene2d;

import com.badlogic.gdx.math.MathUtils;
import com.badlogic.gdx.scenes.scene2d.Actor;
import com.badlogic.gdx.scenes.scene2d.ui.ScrollPane;
import com.badlogic.gdx.scenes.scene2d.ui.Skin;
import com.badlogic.gdx.scenes.scene2d.ui.Table;
import com.badlogic.gdx.utils.Array;
import com.esotericsoftware.tablelayout.Cell;

import com.badlogic.gdx.math.MathUtils;
import com.badlogic.gdx.scenes.scene2d.Actor;
import com.badlogic.gdx.scenes.scene2d.ui.ScrollPane;
import com.badlogic.gdx.scenes.scene2d.ui.Skin;
import com.badlogic.gdx.scenes.scene2d.ui.Table;
import com.badlogic.gdx.utils.Array;
import com.esotericsoftware.tablelayout.Cell;

public class PagedScrollPane extends ScrollPane {

	private boolean wasPanDragFling = false;

	private float pageSpacing;

	private Table content;

	public PagedScrollPane () {
		super(null);
		setup();
	}

	public PagedScrollPane (Skin skin) {
		super(null, skin);
		setup();
	}

	public PagedScrollPane (Skin skin, String styleName) {
		super(null, skin, styleName);
		setup();
	}

	public PagedScrollPane (Actor widget, ScrollPaneStyle style) {
		super(null, style);
		setup();
	}

	private void setup() {
		content = new Table();
		content.defaults().space(50);
		super.setWidget(content);		
	}

	public void addPages (Actor... pages) {
		for (Actor page : pages) {
			content.add(page).expandY().fillY();
		}
	}

	public void addPage (Actor page) {
		content.add(page).expandY().fillY();
	}

	@Override
	public void act (float delta) {
		super.act(delta);
		if (wasPanDragFling && !isPanning() && !isDragging() && !isFlinging()) {
			wasPanDragFling = false;
			scrollToPage();
		} else {
			if (isPanning() || isDragging() || isFlinging()) {
				wasPanDragFling = true;
			}
		}
	}

	@Override
	public void setWidget (Actor widget) {
		throw new UnsupportedOperationException("Use PagedScrollPane#addPage.");
	}
	
	@Override
	public void setWidth (float width) {
		super.setWidth(width);
		if (content != null) {
			for (Cell cell : content.getCells()) {
				cell.width(width);
			}
			content.invalidate();
		}
	}

	public void setPageSpacing (float pageSpacing) {
		if (content != null) {
			content.defaults().space(pageSpacing);
			for (Cell cell : content.getCells()) {
				cell.space(pageSpacing);
			}
			content.invalidate();
		}
	}

	private void scrollToPage () {
		final float width = getWidth();
		final float scrollX = getScrollX();
		final float maxX = getMaxX();

		if (scrollX >= maxX || scrollX <= 0) return;

		Array<Actor> pages = content.getChildren();
		float pageX = 0;
		float pageWidth = 0;
		if (pages.size > 0) {
			for (Actor a : pages) {
				pageX = a.getX();
				pageWidth = a.getWidth();
				if (scrollX < (pageX + pageWidth * 0.5)) {
					break;
				}
			}
			setScrollX(MathUtils.clamp(pageX - (width - pageWidth) / 2, 0, maxX));
		}
	}

}

Finally, it’s just a matter of making the grid of buttons. In Scene2D, a Button is a Table, so it enjoys all the abilities that the table provides, including the ability to add and layout children as you like.

For our buttons we’ll have an image and a label at the top, with a table showing the number of stars they’ve earned on the level. Did I mention I am not an artist? We’ll just be using the default button background (tinted red, for fun) for our top image and tinted squares as our stars.

First we’ll create our PagedScrollPane, with each page being a table consisting of four columns and three rows:

PagedScrollPane scroll = new PagedScrollPane();
scroll.setFlingTime(0.1f);
scroll.setPageSpacing(25);
int c = 1;
for (int l = 0; l < 10; l++) {
	Table levels = new Table().pad(50);
	levels.defaults().pad(20, 40, 20, 40);
	for (int y = 0; y < 3; y++) {
		levels.row();
		for (int x = 0; x < 4; x++) {
			levels.add(getLevelButton(c++)).expand().fill();
		}
	}
	scroll.addPage(levels);
}

For each level we create a button, like so:

	/**
	 * Creates a button to represent the level
	 * 
	 * @param level
	 * @return The button to use for the level
	 */
	public Button getLevelButton(int level) {
		Button button = new Button(skin);
		ButtonStyle style = button.getStyle();
		style.up = 	style.down = null;
		
		// Create the label to show the level number
		Label label = new Label(Integer.toString(level), skin);
		label.setFontScale(2f);
		label.setAlignment(Align.center);		
		
		// Stack the image and the label at the top of our button
		button.stack(new Image(skin.getDrawable("top")), label).expand().fill();

		// Randomize the number of stars earned for demonstration purposes
		int stars = MathUtils.random(-1, +3);
		Table starTable = new Table();
		starTable.defaults().pad(5);
		if (stars >= 0) {
			for (int star = 0; star < 3; star++) {
				if (stars > star) {
					starTable.add(new Image(skin.getDrawable("star-filled"))).width(20).height(20);
				} else {
					starTable.add(new Image(skin.getDrawable("star-unfilled"))).width(20).height(20);
				}
			}			
		}
		
		button.row();
		button.add(starTable).height(30);
		
		button.setName("Level" + Integer.toString(level));
		button.addListener(levelClickListener);		
		return button;
	}

And here’s the whole file:

package com.example.gdx.scene2d;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.Color;
import com.badlogic.gdx.graphics.GL10;
import com.badlogic.gdx.math.MathUtils;
import com.badlogic.gdx.scenes.scene2d.Actor;
import com.badlogic.gdx.scenes.scene2d.InputEvent;
import com.badlogic.gdx.scenes.scene2d.InputListener;
import com.badlogic.gdx.scenes.scene2d.Stage;
import com.badlogic.gdx.scenes.scene2d.ui.Button;
import com.badlogic.gdx.scenes.scene2d.ui.Button.ButtonStyle;
import com.badlogic.gdx.scenes.scene2d.ui.Image;
import com.badlogic.gdx.scenes.scene2d.ui.Label;
import com.badlogic.gdx.scenes.scene2d.ui.ScrollPane;
import com.badlogic.gdx.scenes.scene2d.ui.Skin;
import com.badlogic.gdx.scenes.scene2d.ui.Slider;
import com.badlogic.gdx.scenes.scene2d.ui.Table;
import com.badlogic.gdx.scenes.scene2d.ui.TextButton;
import com.badlogic.gdx.scenes.scene2d.ui.Skin.TintedDrawable;
import com.badlogic.gdx.scenes.scene2d.ui.TextButton.TextButtonStyle;
import com.badlogic.gdx.scenes.scene2d.utils.Align;
import com.badlogic.gdx.scenes.scene2d.utils.ChangeListener;
import com.badlogic.gdx.scenes.scene2d.utils.ClickListener;
import com.badlogic.gdx.scenes.scene2d.utils.Drawable;
import com.esotericsoftware.tablelayout.Value;

public class PagedScrollPaneTest extends ApplicationAdapter {
	
	private Skin skin;
	private Stage stage;
	private Table container;

	public void create () {
		stage = new Stage(0, 0, false);
		skin = new Skin(Gdx.files.internal("data/uiskin.json"));
		skin.add("top", skin.newDrawable("default-round", Color.RED), Drawable.class);
		skin.add("star-filled", skin.newDrawable("white", Color.YELLOW), Drawable.class); 
		skin.add("star-unfilled", skin.newDrawable("white", Color.GRAY), Drawable.class);
		
		Gdx.input.setInputProcessor(stage);

		container = new Table();
		stage.addActor(container);
		container.setFillParent(true);

		PagedScrollPane scroll = new PagedScrollPane();
		scroll.setFlingTime(0.1f);
		scroll.setPageSpacing(25);
		int c = 1;
		for (int l = 0; l < 10; l++) {
			Table levels = new Table().pad(50);
			levels.defaults().pad(20, 40, 20, 40);
			for (int y = 0; y < 3; y++) {
				levels.row();
				for (int x = 0; x < 4; x++) {
					levels.add(getLevelButton(c++)).expand().fill();
				}
			}
			scroll.addPage(levels);
		}
		container.add(scroll).expand().fill();
	}

	public void render () {
		Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
		stage.act(Gdx.graphics.getDeltaTime());
		stage.draw();
		Table.drawDebug(stage);
	}

	public void resize (int width, int height) {
		stage.setViewport(width, height, false);
	}

	public void dispose () {
		stage.dispose();
		skin.dispose();
	}

	public boolean needsGL20 () {
		return false;
	}

	
	/**
	 * Creates a button to represent the level
	 * 
	 * @param level
	 * @return The button to use for the level
	 */
	public Button getLevelButton(int level) {
		Button button = new Button(skin);
		ButtonStyle style = button.getStyle();
		style.up = 	style.down = null;
		
		// Create the label to show the level number
		Label label = new Label(Integer.toString(level), skin);
		label.setFontScale(2f);
		label.setAlignment(Align.center);		
		
		// Stack the image and the label at the top of our button
		button.stack(new Image(skin.getDrawable("top")), label).expand().fill();

		// Randomize the number of stars earned for demonstration purposes
		int stars = MathUtils.random(-1, +3);
		Table starTable = new Table();
		starTable.defaults().pad(5);
		if (stars >= 0) {
			for (int star = 0; star < 3; star++) {
				if (stars > star) {
					starTable.add(new Image(skin.getDrawable("star-filled"))).width(20).height(20);
				} else {
					starTable.add(new Image(skin.getDrawable("star-unfilled"))).width(20).height(20);
				}
			}			
		}
		
		button.row();
		button.add(starTable).height(30);
		
		button.setName("Level" + Integer.toString(level));
		button.addListener(levelClickListener);		
		return button;
	}
	
	/**
	 * Handle the click - in real life, we'd go to the level
	 */
	public ClickListener levelClickListener = new ClickListener() {
		@Override
		public void clicked (InputEvent event, float x, float y) {
			System.out.println("Click: " + event.getListenerActor().getName());
		}
	};

}

Note, this is only one way to go about accomplishing this task and may not be the best way to do it, but it gets the job done so I’m happy with it.

Today, I was working with the GWT backend for LibGDX and in this particular game I was using mouse drag. I was met with an unsightly text-selection cursor on my mouse. It made me sad, and I bet it’d make you sad too.

Here’s one way to fix that…

The default index that the LibGDX Setup creates is pretty basic, which is good as it makes no assumptions as to what you want. Here’s an example:

<!doctype html>
<html>
	<head>
		<title>lines</title>
		<meta http-equiv="content-type" content="text/html; charset=UTF-8">
	</head>
	
	<body>
		<div align="center" id="embed-com.mobi.lines.Lines"></div>
		<script type="text/javascript" src="com.mobi.lines.Lines/com.mobi.lines.Lines.nocache.js"></script>
	</body>
</html>

Unmodified, this allows the aforementioned text-selection cursor to appear upon drag operations. If you don’t want that, you can add the following style (to the head) and script (at the end of the body) tags to your index.html:

<style>
	canvas { cursor: pointer; }
</style>

and

<script>
	function handleMouseDown(evt) {
	  evt.preventDefault();
	  evt.stopPropagation();
	  evt.target.style.cursor = 'pointer';
	}
	function handleMouseUp(evt) {
	  evt.preventDefault();
	  evt.stopPropagation();
	  evt.target.style.cursor = '';
	}
	document.getElementById('embed-com.mobi.lines.Lines').addEventListener('mousedown', handleMouseDown, false);
	document.getElementById('embed-com.mobi.lines.Lines').addEventListener('mouseup', handleMouseUp, false);
</script>

In the end, you should have something like this:

<!doctype html>
<html>
	<head>
		<title>lines</title>
		<meta http-equiv="content-type" content="text/html; charset=UTF-8">
		<style>
			canvas { cursor: pointer; }
		</style>
	</head>
	
	<body>
		<div align="center" id="embed-com.mobi.lines.Lines"></div>
		<script type="text/javascript" src="com.mobi.lines.Lines/com.mobi.lines.Lines.nocache.js"></script>
		
		<script>
			function handleMouseDown(evt) {
			  evt.preventDefault();
			  evt.stopPropagation();
			  evt.target.style.cursor = 'pointer';
			}
			function handleMouseUp(evt) {
			  evt.preventDefault();
			  evt.stopPropagation();
			  evt.target.style.cursor = '';
			}
			document.getElementById('embed-com.mobi.lines.Lines').addEventListener('mousedown', handleMouseDown, false);
			document.getElementById('embed-com.mobi.lines.Lines').addEventListener('mouseup', handleMouseUp, false);
		</script>
		
	</body>
</html>

I know, it’s not exactly earth-shattering stuff here, but I hope it can help someone.

For quite some time I’ve dreamed of being able to use my Android devices for development. Until recently, this dream seemed like it would never become a reality (at least, to the extent I wanted). Then, I learned of a new app available on the Google Play store… AIDE – Android IDE, an on-device development environment for Android applications. I’m not sure if this is the first app of its kind or not, but it sure seems like it’s the best.

So, what exactly does AIDE do that makes it so awesome? Well, first of all, like any good code editor AIDE offers syntax highlighting. More interestingly though, it provides code completion, refactoring, and other helpful features that traditional IDEs offer (and most on-device code editors don’t). Lastly AIDE, makes it possible to compile and run your application directly without having to use a computer. This is, to me, the most exciting aspect of AIDE.

After working with LibGDX for the last year and a half, I naturally wanted to see if I could use AIDE to continue to do so. My first attempt ended rather quickly with a issue report to the developer of AIDE but they turned around a fix very quickly and I was back in business. Lo and behold, it works!

There are a couple ways to get this set up, but here I’ll describe an easy way to start a new project. I’ll assume we want to maintain the best practice 3+ project setup and, to make it easier, I will utilize the dev-guide demo project from the LibGDX SVN repository on Google Code.

I’m sure I don’t have to tell you this but, to be sure, ensure you have AIDE installed on your Android device (this will work the same on phones or tablets).

With that out of the way, the first step will be to acquire the dev-guide project. I did this right on my device using Open Android SVN but you can use any means you like (Box, Dropbox, and Google Drive are all fine choices, as is copying from your computer). I copied the dev-guide folder to the AppProjects folder that AIDE sets up on the sdcard but this isn’t strictly necessary as AIDE will open projects from anywhere you like. Next, start AIDE, then locate and open the my-gdx-game-android project. We’ll need to make some very minor modifications so it works in the AIDE environment. Open the .classpath file in the project root. Update the references to the shared project and gdx.jar so that they are relative to the project (as opposed to the workspace). At the time of writing, the icons included in the my-gdx-game-android project are broken so you’ll need to replace them. Creating a new project in AIDE is a fine method of acquiring new ic_launcher.png graphics. Just copy and replace the same in the my-gdx-game-android project. Now, we are ready to run the game to make sure everything is correctly setup. Simply choose the Run option from the Menu (or Action Bar if on Android 3.0+). It will take a few moments to compile and install. When it opens you should be met with a nice fuschia screen (You can thank Mario for that one).

Assuming all went well, you are now ready to build out the next big thing. You’re only limited by your own imagination. Well, that and your ability to be productive and creative on your Android device. Perhaps, I will do another post with some apps I’ve found useful in that regard.

So, to recap, the steps are:

1. Acquire AIDE
2. Acquire the dev-guide project from Google Code
3. Update the classpath
4. Replace the icons
5. Run
6. ???
7. Profit

Update:: I’ve fixed the icons in the LibGDX SVN, so that step should no longer be required.

I realize I have been neglecting this blog, and since it is currently set as the default site for nEx.Software that doesn’t look very good. I am in the beginning stages of a redesign and a refocusing of the site. I plan to put more of a focus on nEx.Software as a company as opposed to nEx.Software as a blog since I clearly haven’t been the most attentive blogger around.

Stay tuned.

Recently, we received an email from a customer looking for updates on BarTor. OK, not all that uncommon right? The thing that stood out was the approach this customer took in asking for these updates. Lets just say that it was shockingly hostile, especially for a first contact email. Rather than explaining it, I will just include the email here along with my response.

From: Chris
Date: Sun, Jun 20, 2010 at 4:35 AM

the open source world should bitch slap you across the fucking face for getting rich off of us – at least $10,000 rich and now you’re ignoring us and no longer providing updates to an app that you charged $2.99 on the android market??????? how’s about an update you fucking cheapskate. your app only searches for torrents from isohunt.com and isohunt.com has since gone legit and no longer carries any torrents worth downloading. wtf man? i outta press charges on your ass. i’m looking into googles agreement and checking to see if you are at fault here. dick.

And my response:

To: Chris
Date: Sun, Jun 20, 2010 at 7:46 AM

Hello Chris,

How are you? I am sorry to hear that you are upset about the BarTor update frequency; however, a little respect would have been more appropriate.

Although, I don’t think your email truly warrants a response, I will do so. First and foremost, a general tip on social etiquette: when making first contact with someone, especially someone who you expect to do something for you, hostility is rarely an appropriate method.

nEx.Software as an entity, and in particular the product, BarTor, has little to do with the open source community. BarTor was a commercial endeavour and unfortunately a rather unsuccessful one. I can’t even begin to guess where you got your estimate from, but I can assure that the real numbers are FAR less than that… more in the $1,000-$1,500 range over the course of 15 months. Not that it is any of our business though.

Although ISOHunt may have changed its business model, BarTor continues to function as intended and advertised. Your assumption that the business model of ISOHunt has any direct correlation or impact on BarTor is just plain wrong.

Yours is the first email we have received of this nature, so I can assure you we have not ignored anyone. As previously stated, BarTor continues to work as intended and I think most people understand that.

That being said, we are not opposed to making an update if it seems necessary, but sending hostile threats is not a good way to let us know you’d like an update.

Respectfully,

Justin
Founder
nEx.Software

http://www.nexsoftware.net

Now, I am sure that I will catch a little flack about the “has little to do with the open source community” comment in my response but, if we are being completely honest, it is mostly true. While I, Justin, make an attempt to be a part of the community and contribute occasionally, nEx.Software itself does not follow an open source model. But that’s enough about that, as it is not the point of this post.

The reason I posted this here is due to the fact that I was a little bit floored by this first contact email from someone looking for something from us. I certainly understand that this customer is frustrated, and would like us to update the software; however, this approach of name-calling and making threats is almost guaranteed to not have the intended effect.

So, now that we know how not to approach developers to ask for updates… Let me give a tip on how to approach us: Ask nicely. I know, profound, huh? Even if it is only for the first email you send, a first impression goes a long way.

We at nEx.Software feel strongly about Android, and we want to see it evolve. For SOME of the world, Android HAS evolved. The release of Android 1.6 in October of 2009 brought Android to a new level in many ways, and we feel that this is a step in the right direction. The fact that there are still phones being released based on Android 1.5 (Motorola CLIQ [T-Mobile], Samsung Behold II [T-Mobile], Samsung Moment [Sprint], HTC Hero [Sprint], HTC Droid Eris [Verizon], and even a Motorola device rumored to be coming out in 2010 [Unknown]) is counterproductive to this evolution. While we do understand that it takes time to update something as big as an operating system, and this is especially true when dealing with custom user interfaces and functionalities, there needs to be a sense of urgency coming from manufacturers and carriers.

It is our opinion that, as long as applications are being made to support Android 1.5, there is no true drive for the manufacturers to upgrade their users’ devices. But what would happen if users of those devices were unable to access many of the applications in the Market (undoubtedly, this is the case already)? Surely, that would create the sense of urgency that seems to be missing at this time. We cannot have users missing out on the evolution of Android simply because the manufacturers and/or carriers don’t see a need or don’t think that those features are necessary for a certain device. This is an unacceptable approach to Android, in our opinion.

Accordingly, we have decided to no longer support Android 1.5 in the Android Market. We propose that other developers, who are able to do so, do the same in an effort to exact change. We are aware that there are many developers who cannot or will not follow in this decision, and we respect their decision whatever they choose. This is the path we have chosen to take.

We will be updating all of our applications currently available in the Android Market to require Android 1.6. We will however, try to move Android 1.5 versions into the alternative markets (such as AndAppStore and SlideME), and, where it makes sense to do so, we will distribute the Android 1.5 versions from our website.

You may be asking “Why not Android 2.0?” and to that we have to bring up the fact that ONLY ONE device is currently running Android 2.0, and as of the time of this announcement Google has given no indication that Android 2.0 will be made available in the Android Open Source Project anytime soon. While it is true that manufacturers may have or get access to Android 2.0, the fact remains that we have seen no commitment from these manufacturers that they will in fact update existing devices (HTC has announced via Twitter that the Hero will receive an update 2.0, but failed to mention anything about Dream and/or Sapphire devices).

After having my Motorola CLIQ for three days, I decided to write down my thoughts and opinions of the phone and specifically focus on those aspects that are (in my opinion) of interest to current Android users who are looking at the CLIQ as a possible upgrade device. So here it goes…

The Contents of the Box:
• Motorola CLIQ Phone
• AC Adapter Plug
• USB Cable
• SIM Card
• Instructions

Of course, there is nothing incredibly out-of-the-ordinary here but there are a few things worthy of a mention. First, the AC Adapter plug… It’s just that… a plug. You actually use the provided USB Cable for both the AC Power and for connecting your phone to your computer. This works fine, it is just weird. Second, there is a curious lack of reference to Android in the instructions. It’s there, just infrequently. Again, it’s just a little weird, especially considering Motorola’s almost over-zealous dedication to Android.

The Hardware:
Having heard numerous people half-jokingly refer to the CLIQ as a toy, I am pleasantly surprised at the perceived ruggedness of the build. Only time will tell whether the ruggedness is real or not, but at this point I’m quite happy with it. When compared to the HTC Dream (T-Mobile G1) the lack of the swivel motion in the keyboard makes it seem sturdier. Also unlike the Dream there is far less motion between the front and back pieces when closed. There is still some motion, however, which is most noticeable when pressing at the left and right edges of the screen. So far there is no creaking or squeaking related to this motion, which was not the case with the Dream.

The CLIQ is similar in size and weight to the HTC Sapphire (T-Mobile MyTouch 3G, HTC Magic), but slightly thicker. And, although similar shape, the CLIQ does lack the “chin” as seen on most of the HTC Android devices. So if you don’t dig the chin, you might find the flat-face of the CLIQ more appealing.

When closed, the CLIQ has the Menu (designated by four squares), Home, and Back buttons on the front, a silent-mode switch and volume rocker on the left, the power/lock button and camera button on the right. On the top is the 3.5mm headphone jack and on the left is the MicroUSB slot. Slide open the keyboard to reveal the 5-Way Directional Pad to the left of the Four-Row Keyboard. For those coming from one of the existing Android devices such as the Dream, Sapphire, or Hero, this is where things get different.

The fact that you have to open the keyboard to get at the directional pad is somewhat troublesome. It’s amazing but you don’t realize how often you actually use the navigation controls (trackball or directional pad) until you don’t have them accessible. For me, this is most obvious when using the virtual keyboard and need to go back a few characters or lines to correct something. Having used a Dream and a Sapphire for nearly a year now, I find myself constantly going to the trackball only to find it isn’t there. Also, the placement of the directional pad on the left is proving to be a little hard for me handle. At first, I had though “Sweet! It’s more like the game controllers I am used to, this is going to be awesome!” but I have found I am more comfortable with the trackball on the right. Again, this is probably because I am used to it.

The keyboard itself is different and interesting to get used to. With the Dream, our beloved physical-keyboarded Android, we have a 5-Row Keyboard which makes typing a bit easier than with the 4-Row Keyboard of the CLIQ. Also, it may just be me but it seems like the CLIQ takes a touch more pressure to press the keys. That being said, the shape of the keys (somewhat like a rounded pyramid) and their closeness to each other actually helps with typing speed because in many cases you can rock between the keys easily. The keyboard is where the CLIQ gets its name. There is actually a clicking sound with each keypress. It’s not a software generated sound but rather there is an actual clicking sound coming from the hardware. I know what you are thinking… Yes, I think this is intentional and not a defect. It’s not loud but it is noticeable, which means no secret texting in class kids (unless you go virtual).

Lastly, something that isn’t really keyboard related but is related to typing on the CLIQ. The placement of the volume rocker on the left side (which becomes the bottom when the keyboard is open) is unfortunate. This is because depending on how you rest your non-typing fingers while typing you may find yourself accidentally adjusting your ringer volume frequently.

The touch screen is slightly smaller than the HTC phones, coming in at 3.1” as opposed to 3.2” but this doesn’t make a huge difference (for me at least). Sometimes the touch response can seem a little lagged and somewhat inaccurate but perhaps I am at fault. I find myself hitting the wrong keys on the virtual keyboard more often on the CLIQ than on my other phones.

So I bet at this point you are asking yourself, this is a phone so how does it work as a phone? Although I don’t often use my phone as a phone, I have found the voice quality both on the CLIQ side and on the other caller’s side is loud and clear, and without any weird artifacts. This is not new to me though as I have experienced flawless voice quality on my other Android phones as well.

The Software:
Somewhat disappointing is the fact that the CLIQ, with its MOTOBLUR services, is based on Android 1.5. This is disappointing for two reasons: First, the CLIQ is being released on a carrier that has already rolled out Android 1.6 to all of its existing Android phones (T-Mobile USA). Second, Motorola is releasing another device only days later that is running Android 2.0. I understand that the CLIQ is Motorola’s first Android device and that its MOTOBLUR services were built on that framework, but Motorola obviously has had the benefit of knowing Android 2.0 for at least some time and I would have liked for them to have MOTOBLUR updated to Android 2.0. Perhaps there is going to be a quick follow-up release to upgrade CLIQ users to 2.0 but I doubt it.

So, now that we know MOTOBLUR was likely a part of reason that the CLIQ is being release with Android 1.5, let’s talk about those services and see if they justify the ends. We’ll begin with my experience starting up the phone and setting up the MOTOBLUR services, and then lead into how those services come into play with real use of the phone. Finally, I’ll discuss the overall experience without specific focus on MOTOBLUR.

Anyone who follows me on Twitter will know that I was very excited to receive my CLIQ and was very eager to get home from work and fire it up. And I did exactly that. I got home, I popped the SIM card out of my Sapphire and into the CLIQ and excitedly powered it on. Much as is the case with the instructions booklet, I found myself a touch confused when I was not presented with any indication that the phone I was booting was indeed Android. Instead, I got a pulsing MOTOBLUR logo. Fine, whatever, I can deal with that. I then got to what I will call the Welcome to Android screen, but again, saw no indication of Android’s presence. Instead I got a customized welcome screen and was directed to begin MOTOBLUR setup. This was easy enough, I enter my Name, my Email Address and a Password and I am good to go. After that I get to choose which accounts I sync (including MySpace, Facebook, Google, Last.FM, Twitter, Email, Corporate Sync, Picasa, Photbucket and Yahoo Mail). I am not sure if Google was optional or not but since this is Google Android, I chose it automatically. I also included Facebook and Twitter. It might have been nice to also have LinkedIn as an option for those corporate types. Everything went fine here and I was delivered to the Home screen of my phone.

Although I knew it was coming, I was caught a little off guard by the number of Widgets that were loaded by default to my Home screen. My Android experience, having flashed and re-flashed and wiped and re-wiped my phones countless times, has always been a minimalistic default Home screen. Instead I was presented with the Social Status, Happenings, Messages, Weather, News, Music, and Search Widgets already preloaded with either my social networking content or default selections. I updated the weather widget to show my location, removed the News and Music widgets, and went along my way a much happier person.
As you probably noticed, I left all of the social networking widgets in place. So, how does “The First Phone With Social Skills” stack up in terms of social networking? It’s kind of a mixed bag. While I am generally pleased with the way that MOTOBLUIR retrieves my statuses and messages from various sites, there is a bit to be desired. First of all, I have yet to find out if there is a way that I can set the frequency at which these sites are polled for updates, or whether I can manually trigger an update. In the case of Twitter, where conversations seem to fly by at the speed of a hummingbird, I find myself a little behind the times when I get updates. The good thing: MOTOBLUR makes is very easy to see what is new because only new statuses are shown in the Happenings widget. Once you view them, they are removed from the widget (but are still available for viewing in the Happenings application). This behavior is the same for the Messages, and News widgets. The Happenings application also functions as a Twitter (or whatever service to which the current message applies) client but it is somewhat rudimentary. For example, there is a way to Reply to Tweets and to Direct Message the Sender of a Tweet, but there is no option to Retweet, or follow Mentions or Hashes. This is probably due to supporting so many different services that they had to compromise some functionality. Needless to say, I have not been able to use MOTOBLUR as my sole Twitter client. Facebook, operates in much the same way so I won’t go into that here. I use Facebook much less frequently that Twitter so I am happy with the MOTOBLUR implementation there.

Where I think MOTOBLUR shines is actually in its modifications to the Contacts application. Instead of just being a list of people, the Contacts application becomes yet another way to see the status of your Contacts and consolidates all of your contacts from your various synced services. Of course, you have the option to just view a list as well. The Dialer view presents us with the Dialer and additional tabs for Recent, Frequent, and Speed Dial contacts.

Of course, with these modifications, the Contacts database had to be changed. Unfortunately, there have been reports of Contacts based applications not functioning properly in some cases. Keep this in mind of you see any weird things happening and notify the developer of the affected application so they are aware and can implement a fix or help troubleshoot.

As that pretty much covers the main features of MOTOBLUR in the device (there are other features such as remote wipe, but those are not device related, so we’ll skip them for now) I will move on to the general observations of the user experience.

If you’ve seen any videos or screenshots of the CLIQ you will already know that the UI is modified from the vanilla Android experience. Most of the UI is similar but colors have been modified and some elements have changed graphically. The theme of the CLIQ is nEx.Software colors. Only kidding, but they are red and black so in most places that you would normally see orange, you see red. In most places this works but there are some places where it might have been best to not modify the colors. For example, the stars to indicate rating in the Market are red instead of green, which makes them a little difficult to see due to their small size.

The phone has no physical call or end call buttons, which means that you have to go to the home screen to make a call, which is fine because if you are making a call you probably don’t need to be in another app. As you would expect you can answer a call while in any application.

Overall, the phone seems a little snappier than the Dream and Sapphire (except for the HTC branded variant which has the 256MB RAM) because it has more RAM. However, I would imagine that MOTOBLUR can dig into the speed on updates, which it seems you have no control over.

Conclusion:
After having spent three days with this phone, I have definite things that I like and things that I don’t really care for but I have been generally impressed by this phone and would say that it is a good entry into the Android market (not the Android Market of course). I would recommend it as a replacement for the Dream if a replacement was needed, but would probably not recommend it if there was no actual need. It’s just not that compelling an upgrade for those who don’t have to. For a new Android user who wants a keyboard I’d recommend it over the Dream. But I’d venture a guess that it would be hard to choose this over the Motorola Droid or some of the other Android phones de out in the near(ish) future.

An item of note that isn’t really a part of the review but I felt like mentioning anyway. There is currently a bug in the CLIQ firmware which has broken some games, and has caused them to not display their graphics (i.e. Buka and Totemo by Hexage). If you know of any games that are experiencing this issue, please let the developer know so that they can work around the bug.

Please let me know if there is anything else you’d like to know about the CLIQ, or my experiences with it.

Coming soon…

Hi all… Note, I am going to assume that there are at least a few people who have wandered off, gotten lost, and somehow ended up here. Hopefully, a few of you meant to be here too…

Yesterday, I was perusing the forums over at www.androidandme.com (as I often do) and one of the members had posted a question related to development. Of course, I hunt these down and pounce whenever I see them. So, on to the question, which I am going to strip down to the scope of this post… How does one write a custom Analog Clock Home Screen Widget for Android.

So, as I am sure you have already guessed, I have decided to write a tutorial (with code) to explain in detail how to do just that.

Before we continue, I should point out that as I am writing this I am going to assume that you have obtained, installed, and know how to use the software tools for Android Development. For the purpose of this tutorial, these tools are: JDK 1.5 or higher, Android 1.5 SDK, Eclipse 3.4 or higher, and the Android Development Tools Plugin for Eclipse.

Now that that is all out of the way, let’s move on to the tutorial…

First off, we are going to create a new Android Project in Eclipse. For my own code for the tutorial (which can be downloaded here), I will call the Project AnalogClockWidget, I will choose Android 1.5 as the build target (required for Widgets), I will set the Application Name to Analog Clock Widget, the package name to nEx.Software.Tutorials.Widgets.AnalogClock, and create an Activity called Info (this will be explained later).

During the course of this tutorial we will be creating several files that implement various aspects of the widget. These files we will be creating are:

• Java Source Files
  • Info.java
  • Widget.java

• Resource Files
  • res/xml/widget.xml
  • res/layout/info.xml
  • res/layout/widget.xml
  • res/drawable/widgetdial.png
  • res/drawable/widgethour.png
  • res/drawable/widgetminute.png

We will also be working with AndroidManifest.xml within the root directory of our project.

Resource Files

The most logical place to start in creating a widget such as this is creating the layout files and the xml file declaring the app-widgetprovider (in our case, res/xml/widget.xml).

res/xml/widget.xml: This file contains the definition of our Analog Clock widget. It is an xml file with only one element: appwidget-provider, which has the following attributes: xmlns:android (standard in Android resource files, defines the android namespace), android:minWidth (defines the minimum width of our Widget, translates to number of cells in the horizontal space), android:minHeight (defines the minimum height of our Widget, translates to number of cells in the vertical space), android:updatePeriodMillis (defines the update frequency, a value of 0 means no updates), android:initialLayout (a pointer to the layout file to display during loading of the widget).

the graphics I am using for this custom version of the Analog Clock will be a nEx.software themed version of the original Analog Clock. As such, I am going to use the same size parameters as the original. That that is, my Clock Dial will be 146ppx by 146 px. Ecah hand will be 14px by 146px.  This size will fit nicely into a 2 cell by 2 cell space on the home screen (in both landscape and portrait modes), just like the original clock. Note that we refer to res/layout/widget.xml here as our android:initialLayout.

Click the link at the beginning of this section to see what our widget definition should look like.

res/layout/info.xml: This file simply provides the layout for an information screen to tell the user about your widget, and provide instructions on how to use it. In our case, we have a very simple widget which requires no configuration, and no special instructions so it will be a very simple layout containing only a LinearLayout and TextView. More complex widgets will usually require more complex information screens.

Click the link at the beginning of this section to see what our info screen should look like.

res/layout/widget.xml: This file provides the layout which we will use for our widget. Again, because this is a simple widget this will be a simple file. In fact, the only elements we will include here are RelativeLayout and AnalogClock. This could also be done without the RelativeLayout, but I usually prefer to have a container in my layout.

Click the link at the beginning of this section to see what our widget should look like.

The remainder of the Resource files listed above are just the graphics we will use for the clock, and need not be specifically mentioned here.

Java Source Files

Info.java: This class extends Activity, and only serves to provide an informational screen to the user. Technically, this is not required for a Widget project, but I recommend it for the following reason:

If you plan to release to the Android Market, it will mitigate those useless and uninformed comments such as “It doesn’t launch.” or “Please remove from the app drawer.” and help you to achieve and retain a better ranking in the Android Market. So, I know you are thinking now “Spill the beans already!” so here it goes… Provide an Info activity which opens from the Android Market when the user presses the Open button, but does not add itself to the app drawer (Launcher). Sounds simple enough, so how do we do it? All you need to do is open the AndroidManifest.xml file,

and replace

android.intent.category.LAUNCHER

with

android.intent.category.INFO.

It’s amazing how a simple change like this can easily amount to a full star or more in your Android Market rankings.

While we are in the AndroidManifest.xml file, we might as well make our other required changes too. Because this is a widget project, we must define our widget in the manifest. To do this, you must define a receiver tag with an intent-filter for android.appwidget.action.APPWIDGET_UPDATE and including a meta-data tag which defines the resource file for the widget.

Click here to see what your AndroidManifest.xml file should now look like.

Widget.java: This is where the magic happens, and is where we will spend the rest of this tutorial. In order to create and use a widget we must extend AppWidgetProvider. Remember, we already added the reference to this class in the AndroidManifest.xml file.

Because this is a very simple widget that relies on nothing but itself (no calls to the web, no background updates, etc…) our Widget class will be very simple. We will only handle the onReceive event that gets called by the AppWidget framework whenever a Widget is Added, Deleted, Updated, etc…

In this onReceive method we will only look watch for the “update” event, so that we can reapply our Widget when appropriate. For some reason, I decided on a blog format that doesn’t not work exceptionally well for including code within a post (layout is not really wide enough). Until I find a better layout for this sort of thing, please click here to view the code sample for our onReceive method.

At this point, we actually have a working Analog Clock Widget, and could compile and use it as is. But that wouldn’t be any fun. What we also want to do is handle when the user clicks on the Clock, and take the user to the Alarm Clock application. to do that, we must create a PendingIntent, and assign it to the click event for the widget. Do do that we will add to the onReceive method three lines. Please click here for the updated code.

At this point, all that is left is to replace the widgetdial.png, widgethour.png, and widgetminute.png in the res/drawable/folder with your own graphics, compile, and install.

You can download my Eclipse project for this widget here.

Regrettably, I somewhat rushed this tutorial, since I had promised to get it out as soon as possible, and I am aware that there are things that could be done better (formatting, maybe more verbose, maybe simpler terminology, possibly different writing style). I intend to update this tutorial in the coming days to be fix some of these issues. Please let me know what I can do better, and offer any suggestions for improvements for this and future tutorials.

In BarTor, we custom draw a lot of our controls, and we do this for a couple of reasons. First, we do this so that we can have better contol of the overall look-and-feel of the application, and we also as a framework for color theming capability (in other words, allowing the user to pick his/her own color scheme).

It is my goal to write a series of posts that outline some of the Android drawing classes and methods and how to use them in your own Android applications. While the focus of these posts will be on how we have used them in BarTor, we will certainly be presenting them in a way that makes the information usable for any application.

Stay tuned, the first post in this series is coming soon.