svpino.com

The magical tech behind paper...

noreply@blogger.com (Santiago L. Valdarrama) — Wed, 14 Nov 2012 05:38:29 PST

The Magical Tech Behind Paper For iPad's Color-Mixing Perfection.

An amazing post about an amazing iPad application. I love the application and really enjoyed reading about what's going on behind the scenes. It's amazing how much effort was put behind an apparently trivial feature.

You gotta love these guys.

The magic of being skilled

noreply@blogger.com (Santiago L. Valdarrama) — Tue, 30 Oct 2012 10:50:54 PDT

Incredible what some people can do with an iPad (or a pencil and a piece of paper). From left to right: me, Deisbel, and Jorge.

I really wish I could draw like this. If you are interested, here is the original photo.

This ain't a Windows-friendly corner

noreply@blogger.com (Santiago L. Valdarrama) — Sat, 27 Oct 2012 15:54:31 PDT

I'm hanging this on my office wall for Halloween.

Scary, right?

Cartoonish diagrams

noreply@blogger.com (Santiago L. Valdarrama) — Sat, 27 Oct 2012 00:15:48 PDT

It's amazing how quick a drawing becomes alive, isn't it?

I love this kind of fun to somehow break the traditional boring diagrams that everybody uses for technical stuff. Believe me, people in your audience will be way more willing to pay attention if you throw some funny-looking cartoons at them.

It takes time, but at the end it looks awesome! For anyone wondering, this is a classic Integration-Manager Workflow in Git.

Open sourcing my Android App. Go, grab it, and do something good with it.

noreply@blogger.com (Santiago L. Valdarrama) — Mon, 22 Oct 2012 10:43:50 PDT

If you've been following my blog, you already know that some time ago I was working on an Android application. Its main goal was satisfying a personal need: I was super-frustrated that there was nothing for the Android platform that let me take a quick glance at the stock market. Personally I'm a stock junkie, and I love to check stocks 20 times a day. Not having a simple app to do it was really painful.

So I did it myself. Just like I wanted. When I published it, I called it "Stocktile", but internally "Longhorn" was its name.

And God knows I loved the result! It was quick, easy to use, and beautiful for my taste. I made it rock-solid and took special care of every detail I could imagine. Since day one I used it 20 times a day until I bought an iPhone 5... iOS comes with a pre-installed stock application so I won't be working on an iOS version of mine any time soon.

So now I'm not going to use Longhorn anymore. The application is already in Google Play and the Amazon Marketplace, but I felt like I wasn't done with it. I really like it and I'd like a better life for it.

So that's why I decided to open source it. Click below to go to my GitHub account and grab it:

Download Stocktile (Longhorn) source code here.

Yup, you can download the code, re-compile it, change it, and do whatever you want with it (well, at least whatever the Apache License version 2 let's you do with it).

To give you a preview of what cool stuff you'll find:

Drag and drop (for Android 4.0+)
Search autocomplete
Talk to search
Automatic market updates
Battery optimization techniques (Read more about this here)
Support all the way up from Android 2.2
A very nice UI layout
Gracefully handling device orientations
And way more stuff...

For me it was a real pleasure to work on this app. I hope you can use the code to make something amazing. If that's the case, let me know. I'd love to hear about it.

A Blow To HTML5

noreply@blogger.com (Santiago L. Valdarrama) — Sat, 25 Aug 2012 07:49:02 PDT

A Blow To HTML5 is a super interesting discussion about HTML5 versus native code for mobile applications. Stop by if you want to read different takes on the subject from different people. I'm really enjoying it.

My Chromebook is winning me over my MacBook Pro

noreply@blogger.com (Santiago L. Valdarrama) — Wed, 08 Aug 2012 12:07:08 PDT

I'm a die-hard fan of my MacBook Pro 15.4". It's the best computer I've ever had and I think it's only behind the new Retina MacBook. I use it daily and it's essential for my work.

But...

At home, I've found myself going back to my Google Chromebook. It's all about the weight. With 3.02 lbs only, it's a no brainer to pick it up and move around the house. An incredible battery life plus the fastest wake-up from off I've ever seen complete the perfect I-need-more-than-an-iPad scenario. Obviously, this works only when I'm reading or doing something else browser-only. As soon as I need Eclipse or any other non-browser app I need to go back to my Mac.

Anyway, I think it's interesting how spoiled I've got with the time. The latest Windows laptop I had was an HP Pavilion dvd5 and that thing was heavier than a brick. With the introduction of the iPad in my life, everything now feels too clumsy to carry around... even my MacBook Pro. That's why the Chromebook is winning me over.

Good news are: from now on, on such a fierce market, everything will be even lighter... can't wait to see what comes next.

Integral data types in Java and C#

noreply@blogger.com (Santiago L. Valdarrama) — Sat, 11 Aug 2012 10:38:55 PDT

Here is something not super interesting, but that usually comes in handy: what's the range of the integral types in Java and C#?

Let's start by saying that integral data types are those that represent only whole numbers. Each number will have a well defined successor. So floating point numbers are not integral data types (what comes after 0.1? 0.11 or 0.111?) but integers are.

That being said, Java supports the following integral data types: byte, short, int, and long. On the other hand, C# supports sbyte, byte, short, ushort, int, uint, long, and ulong. On purpose, I'm leaving outside of this conversation the char data type since, despite it can be considered an integral type, I don't want to confuse anyone by mixing characters with numbers. So a total of 4 types in Java and 8 types in C#.

The interesting part is the range of numbers that each one of these types supports. To calculate this range, let's first take a look to the size of each one of these types:

sbyte - 8 bits (1 Byte)
byte - 8 bits (1 Byte)
short - 16 bits (2 Bytes)
ushort - 16 bits (2 Bytes)
int - 32 bits (4 Bytes)
uint - 32 bits (4 Bytes)
long - 64 bits (8 Bytes)
ulong - 64 bits (8 Bytes)

This is true for both Java and C# (remember that only a subset of these types is supported in Java). Having these sizes, there's a simple formula to compute the range of each type. In the case of C# we'll also have to pay attention to the prefix (if any) of the type. This prefix can be "s" (sbyte), "u" (uint), or none (long). This hints us whether the range is going to include negative numbers or not: "s" means "signed" so it will include negative numbers, "u" means "unsigned" so it will include only positive numbers, and when nothing is specified, assume negative numbers are included. So let's see the formula:

If the number includes negative values, the lower bound is going to be - 2^(bits - 1).
If the number includes negative values, the upper bound is going to be 2^(bits - 1) - 1.
If no negative numbers are included, the lower bound is going to be 0.
If no negative numbers are included, the upper bound is going to be 2^bits.

The reason why in negative numbers we need to use bits - 1 as the exponential part of the formula is because the sign (+ or -) is going to be stored on the same value and it will take 1 bit (1 meaning negative and 0 meaning positive). Let's run the numbers and define the ranges:

sbyte [-2^7 .. 2^7 - 1] = [-128 .. 127] 
byte (Java) [-2^7 .. 2^7 - 1] = [-128 .. 127]
byte (C#) [0 .. 2^8] = [0 .. 255]
short [-2^15 .. 2^15 - 1] = [-32,768 .. 32,767]
ushort [0 .. 2^16] = [0 .. 65,535]
int [-2^31 .. 2^31 - 1] = [-2,147,483,648 .. 2,147,483,647]
uint [0 .. 2^32] = [0 .. 4,294,967,295]
long [-2^63 .. 2^63 - 1] = [-9,223,372,036,854,775,808 .. 9,223,372,036,854,775,807]
ulong [0 .. 2^64] = [0 .. 18,446,744,073,709,551,615]

So here are some things to notice. First, if you use both C# and Java, be careful when you use the byte data type because it doesn't have the same range in both languages. An equivalent for the Java's byte in C# is sbyte. Second, note that in case of signed types, the upper bound is always 1 less than the lower bound (32,767 vs 32,768 for an int). This is because the value 0 is always considered a positive number. Third, try to say the name of the number represented by a long value. It will probably take you a while.

Another point that is usually misunderstood is the fact that the size of these data types is going to be always the same regardless of the architecture our program is running on. So you might be running your program in a 64 bit machine, but an int is going to be always 32 bit long so it will have the same range. This is true for both C# and Java.

Finally, I would like to know why in hell the C# design team decided to break the pattern creating an sbyte and byte instead byte and ubyte respectively. It doesn't make any sense to me unless they were really really drunk that night (or because any other obscure compatibility thing that I can't think of right now).

Where do I want my phone to be in 5 years?

noreply@blogger.com (Santiago L. Valdarrama) — Sat, 11 Aug 2012 10:39:57 PDT

In the past 3 years my phone went from a dumb-down Nokia I-can't-remember-the-model to an iPhone 4S and a Galaxy Nexus running Jelly Bean (Nokia N95, Blackberry World Edition, iPhone 3GS, and Nexus One along the way). This goes fast, so before the future gets here, here are the 10 main things I want my phone to be / do in the next 5 years.

Crazy good battery life. I'm talking about days of battery life, not hours. I just don't want to think about charging my phone anymore. I want wireless charging so just by getting closer to a power station my phone will charge itself without me even noticing.
Incredible lighter and thiner. They still feel bulky sometimes. A lot of progress has been made in this regard but so much can still be done. Imagine a phone that fits in your wallet (and I don't know why I would want to put it there, but you get the point).
100% voice controlled. I hate buttons and complicated interfaces. Voice is the natural replacement of these. Humans communicate using voice and we have seen already pretty compelling voice interfaces (read Siri and Google Now). They are good, but not great. I want to tell whatever I want to my phone and I want it to do it. No questions asked.
Full-featured payment mechanism. No more plastic. At all. Bye. I want to pay everything and everywhere with my phone. It's with me all the time and I shouldn't have to carry anything else in my pockets. Google Wallet et. al. are doing a good job, but we are still not quite there.
Again, no plastic. Following on the previous point, I don't want any plastic, including my ID. Any form of identification should be built into our phones. If I open my wallet right now, I can't find anything that can't be easily discarded in favor of an electronic replacement.
Key replacement. My car keys? Nope, my phone should open my car. My home keys? Same thing. Office? Mailbox? Yup. A bluetooth-type key-less system would be awesome: get close enough and the "thing" will open without having you to say / do anything.
An electronic identity. I didn't have a better name for this one. Basically, I'd like the phone to identify me everywhere I go (if I choose to, of course). At the bank the clerk will know about me without asking 20 questions. The cops won't have to ask for your "registration and license" anymore, and we'll save ton of time just by electronically answering / filling every form we have to. All this by just pressing a button.
No more paper. Plane tickets? Nope. Movie tickets? Concert tickets? Invitations? Checks? Receipts? You name it. Answer is no for all of them. Everything that requieres you to carry something should be replaced. The phone should take care. Magically.
Better shopping experience. Imagine going to a store, scanning (or touching?) the products you want and have someone instantly packing them at the front door for you to pick them up when you are done. No payment processing, no carrying carts around. Or real targeted ads showing only what I care about (yes, as seen on Minority Report).
Easily reemplazable and secure. Since our life will be so tightly coupled to our phone, we'll have to make them easily reemplazable and bullet-proof secure. Loosing your phone shouldn't be a pain other than having to buy a new one.

Think about it. We are not that far. I can even say we are almost there. Is more about the entire ecosystem evolving than the phones themselves.

YouTube is not going to be part of iOS 6

noreply@blogger.com (Santiago L. Valdarrama) — Mon, 06 Aug 2012 15:15:17 PDT

Apple: YouTube app will not be included in iOS 6.

Obviously you will be able to install it from the App Store. This is Apple showing more hate to everything Google-related. They told The Verge that this is because the license rights to include YouTube as a default application was not renewed, but I'm wondering who didn't want to renew it in the first place.

I particularly don't care besides the extra 30 seconds that I will have to spend to install the application, but it's scary how far away from Google Apple is getting. Starting from Gmail there are some Google products that I personally can't live without, and I have the feeling that more than few people feel the same. If Apple starts banning each one of them without a compelling replacement, they will hurt their sales. A lot.

Anyway, I'm hoping that Google have the app ready for the lunch of iOS 6 probably next month, and I'm also hoping that this Apple vs Google cancer doesn't spread anymore.

If you make your product interfaces obvious, everyone wins.

noreply@blogger.com (Santiago L. Valdarrama) — Sat, 11 Aug 2012 10:40:38 PDT

Key-less interfaces. This is where technology is going, and I love it. However, some people still don't get it and they still make horribly complex interfaces. The notion that a product is better if it has 100+ options is totally wrong, and the market its proving it. Make a simpler product, and you will destroy your competition.

My laundry machine has a speed-deal type control that I still don't know how to properly use after 2 years washing my clothes. I don't care either. It's fixed in one of the steps and that's what I've been using. Remove that thing and add one "start" button. I'm sold.

I bought a blender yesterday with 2 possible options: start and pulse. I paid $30+ bucks over other models with 20 non-sense buttons. I love it and I will gladly buy it over again next time. Do you know how much pain it removes from my life? I know how to use it without having to read any manual!
My iPhone has one button. Love it. My Galaxy Nexus has three. Why? I have to think every time before pressing one of them. I usually screw it by pressing the wrong one (I might be an idiot). I've never being confused with my iPhone, but I need to complain about my Android. Some phone makers re-order these buttons, so every phone could be different adding more confusion. I've also seen some models that make things worse by turning off the backlit making the buttons invisible to the user! You have to guess-press them to realize that you fucked it up and pressed the wrong one. Nice touch!
I used to hate those Windows keyboards with ~200 keys. Somebody thought that it was nice to add a key for every Windows pre-installed application on your hard drive. So you had a key for pulling up Notepad, one for IE, one for the calculator, and a huge painful bulky and confusing keyboard sitting on your desk. Not for me.
My former Honda Accord panel looked like a piano. You can easily get killed yourself trying to find the right button while driving. My new Audi A4 has 20 more features and uses less than half of the buttons. Needless to say how better it is and how much I like it.
Guess why I moved from Microsoft Office to Google Docs... Well, at least that's one of the reasons.

The list goes on and on.

Looking around I can find hundreds of examples where technology is getting simpler for users. Every button (option) counts and adds certain stress to the person that needs to use it. Complexity it's never welcomed and people recognize it by going more and more with the easiest product. I consider myself a pretty technical person, and nothing bugs me more than having to deal with a manual before using something. Make it simple and obvious and you'll save tons of paper!

I think that's the future. Key-less interfaces where products are easier to use and work without requiring so many configuration and input instructions. Look at Siri on iOS and the new Google Now on Jelly Bean. We are moving there very quickly.

And for you... please go ahead and rethink whatever is what you're doing. It probably can be simpler. It probably doesn't need so many options. Make us (and yourself) a favor and trim it down until you get rid of every "needed" instruction.

If you make it obvious, everyone wins.

Yes, he was hacked. Hard.

noreply@blogger.com (Santiago L. Valdarrama) — Sat, 04 Aug 2012 18:01:22 PDT

Yes, I was hacked. Hard.

Ouch.

This made me re-think my personal policy for passwords.

Access to protected and default (package) members in Java

noreply@blogger.com (Santiago L. Valdarrama) — Sat, 11 Aug 2012 10:35:36 PDT

Regarding visibility, protected is one of the most misunderstood modifiers in Java. It's always tricky to get it right, and when combined with the default (or package) visibility, it can become really confusing. Here is my attempt to cover every single possibility of these two access levels.

Let's start with some code:

package com.svpino.snippets.white;

public class Parent {
    void method0() {
        System.out.println("Parent::method0");
    }
 
    protected void method1() {
        System.out.println("Parent::method1");
    }
}

Here we are defining two methods, method0 has default visibility (since no modifier is specified), and method1 is protected. So far, so good. Let's see now the other class:

package com.svpino.snippets.white;

public class Child1 extends Parent {
 
    public void method2() {
        System.out.println("Child1::method2");
        method0();
        method1();
    }
}

The class Child1 is inheriting from Parent and its located on the same package. This means, that lines 7 and 8 are perfectly valid. Line 7 can be executed because method0 has package visibility and Child1 is located on the same com.svpino.snippets.white package as Parent. Line 8 is valid because method1 is protected so Child1 can access it through inheritance.

But, what if we try these methods from a different package? Let's see:

package com.svpino.snippets.black;

import com.svpino.snippets.white.Parent;

public class Child2 extends Parent {
 
    public void method2() {
        System.out.println("Child2::method2");
        method0(); // Error! This doesn't compile!
        method1();
    }
}

Now in this case, Line 9 is not valid anymore. We can't call method0 because we are on a different package than Parent. However, Line 10 is still valid since we are accessing a protected member through inheritance.

Now let's spice things up a little bit:

package com.svpino.snippets.white;

import com.svpino.snippets.black.Child2;

public class Neighbor1 {

    public void method3() {
        Parent parent = new Parent();
        parent.method0();
        parent.method1();

        Child1 child1 = new Child1();
        child1.method0();
        child1.method1();
        child1.method2();

        Child2 child2 = new Child2();
        child2.method0(); // Error! This doesn't compile!
        ((Parent) child2).method0();
        child2.method1();
        child2.method2();
    }
}

Line 9 has no problem to compile, since we are on the same package than Parent. Line 10 also compiles (and this is interesting) since the protected visibility in Java works the same as the package visibility. Keep that in mind all the time: A protected member has essentially package-level or default access to all classes except for subclasses.

Moving to the next block, Line 13 and Line 14 will also compile for the same reasons Line 9 and 10 compile respectively. Line 14 is calling a public method from Child1 so it will also compile. Nothing fancy here.

Let's see what happens in the last block. Line 18 doesn't compile because we are trying to access method0 through the Child2 class. If you go back to that class you'll see it's defined in a different package than Neighbor1, and because method0 has default visibility, it won't be visible at this point. However, casting child2 to a Parent will let us access method0. The compiler will validate that we do have access to everything defined with package visibility in the Parent class, so Line 19 won't be a problem.

Now, think about Line 20. It will compile, but why? It was kind of shocking for me discovering this. Supposedly, method1 should behave exactly as method0 since package visibility acts like default visibility, however there's another subtle difference between them. I had to check the Java specification to find the key:

6.6.1 (...) if the member or constructor is declared protected, then access is permitted only when one of the following is true:
* Access to the member or constructor occurs from within the package containing the class in which the protected member or constructor is declared.
(...)

Now compare that to the following about default access:

6.6.1 (...) Otherwise, we say there is default access, which is permitted only when the access occurs from within the package in which the type is declared.(...)

So the difference is that a protected member will be always accessible when the access occurs from within the package where the class containing the member was declared, meanwhile default access is only possible when the access occurs from the same package where the type (the type of the object we are using to access the member) was declared. In our case, the member method1 was declared in the package com.svpino.snippets.white, and we are accessing it from Neighbor1 which happens to be on the same package, so the access will be allowed even though we are using Child2 (the type) to do it.

It sounds complicated, and I had to read it more than once myself to make sense out of it. But if you pay careful attention to the wording, you'll see it. Finally, it's not surprising than Line 21 will compile since method2 has public access.

The code for our last test is as follows:

package com.svpino.snippets.black;

import com.svpino.snippets.white.Child1;
import com.svpino.snippets.white.Parent;

public class Neighbor2 {

    public void method3() {
        Parent parent = new Parent();
        parent.method0(); // Error! This doesn't compile!
        parent.method1(); // Error! This doesn't compile!

        Child1 child1 = new Child1();
        child1.method0(); // Error! This doesn't compile!
        child1.method1(); // Error! This doesn't compile!
        child1.method2();

        Child2 child2 = new Child2();
        child2.method0(); // Error! This doesn't compile!
        ((Parent) child2).method0(); // Error! This doesn't compile!
        child2.method1(); // Error! This doesn't compile!
        child2.method2();
    }
}

Lines 10 and 11 will not compile since we are accessing them from outside the package where they were defined. Same thing happens with lines 14 and 15, meanwhile line 16 is a simple public access.

Now, line 19 is trying to access a default member that was defined in a different package, so it won't compile. The cast in line 20 won't compile because Parent still belongs to a different package, and look how interesting is line 21. We can't access method1 even though it is inherited by Child2 from Parent. The reason is because once a subclass outside the package inherits a protected member, that member becomes private to any code outside the subclass with the exception of subclasses of the subclass. Yes, another tongue-twister, so you might want to read it again. Basically, as soon as method1 is inherited, its visibility becomes private to any outsider (like our Neighbor2 class).

So that's about it. Impressive how tricky these modifiers can be, specially the protected access. It took some time to wrap my head around all these concepts, but now I have it pretty clear.

Hope it helps.

Google delays launch of Nexus Q, gives free Q to those who pre-ordered

noreply@blogger.com (Santiago L. Valdarrama) — Tue, 31 Jul 2012 18:54:08 PDT

Google delays launch of Nexus Q, gives free Q to those who pre-ordered

I thought from the beginning that the Nexus Q was a half-baked product. It wasn't only pricey (due to being manufactured in U.S) but it offered 1/10th of the features found in competitor products. It was going to have a hard time to compete with so many more mature choices on the market.

I don't think Google is killing it. They are just taking it back to the drawing table. They need to rethink how the Q is going to fit in the consumer living-room where there's probably a Google TV / Apple TV / Roku Player / TiVo / XBox / you name it.

People don't want another gadget. Nobody is going to spend $300+ for a funny-looking ball that queues music from their friends' phones. They want something that solves a real problem and stands still next to the competition.

After the Google TV fiasco, the Q had an open ticket to the same party. I'm glad somebody stood and spoke and now Google backtracked to rethink their strategy. It's awesome they are honoring the pre-orders. Well done!

Verizon faces $1.25m fine for blocking third-party tethering apps

noreply@blogger.com (Santiago L. Valdarrama) — Tue, 31 Jul 2012 18:50:11 PDT

Verizon faces $1.25m fine for blocking third-party tethering apps

Uh oh... more about the carriers. Since I'm following technology I've never ever heard anything about carriers doing well for their customers. Unfortunately they are a necessary evil and they are taking advantage of that.

But nothing lasts forever. Carriers will change. They have to. At some point someone will do it differently and they will find themselves out of business. See the Google Fiber now getting into the TV provider arena. Same thing is going to happen with telephony at some point, and all the big guys are digging their own holes right now... they will miserably pay for that.

Wait and see.

Still waiting for Google+ comments on Blogger

noreply@blogger.com (Santiago L. Valdarrama) — Mon, 30 Jul 2012 18:14:37 PDT

More Google+ integration into Blogger, but still not integrated comments. I've been requesting, this, forever, but is still not here. Obviously is going to happen at some point because it's a natural transition for a product like Blogger. Question is when...

Is Computer Science overrated? Should we google stuff instead?

noreply@blogger.com (Santiago L. Valdarrama) — Sat, 28 Jul 2012 09:30:39 PDT

Lot of people say so. Apparently every successful technology company nowadays is started by drop-offs or folks that never went to college. Or at least that's what the press says. It's becoming a trend that everyone talks about and adepts strongly defend.

Bullshit.

Sorry but you are wrong. College is more important than ever. Computer Science has been, is, and will be the way to go. It will always make sense. It doesn't matter how many successful people you can count that didn't go to college, there are far more that went but they are not as exciting to talk about like the former.

But... they only teach you old stuff

Sure they do. Technology advances faster than any other industry in the world. Computer Science changes by the minute, but the foundation is the same. If every school changes their program every time a new framework-paradigm-tool sees the light, there won't be professors that can teach each new subject. It's not sustainable nor practical. This is not the way it works and it shouldn't be.

Instead, college is supposed to teach you the basis that you'll need to have a successful career. Stuff that you might think is old, or not useful, but that opens your mind and teaches you how to approach problems and find solutions for them. They make you think, analyze, understand... and you can't just simply google that. Solutions are out there, but if you don't know the root of the problem you will always be a good short-term copy-and-paste developer.

In every conversation I've had about this matter, I always refer back to algorithms. Think for a second about everything contained in such a simple word. This is not related with the latest and the greatest paradigms out there, or the best tools or frameworks. This refers to the basic ABC steps to tackle a problem and give a compelling solution. This knowledge stays and never fades off with the time. Instead, it gets better as you gain more experience, and it's precisely one of the main focus of every Computer Science school. Books about this could be from 1980 but they are still valuable, sometimes more than ever. And the perfect way to reach all this knowledge is by attending school.

But... 4 - 5 years is still a long time

Yup, it's the perfect period to make you mature and give you everything you need to have a successful start out there. If you are waiting for a program that's going to make you proficient in the latest technology paradigm you might better get comfortable because it's never going to happen. Instead, use these years to suck everything valuable and complement all that with today's advances.

If you go to school only to listen and read, you'll fail. Be proactive. Be always one step ahead. Read and then ask. Listen and then compare. Think about how you can apply everything that you've been taught to what you want to do. There's going to be hundreds of people smarter than you around, so use them to get every piece of knowledge you can out of them. During school is OK to fail, try and fail again, research, innovate, everything is allowed and everything will make you better. Real life is full of real problems and you won't have such a luxury. Use the time, and use it wisely.

But... but...

There's always going to be another reason not to go. And if you can't or won't it's alright, but you'll have to make up for that time in a different way. 90% of the smarter people that I know went to college, but the other 10% are as good as everyone else. That happens, but it doesn't mean that works for everyone.

Way before college I knew how to solve some problems. Heck, even some complicated ones. But most of the time I didn't know why the damn thing worked. Was more like a trial - error approach. College helped me with that and made me a far better engineer than what I was before. I was lucky, but I helped a ton my luck studying. And you can also do it instead of thinking that you'll be wasting your time.

There has never been a better time to go to school. Stop thinking that you're going to be the next Mark Zuckerberg or Steve Jobs if you don't go or drop off. Chances are that you won't, and you will hurt your formation in a very bad way during the process.

So, think again.

Design and test. Go back and start the same process over and over again

noreply@blogger.com (Santiago L. Valdarrama) — Fri, 27 Jul 2012 20:23:32 PDT

Yes, this is the Nth time I play with the look 'n feel of the blog, but I really like to explore new things. Unfortunately I'm not a designer, so it takes me more time than normal to settle with something that I really like.

Today I can go to bed feeling that the site looks better than ever (it doesn't mean I'm 100% happy though). A huge accomplishment was adding Prettify to format the source code. Neat, but I'd have to go through every single post in my archive and add some styles to get it working. Not gonna happen today... but it will.

The next goal will be to fix some navigation issues and add links to the RSS of the blog, Twitter, and Google+ (middle finger to Facebook). Hope to get it done by this coming week, will see.

If you have something to say about my extra-minimalist design, go ahead.

If you really want to get something done, you have to stand up and make it happen

noreply@blogger.com (Santiago L. Valdarrama) — Thu, 26 Jul 2012 20:10:30 PDT

Not surprising, but still I'm amazed how easy is to loose track of things and let time pass by without accomplishing anything. Too bad the default setting for people is to drag their feet on everything they don't like to do (or care for).

Probably you have to deal with this every day. Maybe you are on the lazy side most of the time (I've been there too!). That's the moment when somebody else will show up and embarrass you by getting done 90 percent of the work in the time it took you to get through the initial 10 percent.

If you want to make a difference, go and start showing everyone else how it should be done. It's so easy to do it differently, to do it better. It's so worth it and so well compensated. Still, very few people seem to care.

There hasn't been a better time to shine. Go!

Bye Facebook. Hello Google+

noreply@blogger.com (Santiago L. Valdarrama) — Mon, 16 Jul 2012 15:45:52 PDT

On my email today:

Hi Santiago, You have deactivated your Facebook account. You can reactivate your account at any time by logging into Facebook using your old login email and password. You will be able to use the site like you used to. Thanks, The Facebook Team

Yes I did. Sorry. Too many invitations to FarmVille and cute little cats on my feed. I would rather move to a safer place.

Connectivity and Battery Life in Android. Making them play nicely.

noreply@blogger.com (Santiago L. Valdarrama) — Fri, 27 Jul 2012 19:48:26 PDT

Last week I announced Stocktile, a stock market application to make my life easier and enjoy checking on my tickers even more. At the end of that post, I wrote the biggest lesson I learnt while I was developing the app:

Main challenge: The web is always online. Mobile applications are not. It's an entire layer of complexity added to our applications.

Indeed. Not having a reliable and fast Internet connection all the time is something traditional developers are not used to. Mobile imposes this restriction, and we have to deal with it if we want to make our applications solid options for consumers.

But it's not just about connectivity

There's another challenge though that we don't need to worry about outside the mobile ecosystem: battery life. In such small devices, there's a very small battery and dozen of applications competing to use a pice of it. Unfortunately, technology is still not where we can stop worrying about how much power our application sucks, so we need to use it carefully or face the anger of our users.

So connectivity and battery life are the main two players. They need to play seamlessly and safe. Unfortunately is difficult to get it right, so a lot of developers don't pay attention to these details. That's mainly why tons of Android apps are battery and data-plans killers. They just don't care.

On the Android developers site there are two awesome articles explaining the ins and outs of developing and application that properly takes care of connectivity and battery life. I'm not going to reproduce here everything said, but I strongly recommend any developer to read those training sessions. I want to focus instead in the code that powers Stocktile, and how I combined different techniques to make the application a good citizen in Android-land.

Setting our rules

First of all, take into account that every application is different and requires a different level of thinking. What works for me, might not work for a news application or any other category. However, the approach is very similar, so I hope to help more than one out there.

Stocktile downloads the market information for every stock ticker added to your dashboard. You can have 3 tickers, or hundreds of them. Not matter how many, you surely want them to display the latest market information available all the time. That's the point, and that was my goal. However, because I'm feeding my app using the Yahoo! Finance API, there's going to be a minimum delay of 15 minutes between market updates. That's the first constraint I have to play with: no updates will be requested if the latest one was less than 15 minutes ago.

But what happens if the user is not using the application? Do we want to keep updating it? Remember that every update will impact the user's data-plan and the battery life of the device, so the answer is no. If the users don't care about our app, why bothering them with updates they are not going to see? So that's the second rule: the application will be updated only if users are actively using it.

However, downloading information from the network takes time, and we don't want our users waiting from fresh data to come when they open our app. So we should rethink our updates policies: what about updating automatically even if the user is not actively using the app but only when the device is plugged to a power source and connected to a WiFi network? That sounds better!

There are two more use cases that I had to take care of: when the user adds a new ticker to the dashboard, we want to update it immediately. And, if during an update an error occurs, we need to re-schedule the next update as soon as possible. However, it might be the case that something is wrong with the server so a continuous update will further damage the battery life of the device. To solve this, we need to employ a back-off pattern as explained on the Android training classes.

So let's put everything together:

The minimun time between updates will be 15 minutes.
If the user is not using the application, new information is going to be downloaded only when the device is plugged to a power source and running on a WiFi network.
If the user adds a new ticker, an update will be performed immediately only for that ticker.
If an error occurs while updating, a new back-off update will be scheduled as soon as possible.

The BatteryBroadcastReceiver

Let's take a look to all the code pieces that make up these guidelines. Let's start with our second rule above. For that one, we need to create two different BroadcastReceivers, one for monitoring the battery and the other to monitoring connectivity changes. Look at the following lines in our manifest file:

<receiver
    android:name=".BatteryBroadcastReceiver"
    android:exported="false" >
    <intent-filter>
        <action android:name="android.intent.action.ACTION_POWER_CONNECTED" />
        <action android:name="android.intent.action.ACTION_POWER_DISCONNECTED" />
    </intent-filter>
</receiver>

Then our Java class:

public class BatteryBroadcastReceiver extends BroadcastReceiver {

    private final static String LOG_TAG = BatteryBroadcastReceiver.class.getName();

    @Override
    public void onReceive(Context context, Intent intent) {
        if (isTheBatteryPluggedIn(context)) {
            if (areWeUsingWiFi(context)) {
                Log.d(LOG_TAG, "On WiFi and charging, let's update");

                Intent intent = new Intent(context, MarketCollectionReceiver.class);
                intent.setAction(Constants.SCHEDULE_BACKGROUND);
                PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, 
                    PendingIntent.FLAG_UPDATE_CURRENT);

                ((AlarmManager) context.getSystemService(Context.ALARM_SERVICE))
                    .setInexactRepeating(AlarmManager.RTC_WAKEUP,
                        System.currentTimeMillis(),
                        AlarmManager.INTERVAL_HALF_HOUR,
                        pendingIntent);
            }
   
            ComponentName componentName = new ComponentName(
                context,
                ConnectivityBroadcastReceiver.class);          
            context.getPackageManager()
                .setComponentEnabledSetting(componentName,
                 PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
                 PackageManager.DONT_KILL_APP);
        }
        else {
            Log.d(LOG_TAG, "Not charging anymore. Hold off in any new updates");
                
            Intent intent = new Intent(context, MarketCollectionReceiver.class);
            intent.setAction(Constants.SCHEDULE_BACKGROUND);
            PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, 
                PendingIntent.FLAG_UPDATE_CURRENT);

            ((AlarmManager) context.getSystemService(Context.ALARM_SERVICE))
                .cancel(pendingIntent);
   
            SharedPreferences pref = context.getSharedPreferences(
                Constants.PREFERENCES, Context.MODE_PRIVATE);

            boolean areWeWaitingForConnectivity = 
                pref.getBoolean(Constants.PREFERENCE_STATUS_WAITING_FOR_CONNECTIVITY, false);
   
            if (!areWeWaitingForConnectivity) {
                ComponentName componentName = new ComponentName(context, 
                    ConnectivityBroadcastReceiver.class);
                context.getPackageManager().setComponentEnabledSetting(
                   componentName, 
                   PackageManager.COMPONENT_ENABLED_STATE_DISABLED, 
                   PackageManager.DONT_KILL_APP);
            }
        }
    }
}

Looks more complicated than what really is. Let's go step by step. The very first line asks whether the battery is plugged in or not. Here is that code:

public boolean isTheBatteryPluggedIn(Context context) {
    Intent batteryIntent = context.getApplicationContext()
        .registerReceiver(null, new IntentFilter(Intent.ACTION_BATTERY_CHANGED));
 
    int plugged = batteryIntent.getIntExtra(BatteryManager.EXTRA_PLUGGED, -1);
    return plugged == BatteryManager.BATTERY_PLUGGED_AC 
        || plugged == BatteryManager.BATTERY_PLUGGED_USB;
}

Then we ask whether we are using WiFi:

public static boolean areWeUsingWiFi(Context context) {
    ConnectivityManager connectivityManager = 
        (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
  
    NetworkInfo networkInfo = connectivityManager.getActiveNetworkInfo();

    boolean isConnected = networkInfo != null ? networkInfo.isConnected() : false;
    boolean isWiFi = isConnected 
        ? networkInfo.getType() == ConnectivityManager.TYPE_WIFI : false;

    return isWiFi;
}

In case both conditions are true updates are safe, so we can schedule a regular update using the AlarmManager service. Note how these updates will be performed every 30 minutes since the user is not necessarily using the application.

After the update is scheduled, another important thing is done in the code: a BroadcastReceiver for connectivity updates is enabled. Why? Because we need to be notified as soon as the user is not longer connected to the WiFi network. Since connectivity updates are very frequent, we don't want to keep the BroadcastReceiver enabled all the time, so we enable and disable it as needed.

Now, what happens if the battery is not plugged in? Well, we need to hold off in any new updates, so we go ahead and cancel any pending schedule. Also, if we are not actively waiting for the device to go back online, we can also disable the connectivity BroadcastReceiver until we get back plugged in to the wall. Pay special attention to the areWeWaitingForConnectivity flag. This is going to be true in case an error occurred while updating and we are waiting for the connectivity to come back to re-run the update.

The ConnectivityBroadcastReceiver

First, we need to declare our receiver in the manifest file. Note how we want it to be disabled by default. Our code will take care of enabling it only when necessary:

 <receiver
    android:name=".receivers.ConnectivityBroadcastReceiver"
    android:enabled="false"
    android:exported="false" >
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
        </intent-filter>
</receiver>

Then the Java class:

public class ConnectivityBroadcastReceiver extends BroadcastReceiver {
    private final static String LOG_TAG = ConnectivityBroadcastReceiver.class.getName();

    @Override
    public void onReceive(Context context, Intent intent) {
        if (areWeOnline(context)) {
            SharedPreferences pref = context.getSharedPreferences(Constants.PREFERENCES, 
                Context.MODE_PRIVATE);
            boolean wereWeWaitingForConnectivity = sharedPreferences.getBoolean(
                Constants.PREFERENCE_STATUS_WAITING_FOR_CONNECTIVITY, false);

            if (wereWeWaitingForConnectivity) {
                Log.d(LOG_TAG, "Connectivity was just re-established, let's update.");
            
                DataProvider.startStockQuoteCollectorService(context, null);

                ComponentName componentName = new ComponentName(
                    context, ConnectivityBroadcastReceiver.class);
                context.getPackageManager().setComponentEnabledSetting(
                   componentName, 
                   PackageManager.COMPONENT_ENABLED_STATE_DISABLED, 
                   PackageManager.DONT_KILL_APP);
            }       
            else {
                if (areWeUsingWiFi(context)) {
                    if (isTheBatteryPluggedIn(context)) {
                        Log.d(LOG_TAG, "We are on WiFi and charging, so let's update");

                        Intent intent = new Intent(context, MarketCollectionReceiver.class);
                        intent.setAction(Constants.SCHEDULE_BACKGROUND);
                        PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, 
                            intent, 
                            PendingIntent.FLAG_UPDATE_CURRENT);

                        ((AlarmManager) context.getSystemService(Context.ALARM_SERVICE))
                            .setInexactRepeating(AlarmManager.RTC_WAKEUP,
                                System.currentTimeMillis(),
                                AlarmManager.INTERVAL_HALF_HOUR,
                                pendingIntent);
                   }
               }
               else {
                   Log.d(LOG_TAG, "We aren't using WiFi, so don't update");

                   Intent intent = new Intent(context, MarketCollectionReceiver.class);
                   intent.setAction(Constants.SCHEDULE_BACKGROUND);
                   PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, 
                       intent, 
                       PendingIntent.FLAG_UPDATE_CURRENT);

                   ((AlarmManager) context.getSystemService(Context.ALARM_SERVICE))
                       .cancel(pendingIntent);
               }
           }
       }
       else {
           Log.d(LOG_TAG, "We aren't online so don't update.");

           Intent intent = new Intent(context, MarketCollectionReceiver.class);
           intent.setAction(Constants.SCHEDULE_BACKGROUND);
           PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, 
               PendingIntent.FLAG_UPDATE_CURRENT);

           ((AlarmManager) context.getSystemService(Context.ALARM_SERVICE))
               .cancel(pendingIntent);
        }
    }
}

Very similar to the BatteryBroadcastReceiver, but in this case we start asking if we are online (not only on a WiFi, but with any Internet access):

public boolean areWeOnline(Context context) {
    ConnectivityManager connectivityManager = (ConnectivityManager)     
        context.getSystemService(Context.CONNECTIVITY_SERVICE);
    NetworkInfo networkInfo = connectivityManager.getActiveNetworkInfo();

    return networkInfo != null ? networkInfo.isConnected() : false;
}

If we are, and we were waiting for the connectivity to come back (an error occurred while updating), then we run an update immediately and disable the BroadcastReceiver. If we don't need an immediate update, then we ask whether the battery is plugged in, and we are on a WiFi connection. From there, everything is pretty much the same to the BatteryBroadcastReceiver.

Receiving alarms and firing updates

These two BroadcastReceivers work pretty well in conjunction to schedule our background updates, but there's another piece they need to fire up the updates: another BroadcastReceiver that's going to be kicked off by the scheduled alarms. Round of applauses for our MarketCollectionReceiver:

public class MarketCollectionReceiver extends BroadcastReceiver {
    private final static String LOG_TAG = MarketCollectionReceiver.class.getName();

    @Override
    public void onReceive(Context context, Intent intent) {
        if (intent.getAction().equals(Constants.SCHEDULE_RETRY)) {
            SharedPreferences pref = context.getSharedPreferences(
                Constants.PREFERENCES, Context.MODE_PRIVATE);

            boolean retrying = pref.getBoolean(
                Constants.PREFERENCE_COLLECTOR_RETRYING, false);

            if (retrying) {
                Log.d(LOG_TAG, "Retrying update...");
                DataProvider.startStockQuoteCollectorService(context, null);
            }
            else {
                Log.d(LOG_TAG, "Update was already successfully performed");
            }
        }
        else if (intent.getAction().equals(Constants.SCHEDULE_BACKGROUND)) {
            if (isTheBatteryPluggedIn(context) && areWeUsingWiFi(context)) {
                Log.d(LOG_TAG, "Performing background update...");
                DataProvider.startStockQuoteCollectorService(context, null);
            }
            else {
                Log.d(LOG_TAG, "We are not longer able to perform background updates");
                Intent intent = new Intent(context, MarketCollectionReceiver.class);
                intent.setAction(Constants.SCHEDULE_BACKGROUND);
                PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, 
                    intent, 
                    PendingIntent.FLAG_UPDATE_CURRENT);

                ((AlarmManager) context.getSystemService(Context.ALARM_SERVICE))
                    .cancel(pendingIntent);
            }
        }
        else if (intent.getAction().equals(Constants.SCHEDULE_AUTOMATIC)) {
            Log.d(LOG_TAG, "Performing automatic update");
            DataProvider.startStockQuoteCollectorService(context, null);
        }
    }
}

If you take a closer look to the code above, you'll notice that this BroadcastReceiver is using the action of the passed Intent to determine what kind of update was scheduled. In our Battery and Connectivity broadcast receivers we only use "BACKGROUND" updates, but the application uses three different types: BACKGROUND, RETRY, and AUTOMATIC. When the device is plugged in, and is on WiFi, we fire a BACKGROUND update. If an error occurs while updating, we fire a RETRY update. If the user is actively using the application or a new ticker is added, we fire an AUTOMATIC update. The rest of the code, should be self-explanatory.

Now, what about our back-off updates?

That happens when the update occurs. I'm not going to post the entire Service that takes care of the updates, but just the relevant sections:

...
int retries = sharedPreferences.getInt(Constants.PREFERENCE_COLLECTOR_RETRIES, 0);
...                 

if (retrying || wereWeWaitingForConnectivity || areWeUpdatingOnlyOneTicker 
    || (!areWeUpdatingOnlyOneTicker 
        && currentTime - lastUpdate > Constants.COLLECTOR_MIN_REFRESH_INTERVAL)) {
    try {
        update(...);
 Log.d(LOG_TAG, "Update was successfully completed");
 ...
    }
    catch (Exception e) {
        Log.e(LOG_TAG, "Update failed.", e);
    
 if (areWeOnline(this)) {
     Log.d(LOG_TAG, "Scheduling an alarm for retrying the update...");

            retries++;

            Editor editor = sharedPreferences.edit();
            editor.putBoolean(Constants.PREFERENCE_COLLECTOR_RETRYING, true);
            editor.putInt(Constants.PREFERENCE_COLLECTOR_RETRIES, retries);
            editor.commit();

            long interval = Constants.COLLECTOR_MIN_RETRY_INTERVAL * retries;
            if (interval > Constants.COLLECTOR_MAX_REFRESH_INTERVAL) {
                interval = Constants.COLLECTOR_MAX_REFRESH_INTERVAL;
            }                     
  
            Intent intent = new Intent(context, MarketCollectionReceiver.class);
            intent.setAction(Constants.SCHEDULE_RETRY);
            PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, 
                intent, 
                PendingIntent.FLAG_UPDATE_CURRENT);
     
            ((AlarmManager) getSystemService(Context.ALARM_SERVICE))
                .set(AlarmManager.RTC, 
                    System.currentTimeMillis() + interval, 
                    pendingIntent);
        }
 else {
     Log.d(LOG_TAG, "We are not online.");
     
            Editor editor = sharedPreferences.edit();
     editor.putBoolean(
                Constants.PREFERENCE_STATUS_WAITING_FOR_CONNECTIVITY, true);
            editor.commit();
     
            ComponentName componentName = 
                new ComponentName(this, ConnectivityBroadcastReceiver.class);
            getPackageManager().setComponentEnabledSetting(
                componentName, 
                PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
                PackageManager.DONT_KILL_APP);
        }
    }
}

First, note the retries variable. Every time an error occurs, we increment a counter and save it in our preferences. The next update will use this value to delay every update and avoid retries when the server is continuously failing. Note how in this case we set up the alarm with a RETRY action. In case we are online when the error occurs, then we set the flag WAITING_FOR_CONNECTIVITY and enable our ConnectivityBroadcastReceiver to get notified as soon as we are back online.

The other bit of code to pay attention is the flag areWeUpdatingOnlyOneTicker. Although I didn't post the section where this flag gets initialized, it means than the user added a new ticker to the dashboard and we need to run an update just for it.

It's a lot, I know

Yes, it gets tricky, verbose, and it's easy to loose track of every component. By reading back what I just wrote I'm realizing how painful is for developers to take care of so many details. Some day this will get done for us under the hood, or we won't need to worry anymore when technology gets to a point where battery and connectivity are not longer a concern. Unfortunately we are not there yet, and this topic is really important if we want to develop an application that doesn't kill our devices.

Read closely. Try for yourself, and ask if you get lost.

It just works

noreply@blogger.com (Santiago L. Valdarrama) — Sun, 15 Jul 2012 19:18:09 PDT

From the Android documentation:

If you're developing on Windows, you need to install a USB driver for adb. For an installation guide and links to OEM drivers, see the OEM USB Drivers document.

If you're developing on Mac OS X, it just works. Skip this step.

If you're developing on Ubuntu Linux, you need to add a udev rules file that contains a USB configuration for each type of device you want to use for development. In the rules file, each device manufacturer is identified by a unique vendor ID, as specified by the ATTR{idVendor} property. For a list of vendor IDs, see USB Vendor IDs, below.

See where I'm going here?

Stocktile sees the light

noreply@blogger.com (Santiago L. Valdarrama) — Fri, 27 Jul 2012 19:59:54 PDT

Finally! Stocktile is out!
After 4 weeks of long nights in front of my computer, Stocktile is live on Google Play in two different versions: Lite and HD. Mostly, I'm glad because now I get to use an application that does exactly what I want... nothing less, nothing more. If you want to see some screenshots, follow any of the links above.

What I've learnt has been huge. Lots and lots of things to share about the Android platform. Let's see what can I put together when I get my strength back from this past month.

Before going to bed, I do want to share the main lesson from these days. Copied from a tweet I posted 4 days ago:

Main challenge: The web is always online. Mobile applications are not. It's an entire layer of complexity added to our applications.

Think about it.

Playing a little bit with functional programming

noreply@blogger.com (Santiago L. Valdarrama) — Mon, 02 Jul 2012 23:25:38 PDT

You should start reading "Functional Programming - Why should we care?" and take a look to the example C# code at the end of the article.

Then, if you are more of a Java fan, move onto "Functional Programming - Rewriting the example in Java" to see how to do the same thing without delegates and Lambda expressions.

Yes, the second article is mine (not the first one, though). I will be posting from time to time in my company's blog and linking the articles here.

Google I/O is about to start...

noreply@blogger.com (Santiago L. Valdarrama) — Tue, 26 Jun 2012 22:00:00 PDT

Just a few more hours... I'm super excited about the Android sessions. Can't wait to see what Google pulls off. We'll see soon enough.