Smartwatches – LG Urbane

Smartwatches – LG Urbane

I have spent roughly two weeks with an LG Urbane. I won’t cover it in details nor perform any sort of review. I think that the LG Urbane is perhaps the best Android Wear/Smartwatch you can buy right now (and also perhaps the most expensive at 300 USD), however, I think you should not buy one at this time.


It’s useless, expensive, buggy and doesn’t really do anything better than your smartphone.

Are you Nuts?

Before you go coo-coo trying to defend your nice 300 dollar piece of smartwatch, read a little bit more.

The LG Urbane is really nice. The band could be better, I don’t like it to be honest; I will likely get a metal one. But who cares about that? The important part is the smartness of the Watch.

Let’s avoid Apple Watch (this being the only time it will be mentioned) this time. I can only describe a smartwatch, any smartwatch as an extension of your phone. A faster way to read your notifications and sometimes to interact with them. I get it. I like the idea. But it’s not enough, it’s erratic, sometimes doesn’t work, etc., but above all that, it’s not worth 300 dollars.

Let’s be frank here. It’s three, hundred, dollars.

I will save you the trouble.

On a scale from 1 to 10 where 1 is no way and 10 is GET ONE NOW, I give any smartwatch a three.

There’s no real need to have one. You will only use it to check the time, delete unwanted emails and/or replying the ocassional text.

The Fit part, well if you’re into that, but I’ve noticed battery life suffers a little bit more when the fit thing is on all the time.

Now, if you grab all smartwatches and normalize the scale again so it goes from 1 to 10. I think the LG Urbane is one of the best ones at this time. I haven’t tried many. I’ve seen a few, only interacted with Moto 360s (1st Gen) and the fruity company one. (Sorry, I mentioned it again!).

I give the LG Urbane a solid 8 in my new scale. It’s good. It’s buggy sometimes. It slowsdown when it feels like it, etc. But most of these things have to do with Android Wear not being 100 polished yet and my idea that smartwatches suck no matter what.

The Moto 360 is a joke, its battery life is a joke.

The LG Urbane does a little bit better, provided you don’t do any stupid thing with it (as in, touch it ever 30 seconds to check the weather), you will have 1.5 days of battery life on average. You will still want to charge it every night…

Wi-Fi is nice, when it works. It will be better. But the fact that you don’t have to rely on Bluetooth is nice.

Can it get better?

Yes, and it will. Just give it time.

My Biggest Gripe:

When I cross my arms, the worst decision of all times reminds me that someone, for some reason, thought that press and hold on the watch’s face, should activate a face change feature. Needless to say, this feature activates with haptic feedback, so your wrist is nudged every time. How many times are you going to change your watch’s face? Really. A double tap would have been better. I don’t know. I might even write my own face that captures taps and returns true. Trust me, it’s better than a nudge when you cross your arms.

We’re not alone.

Some people keep telling me that they cross their arms the other way around (so their smart watch is on top). Good for them, but I don’t and I don’t feel like changing 40 years of expertise in arms-crossing-technique.

I guess I’m just holding it wrong™.

You're Holding It Wrong

Note: the solution for now is to double press the hardware button (which the LG Urbane has) to enter Theater Mode which disables the screen… along with the nice ambient-mode that leaves the screen dimmed and on at all times (with optional faces, which is nice).

Single tapping the hardware button turns the mode off and you’re back to normal, but this defeats the purpose of the ambient mode – always on thing. Might as well have that disabled and save the battery. That also means your smartwatch is in a comma state where you don’t get to see notifications by merely looking at your wrist, you have to use your other hand (unless you’re some kind of alien) to press the hardware button.

So no, that’s not a solution, it’s a “well at least this doesn’t bother me all the time” kinda thing. Read more about Theater Mode here…

What to do?

Just save the mula, you will need it soon for something cooler.

But You want to spend the money, huh?

Then buy an Urbane. Don’t wait. And if you really think that Smartwatch XYZ coming soon is better, then wait, why are you reading this? As better as your XYZ will be, it will still be the same thing, for now. We have to wait. At least this is not Google Glass.

Happy Smartwatching, said no one ever.

Adding multiple clicking regions to an Android TextView

At work I was asked to make a list of tags clickable. The list of tags came from the API in a comma separated list. So it looks like this:

tag1, Tag2, tag3, TAG4, etc. 

This is nice because I don’t need to worry about displaying it correctly. It’s the API’s job to send me the data.

If you take a look at the XML for the Layout, it’s very simple:

style="@style/mix_list.tag_cloud" />

And the style is very straightforward too:

<style name="mix_list.tag_cloud">
 <item name="android:maxLines">1</item>
 <item name="android:clickable">true</item>
 <item name="android:ellipsize">end</item>
 <item name="android:singleLine">true</item>
 <item name="android:lineSpacingExtra">1sp</item>
 <item name="android:textAllCaps">true</item>
 <item name="android:fadingEdge">horizontal</item>
 <item name="android:paddingLeft">10dp</item>
 <item name="android:textColor">@color/black</item>

The initial requirement was to show tags in a single line and if there were more, just add the ellipsis “…”, and this worked fine. No need to use anything other than a single TextView to display the data. Android took care of everything. All was good until I was asked to make the tags clickable. So if the user taps tag1 the app should react to that and do something (in this case, a new Activity is launched and the tag1 is used to obtain data). After testing different approaches, this is the easiest I could come up with. I didn’t want to mess with the Layout, one TextView was fine and dynamically adding TextViews (with their ClickListeners) would have been a pain in every possible way, so I resorted to the SpannableString and it’s various incarnations. Before the change, I was simply doing this in my ListAdapter (notice I’m using a ViewHolder pattern):


I needed to change that now. So I created a small method which does it for me:

makeTagLinks(item.tag_list_cache, holder.tagcloud);

This small method looks like this:

1	private void makeTagLinks(final String text, final TextView tv) {
2		if (text == null || tv == null) {
3			return;
4		}
5		final SpannableString ss = new SpannableString(text);
6		final List items = Arrays.asList(text.split("\\s*,\\s*"));
7		int start = 0, end;
8		for (final String item : items) {
9			end = start + item.length();
10			if (start < end) {
11				ss.setSpan(new MyClickableSpan(item), start, end, 0);
12			}
13			start += item.length() + 2;//comma and space in the original text ;)
14		}
15		tv.setMovementMethod(LinkMovementMethod.getInstance());
16		tv.setText(ss, TextView.BufferType.SPANNABLE);
17	}

Let’s go through the relevant pieces.

The first thing to notice is that we only use one SpannableString and and then we define regions (spans) inside it. List of tags is automatically split thanks to Java (line 6).

Two auxiliary integers are used (start and end) defined in line 7. The values of these will increment as we move through the tags.

So the loop is a Java 5.x iteration though a List<String>. Nothing fancy. (Line 8).

In Line 9 we start the magic. First calculate the end of the Span. In the first iteration, start (and end) are both zero, so the end is basically the size of the first String.

Line 10 is a security check, if the start went beyond the end, just skip it (that means you’re probably done).

Line 11 is the real magic. Defines a new ClickableSpan from start to end. The MyClickableSpan is a small class that we’ll see later, but it could have been any other type of span (Color, style, etc.); you can even define multiple spans for the same region. We don’t use flags, but you should read the class in Android to see what the flags are, but chances are you’re not going to need them.

Line 13 moves the starting point forward. Since the original text had a comma and a space separating the tags, we need to account for these two characters when moving forwards, because we’re iterating the Strings in the List<> but the span has the whole text. So the start adds the item length plus two more spaces (comma and space between tags). The loop iterates and we get a new string. Start is now positioned at the beginning of this string, so we recalculate the end, which is now start plus the new item length.

Rinse and repeat.

The final two lines 15 and 16 are important. If you don’t set the MovementMethod, it’s not going to work.

Like my friend Jeff Atwood uses to say, read the source, Luke. Here’s what the source code for setMovementMethod says:

* Sets the movement method (arrow key handler) to be used for
* this TextView. This can be null to disallow using the arrow keys
* to move the cursor or scroll the view.

Hmmm ok… doesn’t really say much. What is a MovementMethod anyway? It’s a Java Interface (Protocol for those Objective-C guys) that…

* Provides cursor positioning, scrolling and text selection functionality in a {@link TextView}.

So in line 15 we provide the default implementation, so the tags are “moveable” (it sounds weird).

And this is how it looks in the Android source code:

* A movement method that traverses links in the text buffer and scrolls if necessary.
* Supports clicking on links with DPad Center or Enter.

So by passing an instance of LinkMovementMethod, we’re providing out TextView with all this power!

Anyway, in line 16 we just set the text of the TextView to be the SpannableString and we tell it that the Buffer is Spannable. It’s worth looking through the TextView source code to see what all these things do. There’s a lot going on behind the scenes and it’s always interesting to see “how they did it”.

And that’s it. The only mystery is not to reveal what MyClickableSpan is. You will be disappointed.

private class MyClickableSpan extends ClickableSpan {
   private final String mText;
   private MyClickableSpan(final String text) {
      mText = text;
   public void onClick(final View widget) {

Yes, that’s all. I just wanted a ClickableSpan that could store a String (the text associated with the “span”).
Wait, what is mListener?
Just an Interface/Callback that was passed to this Adapter that has one method. onTagClicked(String). In my particular case it’s a Fragment that handles this tag clicking thing, but it can be anything you want.

And that’s it! I’m not sure if this is simple or not, the documentation is not very clear and there are way too many classes floating around…

In any case, just experiment and remember your allies: Google and StackOverflow but don’t become a CopyPaster. Read what the code does, try to understand every single line and ask if you don’t understand what it does. You will be surprised how much you can learn by just reading code.