I’m not an Android or iOS software engineer, so all I can say in response to any of this is that, assuming Munn’s correctly articulated the way rendering takes places on Android and iOS devices, it makes sense (but then so does the idea that Lee Harvey Oswald had help, at least to some people).

Peckham makes no mention of trying to corroborate Munn's claims with a more experienced, knowledgeable engineer, like Romain or Dianne from the Android team, nor does he reference the corrections made by iOS experts in the comments on Munn's post. A more qualified engineer would support their theories with evidence like code, specifications, and performance test results, not Reddit and Hacker News comments as Munn did.

I don't claim to have all the answers, but I can tell you that implementing fluid interfaces on both iOS and Android is time consuming and difficult. The challenges are an order of magnitude more complex than Munn suggests. I haven't had an opportunity to try Ice Cream Sandwich yet, so I can't tell you firsthand how it compares to the iPhone. However, Jason Kincaid, quoted by Munn, described ICS as quite smooth and noted that both Android and iOS stutter occasionally.

Now that Android has pervasive hardware acceleration, Android has no fundamental technical disadvantage compared to iOS with regard to to implementing fluid UIs. Given comparable hardware, any UI that runs smoothly on iOS should be able to run just as smoothly on Android. That said, hardware acceleration isn't a magic switch that you can just turn on. Android developers need to modify their applications to take full advantage, just like iOS developers have to design their own applications with hardware acceleration in mind. This will take time.

To Munn's point, "UI thread" and "main thread" mean the same thing. Most user interface frameworks, including those employed by iOS and Android, have a notion of receiving input events and manipulating the user interface from a single thread. Users of those frameworks often use the terms "UI thread" and "main thread" interchangeably. Why impose this restriction? If you limit access to UI elements to a single thread, you simplify API usage and improve performance because you don't have to deal with locks and concurrency. Contrary to Munn's claims, Android does actually assign a higher scheduling priority to the UI thread than it does to background threads. I assume iOS does likewise.

Android and iOS are more alike than different in this respect. Either platform will hang and stop responding to user input if you monopolize the main thread with blocking operations (like file I/O) or slow drawing logic. This likely explains why Jason experiences jitters when visiting global search on iOS. On both platforms, programmers should perform all blocking operations on background threads and should never block the main thread.

As for the differences, iOS's Core Animation framework tweens animations in a background thread while Android does the same in the main thread. On iOS animations continue running, even when the application accidentally blocks the main thread. In addition, when scrolling, iOS's main thread goes into a "tracking" mode where it filters out certain types of events that might result in redrawing or other performance degradations. This has no affect on background operations. Nothing technically prevents Android from supporting these features, but their absence doesn't preclude smooth UIs on Android either. Hardware acceleration is far more important.

Does this mean we're going to start seeing iOS-quality user interfaces across the board on Android in the near future? No way. The reasons have little to nothing to do with bytecode or garbage collectors and everything to do with the community and tools. First, iOS app developers have far more experience taking advantage of hardware acceleration. They're experts in going out of the way to avoid software rendering. Hardware rendering requires a different mindset, and Android programmers will need time to catch up.

Second, Android programmers need to support both software and hardware rendering for awhile. This requires more code. Some Android devices support only software rendering while others, like the Xoom, actually require hardware rendering to achieve any semblance of smooth animation. Developing and maintaining smooth Android apps will require significantly more developer resources than accomplishing the same on iOS, at least until we can retire support for pre-Honeycomb devices. Programmers with limited resource will no doubt have to elide animations and settle for lowest common denominator solutions for awhile.

Third, from what I've seen, iOS developers have far better tools at their disposal. iOS developers can tweak and reload their applications in seconds, faster than you can reload a Ruby on Rails web page, while Android developers are lucky to do the same in tens of seconds. Being able to quickly iterate and tweak a UI is essential to achieving pixel-perfect, high frame rate animations. If Android programmers need to wait up to a minute after each tweak, they'll be at a significant disadvantage compared to their iOS counterparts. iOS provides amazing tools that overlay their UIs and help pinpoint and eliminate software rendering. In contrast, the UI performance and bugs in Android's emulator are so bad that developers resort to running on real devices only, even during development.

Android's training and legacy support issues will resolve themselves eventually. If I ran the Android team, I'd triple down on tool support. Android's emulator sounds great in theory, but it fails spectacularly in practice. Professional Android programmers simply can't and don't use it. Frankly, the emulation model is a lost cause. Android should replace it with an iOS-like simulator, one with tightly integrated profiling tools, capable of building and displaying apps in seconds. Ideally, the development build process would further cut down the turnaround time by eliding resource compilation, dex conversion, etc.

In the meantime, Android developers can achieve buttery user interfaces on Honeycomb and ICS devices, just like their iOS equivalents, by eliminating blocking operations from the main thread, minimizing time spent drawing in software, and allocating objects judiciously. Android programmers just have to work a little longer and harder to get there. Given our fierce dedication to a flawless user experience, my team plans to invest the necessary resources and accomplish just that. If you think you're up to the challenge, please apply.

For additional reading, Dianne has done a wonderful job explaining why the Android team made the choices they did and how those choices enabled some unique advantages over iOS.

For example, Square’s Luhn filter monitors logs and masks anything that looks like a credit card number. If a number like “4111 1111 1111 1111” were accidentally logged as part of an error message, our filter would replace it with “XXXX XXXX XXXX XXXX” and page an on call engineer.

Starting from the rightmost digit and working left, double every second digit.

If a product has two digits, treat the digits independently.

Sum each individual digit, including the non-doubled digits.

Divide the result by 10.

If the remainder is 0, the number passed the Luhn check.

For example, “5678” passes the Luhn check:

Double every other digit: 10, 6, 14, 8

Sum the individual digits: (1 + 0) + 6 + (1 + 4) + 8 = 20

Divide the result by 10: 20 mod 10 = 0 Pass

“6789” does not:

Double every other digit: 12, 7, 16, 9

Sum the individual digits: (1 + 2) + 7 + (1 + 6) + 9 = 26

Divide the result by 10: 26 mod 10 != 0 Fail

Now for the challenge…

Write a command line program that reads ASCII text from standard input, masks sequences of digits that look like credit card numbers, and writes the filtered text to standard output. For the purposes of this challenge, a credit card number:

Consists of digits, spaces (' ') and hyphens ('-').

Has between 14 and 16 digits, inclusive.

Passes the Luhn check.

If a sequence of digits looks like a credit card number, replace each digit with an 'X'. Any characters, including digits, may flank a credit card number. Beware. Potential credit card numbers can overlap. A valid 16-digit number can even contain a valid 14 or 15-digit number. Your program must mask every digit.

I already wrote a test suite, so you can jump straight to the fun part: writing the algorithm. To participate:

Modify mask.sh and make the tests pass. Line feeds delineate the test cases. If you pass a number on the command line, run.sh will repeat the test suite the specified number of times; this is useful for performance comparisons. The tests aren’t set in stone—if you have an idea for improving the test suite, please submit a pull request.

This isn’t a contest, but an innovative solution could score you interviews at Square. I’m primarily interested to see how different programming languages stack up with regard to readability and performance.

Once we have enough interesting submissions, I’ll summarize the results in a followup blog post and open source our own Java-based implementation. In the mean time, if you enjoy working with talented people on challenging problems like this, email your résumé to luhnybin@squareup.com.

Tuesday, November 16, 2010

Sometimes doing the right thing can be extremely difficult. In spite of and because of my commitment to Java, I had to decline an invitation to join the Java SE 7 and 8 expert groups. Talk about a tough decision!

Why did I decline? I'll contribute to open source projects and open standards, standards I can independently implement and license as open source. Java SE, with its anti-competitive licensing restrictions, is not an open standard. It doesn't belong in the thus far open JCP, and I can't support such a charade. I stand by Apache, and I hope Eclipse comes around.

I'm not a lawyer, but I can't help but wonder whether Oracle even has a right to apply additional licensing restrictions to the intellectual property in Java SE. Oracle didn't create Java SE on their own. Look at the list of JSRs pulled into Java SE 7 and SE 8 (see the Contributions sections). Look at the experts on those JSRs. Most of them aren't from Oracle. For example, JSR 310: Date and Time API comes from our own Stephen Colebourne.

The JSPA section 4.D protects experts in these situations, enabling them to withdraw their IP contributions if a spec lead, Oracle in the case of Java SE, changes the licensing terms:

Withdrawal of Contributions due to Change in Announced License Terms. If the Spec Lead for an Expert Group in which You are participating makes significant changes to the terms and conditions of any license granted pursuant to Sections 5.B or 5.F below after those terms and conditions are first disclosed pursuant to the Process, then You may, upon giving notice to the Specification Lead and the PMO, withdraw any copyright or patent licenses concerning Your Contributions granted pursuant to Section 4.A.I or 4.A.II above (but not patent licenses granted by You pursuant to Section 6 below).

It's not clear to me exactly how section 4.D applies to umbrella JSRs like Java SE, but I'd say that changes preventing independent open source implementations qualify as a "significant."

Monday, November 01, 2010

Today is the last day to vote in the JCP EC election. If you're a JCP member, you received voting instructions in an email from pmo@jcp.org with the subject line JCP Elections 2010 end November 1! This email contains the link and your password.

Voting

If you're a JCP member, you received voting instructions in an email from pmo@jcp.org with the subject line "JCP Elections 2010: vote today." The email contains a link and a password. If you have any problems, email admin@jcp.org or call 1-866-543-8750 (US or Canada) or 1-202-207-0529 (International).

Why vote for me?

You're no doubt aware that a bargaining impasse between Apache and Sun/Oracle has virtually halted progress within the JCP over the past five years. Openness of Java SE is critical in the fight against its real competition: .NET, V8, Erlang, Flash, et al. I'll do everything I can to ensure an open future for Java, but we can't let one JSR grind the JCP to a halt. Life must go on.

If you blinked, you might have missed it. JSR 330, Dependency Injection for Java, completed the shortest development cycle of any Java Specification Request on record within the Java Community Process (JCP) program, a feat that looked only theoretically imaginable on paper until Bob Lee proved it could be done. As co-Spec Lead of JSR 330, Bob wasn't focusing specifically on agility when he pushed the envelope. "While I'm glad JSR 330 executed quickly, I'm even prouder of our specification's quality. I think we raised the bar," he says.

How is it possible to achieve both speed and superiority? Doesn't something have to give? In fact, Bob gave a lot to make this happen, and other Spec Leads can learn a lot by retracing his steps. He attributes the short execution time and enhanced quality to a number of factors, including a crack team of Experts, an aggressive schedule that hacked the normal process, transparency, limited scope, and a willingness to collaborate, compromise, question assumptions, and think outside the box.

If you elect me...

I'll continue this record of innovation and pave the way for more JSRs like 330. I'll introduce an abbreviated process for Open JSRs. JSRs that meet our criteria for openness will be able to follow an easier, faster, simpler specification process. This process will motivate more open JSRs. It will free spec leads up to focus more on the technology and less on the process. It will attract more experts to the JCP and ensure a bright future for Java.

Friday, February 05, 2010

We use a self-signed SSL certificate for the test version of our backend web service. Since our certificate isn't signed by a CA that Android trusts by default, we need to add our server's public certificate to our Android app's trusted store.

These same instructions apply to trusting a custom CA, except you'd get the public certificate directly from the CA instead of from a server.