Welcome to 2012! If you're a consumer, you're likely getting ready for another year full of new products, drama, and intrigue from the tech world. If you're a journalist, you're cowering in fear of the upcoming CES trade show. And if you're a Mac or iOS developer—well, as always, you're wishing for bigger and better things out of Apple and its community.

While the iOS and Mac App Stores exploded in popularity in 2011, there's still plenty of room for improvement on the developer side. When we spoke with a number of iOS and Mac developers about their wish list for 2012, they didn't hesitate to let us know about changes they would like to see.






Read the comments on this post

iPad/Android: Want to eke out a little more value out of that tablet? Turn it into a second monitor for your PC or Mac and extend your screen real estate. This is especially handy for laptop users. More »

Google's Android 4, codenamed Ice Cream Sandwich (ICS), debuts later this month on the much-anticipated Galaxy Nexus smartphone. This major new version of Android includes a redesigned user interface that promises a uniform experience across tablet and smartphone form factors, and it delivers new features and a wide range of improvements across the core application stack.

We already gave you a look at the Galaxy Nexus earlier this month in a hands-on review of the hardware. Now it's time to take a close look at the operating system and the ICS user experience.






Read the comments on this post

From iOS and Android to BlackBerry and Windows Phone, the app store model has become the main way mobile device users find, download, and update their software. And with employees increasingly begging for access to corporate resources from smartphones and tablets, IT departments are starting to wonder whether they should jump into the app store business themselves.

"The public app store is kind of the wild, wild West," Forrester analyst Jeffrey Hammond tells Ars. Private app stores, hosted for the employees of a single business, are receiving “a lot of interest from the clients I talk to. Folks realize that self-provisioning is the long-term trend."







Read the comments on this post

If you a hear a word in regular conversation that you don't know, it can be hard to look it up if you don't know how to spell it. Instead, just throw it at Google Voice Search to get an accurate definition. More »

First of all, I should announce my editorship (starting
today)
of another blog, the
Android Developers Blog.
But at Google there are stories behind the stories.

Android Dev Blog
It’s been around since November 2007, way before I’d ever heard of Android.
In recent times it’s been used
somewhat like a press-release channel; each of the pieces heavily group-edited
into just-the-facts mode. Perfectly OK (if a bit tedious) when that’s
the kind of channel you want.

It seemed obvious to me that there was scope for a real bloggy kind of
blog, since there are a ton of interesting stories inside Android crying to be
told. So I said that a few times and I suspect irritated a few people, and
the upshot was I got the whole thing dropped into my lap.

Let me drive a stake in the ground: If you want to
know the actual technical substance of what’s being built here, or to read
inside-Android stories,
that blog is the place
to come, or rather
subscribe
to if you really care.

Blogging at Google
It’s hard, way harder than I’d realized. There’s this thing in the company
culture where everyone is very free with information, internally, and
expected to be very close-mouthed, externally. Within a few days of arriving,
my brain was bulging with more Really Big Secrets than I’d picked up in years
at Sun.

In fact, I now know how much storage we’re dedicating to support... hold
on, even mentioning what it’s being used for would probably get my ass
appropriately fired. And so on. There are a million stories around here and
a person like me who can’t not write is dying to tell them; but it’s really
hard to keep track of which ones are fair game.

To make matters worse, Google is interesting. Since I’ve come to
work here, my blog readership and Twitter follower-count have both ballooned,
and I’ve noticed that more or less anything we say, whether or not I think it
matters, is news.

Twitter follower count; I started at Google on March
15th. Statistics courtesy of
twittercounter.com.

On top of which there are many out there who are kind of scared
and nervous about Google, for a variety of reasons some of which are
perfectly reasonable. And there are those, including some who write for
large audiences, looking to pounce with glee on any whiff of evil or
hypocrisy. Fair enough, I suppose, since Google presents what we in the trade
call a Large Attack Surface.

Which means that Google in general and the Android project in particular
are careful, verging on paranoid, about what gets said in public.

Since I’ve been here, I’ve argued repeatedly that there are a lot of people
who would like to like us, and that there are lot of stories here
that would be good to tell; that the rewards of open-ness greatly exceed the
risks. There are people here, including some very important ones, who
are unconvinced. But they’re still giving this a chance. Let’s hope I’m
right.

Android: A good number of Android users dig the slide-to-type Swype keyboard, but that's now a closed beta. SlideIT is an alternative swipe-style keyboard, and if you find one-handed typing a pain, it might be right up your alley. More »

Last week I wrote
Content
Provider Iterator, which simplifies the task of dealing with Android’s
Content Providers. Reto Meier, the author of what is currently the
best
Android developer book, got
all
nervous about my approach. He’s got a point, but so do I.

If you haven’t read Reto’s piece, please hop on over there and do so; I’ll
wait till you get back.

To recap; my
providerhelper package
lets you write the following code:

Reader<Call> calls =
new Reader<Call>(Call.class, activity, CallLog.Calls.CONTENT_URI);
for (Call call : calls)
String number = call.getnumber();
I claim that this is about as idiomatic as you can possibly get, if your
idiom is Java’s flavor of object-orientation.

But On the Other Hand
Reto, and others, point out that this creates a lot of objects (one per
Call, plus one for any field you choose to store in an Object field) and does
a lot of reflection (one method.invoke() for each field you want
to extract from the Cursor, for each Call). This, they argue, will have an
unacceptable cost and flies in the face of the official recommendations on
designing
for performance in Android.

Jerome Lacoste actually wrote
some
code to measure
the performance, and it suggested that the slowdown was as much as a
factor of ten. So this is not just a theoretical problem. I guess
those people who wrote the Design-for-performance guidelines knew what they
were talking about.

Well, for some applications, anyhow. The problem is,
for others it’s not going to make a damn bit of difference.
For example, in my own app code, the delay for reading a few hundred records
out of the phone-call log, and doing a bit more work with them than Jerome
did, isn’t even measurable. (I’m working to reconcile my result with his;
something funny is going on).

At a more general level, I’d like to appeal to Knuth’s
Premature
optimization is the root of all evil. What Knuth didn’t say, as far as I
know, was the reason why his statement is true: nobody is smart enough to
predict where the performance bottlenecks will occur in any reasonably complex
application. And let’s grant that some “premature” optimization is
common practice: as in, the selection of sensible algorithms and data structures.

So, my take-away is: Yes, you have to learn the lessons Reto’s teaching and
be nervous about the things he says you should be nervous about.

Having said
that, I still believe that the right way to build an application is to do
the Simplest Thing That Could Possibly Work, and maybe it’ll be fast
enough, and if it’s not, then don’t bloody guess where the problem is, measure
it until you know.

Other Gripes
Reto and my commenters also point out that:

Getters and setters are often bad practice, and

the code isn’t thread-safe, and

developers shouldn’t have to inherit from
Builder.

Those are all fair points, particularly the one about concurrency. I will
update the package docs to include warnings about the potential performance
problems and all these other gotchas.

What Next?
I’m not sure yet. On the one hand, Reto’s arguments and Jerome’s results
are certainly sobering.
On the other, I think the problem I was addressing is real: Having read quite
a lot of Android apps source, I do think I see quite a bit of tedious ugly code
concerned with pulling fields out of cursors; the kind of thing that has
me thinking
Don’t repeat
yourself.

Having said that, I have to observe that the Google-provided apps work
pretty well and run pretty fast, and the
source code is a lot easier to read
than that of a bunch of other open-source projects I could name. So maybe I’m
straining at gnats here.

Maybe I’ll end up plastering a big Never do things like
this all over that providerhelper code. Maybe I’ll find
a way to do away with some boilerplate at a more acceptable cost.
I’m quite positive that I’ll come away a deeper and better understanding of the
Android SDK; this is by way of sharing the lessons.

Android: Need a black laptop with 4 GB of memory, but only have $600 to spend? If you've got an Android phone, Craigsnotifica can keep an eye on your local Craigslist site and notify you when your deal has come true. More »

As the iPad descends upon us, it is fair to ask, "Is this the beginning of the end, or the end of the beginning?" Depending upon whom you ask, the conclusions vary widely. The yin and yang of openness vs. integrated raises a fundamental question that underscores the battle being fought in the simmering industry battle between Apple and Google.

As the iPad descends upon us, it is fair to ask, "Is this the beginning of the end, or the end of the beginning?" Depending upon whom you ask, the conclusions widely vary.

For example, RealNetworks' Rob Glaser forcefully argues that Apple's vertically integrated model "Must be stopped." He cautions: "If that's the way the industry plays out -- and there are a couple of vertical stovepipes that are closed -- A: we will have a much slower pace of innovation than we've ever had and B: there will be a tremendous loss in terms of value creation versus it being more horizontal."

Meanwhile, science fiction writer, blogger and tech activist, Cory Doctorow, recently made waves when he asserted in Why I won't buy an iPad (and think you shouldn't, either) that, "If you can't open it, you don't own it. Screws not glue." He concluded:

The real issue isn't the capabilities of the piece of plastic you unwrap today, but the technical and social infrastructure that accompanies it. If you want to live in the creative universe where anyone with a cool idea can make it and give it to you to run on your hardware, the iPad isn't for you. If you want to live in the fair world where you get to keep (or give away) the stuff you buy, the iPad isn't for you. If you want to write code for a platform where the only thing that determines whether you're going to succeed with it is whether your audience loves it, the iPad isn't for you.

And don't even get me started on the legions who dismiss Apple's end-to-end approach with an "Apple's Evil" slap, or more stridently, paint the story as "destined" to play out as things did in the PC Wars, with arrogant Apple racing to an early lead, only to get its head handed to it in the end.

I won't spend a lot of time bringing to the fore the masses that see the Apple model in more favorable terms, as the numbers speak for themselves across just about any metric that matters:

85 million iPhones/iPod Touches/iPads sold
185,000 applications built
100,000 developer ecosystem
4 billion application downloads
15 billion iTunes media sold
JD Power Award for Customer Satisfaction
Ungodly operating margins/cash flow

So how to reconcile the animus with the market's clear directional momentum? Read on ...

Progress and grumpy old men

The late Herb Caen, the legendary columnist of the San Francisco Chronicle, once wrote a piece about the worsening state of San Francisco and, in particular, one of its main arteries, Market Street.

In it, he lamented about how this thoroughfare was always under construction, how the city's charms and enduring traditions were getting swept aside by outsiders, and how the place was becoming less and less hospitable to locals and long-timers, forcing Caen to wonder if, perhaps, San Francisco's best days were behind it.

Ah, but Caen was setting us up for an unexpected upper-cut, as at the tail end of the piece, he reveals (I am paraphrasing), "Would it surprise you to know that I wrote this piece way back in 1954?"

Caen's point was that then, as now, every generation sees their generation as the Real Generation and the Right Approach, when in truth, progress just moves forward.


Hence, the locals of San Francisco, circa 1954, saw a city losing sight of its traditions and therefore, its magic. In truth, the city was just moving forward with the times.


Thus, it was unsurprising that 30 years later, today's locals would reach the exact same conclusions about the "good old days" being their particular generational approach.

I would argue that Glaser, Doctorow and a number of others (Daring Fireball's John Gruber covers some of the other disenchanted in an excellent piece, The Kids Are All Right) are simply guilty of confusing their truth with The Truth, a not so subtle way of saying, "My Way or the Highway."

A note aside, while I have heard plenty of grumpy old men lamenting about the continuing rise of the Apple approach and its dark implications, I have yet to hear a single female prognosticator confuse such attributes with real-world unfavorable outcomes. Perhaps, it's because women don't long for the "good old days" of Stone Age tools, techno-babble, impersonal computing and the like.

Me personally, my first computer was a TRS-80, so I understand the nostalgia of being able to tinker down to schematics and assembly code, and just the same, prefer the ability to apply my muscles judiciously to higher level problems versus lower level ones.

Hence, what I give up in terms of absolute flexibility, I gain in not having to worry about hardware abstractions, infinite form-factors, middleware, glue code, software distribution, marketplace and monetization.

To me, that is a more than acceptable trade-off, inasmuch as you would be hard-pressed to argue that the model is less democratic or even less web friendly (while Apple is clearly trying to create the best native experience possible, they have unquestionably also created the best mobile web experience and are key proponents of HTML5 and pioneered WebKit adoption).

Nonetheless, the yin and yang of openness vs. integrated raises a fundamental question that underscores the battle being fought in the simmering industry battle between Apple and Google.

Do we really need more inmates?

There are two bookends that gave me a grammar and narrative for thinking about software (and hardware) development and design. The first is "The Mythical Man-Month" by Fred Brooks, and the second is "The Inmates are Running the Asylum" by Alan Cooper.

In "Inmates," Cooper makes the argument that too often the development process is driven by techies building the types of products that they would like to use, as opposed to really understanding the aspirations and outcome goals of their target user, let alone who that target user even is.

Worse, they often compensate for this blind spot by building products that address all use cases, including edge cases, and build a design interaction model that is a composite of that blob of functionality.

The end-result are products that are confusing, needlessly complex and that address all theoretical problems from a check box perspective, but few real problems from a specific outcome perspective.

Keep this in mind next time you are comparing the Apple product that seems to be "missing" certain features relative to the cheaper alternative on the other shelf. Nothing is free when it comes to product design decisions.

Margins, and who keeps which piece of what dollar

It's worth revisiting Rob Glaser's earlier comment about "stopping Apple," as it underscores the real reason many want to stop Apple.

Back in the days of the PC, the rise of Microsoft and Intel led to a horizontally organized industry. Microsoft and Intel kept the highest margin dollars for themselves, and could expand into adjacent segments as they saw fit. They also left a number of chunks of the hardware, software and infrastructure stack to third parties.

This type of loose-coupling worked because the PC was essentially a homogeneous platform, and the expectations of user experience were such that daily system crashes, recurrent performance lags and numbingly-complex "enterprise" software was considered the rule, and not the exception.

Now, of course, the two industry standard-bearers of the Post-PC Era, Apple and Google, respectively, have addressed the challenges of old very differently. Google, by embracing simpler, loosely coupled (read: horizontally-focused) cloud-facing solutions, and Apple, by embracing vertically-integrated, complete product solutions that marry hardware, software, service, developer and marketplace.

But make no bones about it; the real tempest here is who keeps the high margin dollars.

In the case of Google, they are happy to allow any and all to plug into their search and advertising gravy train, so long as they can disrupt any and all incumbent segments ripe to be broken up by their model.

In the case of Apple, they see user experience and control of same as central to their value proposition and "govern" accordingly.

Whether you see one as more open, closed, virtuous or evil depends upon your personal preference about user experience and choice, not to mention your particular economic self-interest.


But that is a post for another time.

Related:

Innovation, Inevitability and Why R&D is So Hard
The Chess Masters: Apple v. Google
Open "ish": The meaning of open, according to Google
Android vs. iPhone: Why Openness May Not Be Best
iPad First Impressions: The Good, the Not So Good and the Not Yet

The fact that this isn’t posted on
developer.android.com is a bug,
I’d say. If you’re going to
be doing any Android programming, you really need to get Reto Meier’s
Professional Android 2 Application Development.
Yeah, he works for Google (same group as me) so I’m prejudiced. Whatever. For
the moment, Reto’s book is the Bible.

I want to be able to write apps for my phone in in something other than the
Java language; for example Ruby or Python.
This isn’t one of the things my group at Google has asked me to look at, but I
think it’s worth doing and worth some of my time.
I’m writing this today because I’m amused by the contrast with the current
hubbub over Apple having
tightened
the developer thumbscrews.

Why?
I like
the libraries, but I have to confess
that these days, I’ve slipped into the camp of those who find the Java
language verbose and rigid and overly ceremonious. It bothers me less on
Android than on general-purpose computers, because Android apps tend to have a
pretty thin layer of application code between calls out to the network and GPS
and accelerometer and so on.

But having said that, I’m pretty sure that in, for example, Ruby, I could
write less than half the number of lines of code to get any particular job
done. Also, I entirely loathe
Java generics.

What Google Thinks
As usual, I’m not speaking officially for Google here, but my impression is
that if there were an official reaction, it’d be along the lines of “Uh,
whatever, we’re focused on shipping this next release.” Which is likely
appropriate; The Androiders are so zoned-in on building a great SDK and runtime
and Market that my wild-eyed screw-the-semicolon ideas are not exactly likely
to become front-of-mind. Well, unless I can show that they work.

It may come as a surprise to regular readers here, but there are vast
expanses of our profession, including some of the best and brightest, who
haven’t got the dynlang bug yet.

And the Official Policy?
That’s a non-issue. An Android app has to be an
APK file, and if
you generate/sign one of those and are in the developer program, and it’s not
illegal or porn or something, you can drop it into the Android Market.
(If falls afoul of Market rules, you can post it on your own website or some
other market, and people can still install it, no jailbreaking required.)
How you build the APK is up to you.

In practical terms, if you want it to look-and-feel like an Android app,
you have to use the
Android
SDK; but what language you generate those bytecodes and method calls with,
and how you compile it, well, why should anyone care? I’m using Eclipse,
and while it Just Works with the library and emulators and other tools, it’s
failed to win my heart.
I’m seriously thinking of going to
Emacs and seeing if I could replace Ant with Rake. And, of course,
every piece of the toolchain is open-source and thus in
principle can be forked and improved and replaced.

If what you produce sucks, the word will get around quick; having used the
official Android toolchain won’t save you. And if it doesn’t suck, not having
used it won’t get in the way.

I’m actually a little puzzled by the Apple policy; the technical side I
mean, not the business issues, which Gruber
explains
with ruthless clarity. I can see Apple wanting to enforce the use of their
APIs, but the compulsory linkage to the Objective C programming
language makes me feel like I’m missing something; where is it carved in
stone that it provides the optimal, impossible-to-improve, way to use the
iPhone APIs? And if nobody’s allowed to try anything else, how will we find out?

Anyhow, the market will decide; the big small-m market, not the iPhone nor
Android Markets. But in the meantime, I’d say we’ve got more scope for fun
over here on the Android side.

Candidates
Right at the moment the Rubyists seem to be in the lead in this race, what
with
Ruboto and
Duby.
I can’t think of any architectural reasons why Jython shouldn’t be a
candidate, except for Sun let
Frank Wierzbicki go and I’m not
sure anyone’s working on it much, these days.

Also, in theory you ought to be able to use the
Android NDK to
get the native C versions of Ruby and/or Python going. It’d be a slog, but
the idea doesn’t seem insane.

There are lots of other languages, and maybe one of them is a better bet;
My focus on Python and Ruby reflects my own prejudices, but my
mind is open. And of course JavaScript is already a first-class
citizen pretty well everywhere.

In Conclusion
Got any good ideas for how to let me write serious, shippable Android code
without ever having to do this again?
HashMap<String, List<Person>> buf = new HashMap<String, List<Person>>();

If you do, get in touch. I might be able to help you help me.

Creating camera-phone-friendly QR codes with a goo.gl shortlink URL tweak is nice, but one of our readers took the next logical step. His bookmarklets creates a goo.gl link, automatically converts it to a QR code, and shows you the result. More »

Windows and Mac: Miro Video Converter quickly and easily converts video on-the-fly for popular devices, with presets for your PSP, Android phone, or Apple device. More »