- GOLD from Gustavo Lopez Mañas
- “It Takes Two”, photos by Steve McCurry.
- ‘The Hobbit’ will usher in a new technology at movie theater
- Some more from Sam Kieth
- monsieur Qui • Work in progress
- That Will Be The Day
- FACEBOOK MAKES IT OFFICIAL: YOU HAVE NO SAY
- Bungie’s Destiny detailed in leaked document, official art
- “Private Moon” by Leonid Tishkov and Boris Bendikov
- JOBS Act crowdfunding is unlikely to help most startups
- iPad Mini Comixology Comparisons
- Explore the stellar neighborhood with your browser
From 9/23/12 to 9/30/12:
By TK — September 30, 2012 at 5:32 pm
While writing a ContentProvider the other day I wondered, when I call query() on a ContentProvider, should I start specifying a projection? One of the parameters to ContentProvider.query() is an array of Strings, called the projection. Each element in the array should be the name of a column you would like to have returned by the query.
Now most times my own use of a SQLite database in an app is pretty basic. I want to persist an object that is more complex than what SharedPreferences would allow, or I need to store multiple objects. I’m really limiting the use of the database to CRUD operations. So generally when I call ContentProvider.query() the projection is null, meaning all of the columns in the database are returned. That’s what I want, but maybe there was a performance hit I was taking by not specifying a projection? And then I thought, well what if I only want a couple of the columns? I should provide a projection in that case, right?
Turns out no to the first and yes to the second. I ran queries on database tables with a column counts ranging from 5 to 16, with the number of rows in the table ranging from 100 to 5000. Compared to calling query() with a null projection, passing a projection that passes all of the columns of the table actually performs worse! On average specifying all of the table columns resulted in a query that took 16% longer. But when you want select columns, specifying those columns always results in a faster query than passing null as the projection. As the number of columns in the projection increases so does the query time.
The take away, specify your projection if you want less than all of the columns from the table you are querying. And if you want all columns pass null as the projection.
By TK — September 30, 2012 at 5:18 pm
Over at the The Corner, Square’s engineering blog, they like to post about various topics related to Android development. Yesterday there was a post about a NoSuchMethodException being thrown. The code tried to override an Activity method that wasn’t introduced until API 11 (Honeycomb). No problem, except their min sdk value was 8 (Froyo) and when the code was run on a Froyo device a NoSuchMethodException was thrown.
Normally NoSuchMethodExceptions are thrown when you try to call a method that your target sdk supports, but your min sdk does not. A good example is String.isEmpty(). This method was not introduced until API 9, so if are target is 15 but your min is 8 then your code will throw a NoSuchMethodException on a Froyo device.
A great way to catch this is to use Lint. Lint was introduced with ADT 16, and can perform a number of checks on your code to help catch issues that Eclipse might not catch when building your project (like unused resources, hard coded string values, potential issues with images across multiple densities, etc). It will also mark errors in your code where ever you reference a class or method that is above your app’s min sdk.
In the example on Square’s blog post they tried overriding onActionModeStarted() and onActionModeFinished(), two methods not introduced until API 11. If they had used lint they would have caught this error, but only because the parameter of the methods uses a class that was introduced post API 8. The fact that @Override was used on a method that was greater than the min sdk was not caught by lint. If they had tried overriding recreate(), which has no parameters, no lint markers would have been created and the NoSuchMethodException would have been thrown on a Froyo device.
The take away is that even though lint won’t catch everything, it is still a pretty good tool to help you catch potential problems before they get the chance to be reported as bugs.
By TK — August 7, 2012 at 11:42 am
By TK — February 23, 2012 at 11:05 pm
I got my hands on a Dual 1219 turntable a little while ago, and I gave a bunch of records a listen to tonight. Here’s what the turntable looks like:
The Dual 1219 was made between 1970 and 1972. I have it hooked up to some Bose computer speakers, and it sounds okay, but there is no power. The next thing to get is an amp.
Here’s what I was listening to tonight:
By TK — January 3, 2012 at 11:03 pm