Profile cover photo
Profile photo
Jake Wharton

Post has shared content

Post has attachment
Use a Nexus or Artifactory instance at your company for hosting/proxying dependencies? I wrote a script which synchronizes all of the artifacts from your local Android SDK to a remote repo of your choice.

Post has attachment

Post has attachment
Game 1. Let's go Pens!

Post has attachment
Java Interoperability Policy for Major Version Updates

Major version updates to libraries solve the API warts of old and bring shiny new APIs to address previous shortcomings—often in a breaking fashion. Updating an Android or Java app is usually a day or two affair before you reap the benefits. Problems arise, however, when other libraries you depend on have transitive dependencies on older versions of the updated library.

+Jesse Wilson offers candid insights from user perspective as well:

Ultimately, we fight for the user!

Post has shared content
Surprise! Extra #AndroidDialogs this week. +Huyen Tue Dao talks with +Jake Wharton on RxJava, RxAndroid, writing libraries & optimization.

As always, subscription and sharing appreciated :)

Post has attachment
The video from my "Simple HTTP with Retrofit 2" talk at Droidcon NYC is now available.

The slides are available separately here:

Some of the APIs around implementing Converters and CallAdapters (the very end of the talk) has already changed on master and a beta2 should be released in a week or two which fixes some bugs found by early users.


Post has attachment
I have uploaded my slides from "Simple HTTP with Retrofit 2" from Droidcon NYC. The video will follow in a few weeks.

To coincide with the talk, I have also released Retrofit 2.0.0-beta1! While it's not done, it's very usable.


Post has attachment
Recently, +Pierre-Yves Ricau and I gave tech talks at our "Streamlining Android Apps" event in Square's San Francisco office. These talks were recorded and are now available on Square Engineering's YouTube channel. Enjoy!

Eliminating Code Overhead (Jake Wharton)

The CPU, RAM, and disk are finite resources that are often taken for granted as unbounded. Not only is this obviously untrue, but the use of these resources directly affects the most important resource on a mobile device: the battery. This talk will focus on techniques that both libraries and applications can implement to ensure their effect is in general without overhead.

LeakCanary (Pierre-Yves Ricau)

In just a few few weeks, we reduced by 94% the OutOfMemoryError crashes in the Square Register Android app. We built to automatically detect memory leaks and make it very easy to fix them. This talk will cover the principles as well as the underlying implementation details. We'll dig into a few interesting examples and lessons learned.


In this video, +Colt McAnlis​​ gives a refreshingly candid take on the enum "problem". Almost everything about this video is fantastic. Almost. Watch it before reading more, because it does a great job of outlining the pros and cons of enum usage:

Ok. So what's wrong here?

In the middle of the video an absolutely ridiculous and sensational number is dropped whose sole purpose is to create a shock-statistic which leads to an incorrect perception of an enum's effect: 2556 bytes.

What app, in the entire history of apps written for Android, has ever had a dex size of 2556 bytes? Zero. Not one. Ever.

The video goes on to show that adding an enum bloats this fictitious app to a whopping 4188 bytes. Why that's basically 2x. I added a single enum and my app doubled in size!

Open Android Studio, go to File > New Project, select a minSdk of 16, select a 'Blank Activity' template, and click Finish. On a clean compile, how large is the dex file of this completely empty app? Two million, five-hundred and sixteen thousand, five-hundred and eighty-two bytes. That's 2,512,582 bytes. 1000x times larger than the "base" example used in the video.

Of course, this size stems from the default dependency of the extremely-useful AppCompat which in turn depends on the also useful fat cow support-v4. If you remove these two dependencies, what does our dex size become? The answer may surprise you: who cares? It's an empty app.

Even if this library-free app perfectly matches up to 2556 bytes as mentioned in the video then adding an enum is completely justified as it would be the only thing in the app.

Whatever random SHA of Square Cash I have sitting on my machine currently clocks in at 6.4MB of dex. How much of that is from enums? Maybe it's 0.01MB. Or maybe it's 0.001MB.

Like I said, this video presents the pros and cons of using enums accurately and does show the relative size difference which is what is important. It is a good video. But, the overall dex size comparison is needless and serves only to mislead you to believe the impact is greater than it really is which just destroys all that credibility it built.

As a library developer, I recognize these small optimizations that should be done as we want to have as little impact on the consuming app's size, memory, and performance as possible. But it's important to realize that throwing away an Iterator allocation vs. an indexed loop, using a HashMap vs. a binary-searched collection like SparseArray, and putting an enum in your public API vs. integer values where appropriate is perfectly fine. Knowing the difference to make informed decisions is what's important and the video nearly nails that except for this one stupid stat.
Wait while more posts are being loaded