13 notes

Attention internet: that’s not how Android multitasking works

Hey everybody, please stop confusing John Gruber and his legion of flying monkeys with strangely wrong statements about multitasking in Android.

On Android, apps are suspended when they are no longer visible to the user. Suspended means the app is still in memory, but it is frozen. No processing or event handling happens.

— David Quintana

LIES. Or, more likely, IGNORANCE. Whichever it is, there is no redeeming this objectively wrong statement. I don’t know who this guy is or how much Android programming he has done. Neither did PCWorld but they still wanted to marry his “clearly, straightforwardly, simply written” bundle of bad guesses on computer phone stuff, proudly not “mired in the technical details” such as whether or not its fundamental assumptions were correct.

ANYway. That was months ago. It seemed like this nonsense would be corrected at some point by people that knew what they were talking about. But then today:

When a user switches apps, or hits the home button, your app has a brief time when it “runs in the background.” Then it becomes suspended. In its suspended state, it is still in memory, but gets no CPU cycles.

—Michael Galpin

WHAT. No. But this guy actually does Android programming. What is he talking about? [You can find Michael’s response in the comments below.] Was Coderspiel itself mistaken? Let’s test it!

  scala.actors.Actor.actor {
    while (true) {
      Thread.sleep(5000)
      println("hello")
    }
  }

See for yourself: the world is wrong and Coderspiel is right, like usual. You just have to copy and paste that scrap of code somewhere into your Scala Android app (IF YOU HAVE ONE LAZY PANTS) and see what happens when you leave the application.

Here is what happens, for the lazies: the thread keeps printing crap forever. The app containing it can not be described as “suspended” or enjoying a “brief time”, in any universe. At some point the app may be terminated, if you open a bunch of porn from Steve Jobs’s famous Android porn store. But on our test device it ran for like an hour before we got tired and stopped it.

Crazy, right? It took just a couple of lines of code to disprove this misconception flowing through the torrent of “this thing is somewhat like that Apple thing, please RT” pieces. (Those are boring btw. At this point the only reason to read them is to drink a beer each time they type something completely wrong about Android.) How has this confusion spread so far? Surely most Android programmers know how their platform works. Perhaps they are just so admirably used to packaging long running processes in services, and recognizing that background apps may be terminated at any time, that they think of background apps as being suspended. It’s just that, crucially, they aren’t. It’s the application’s responsibility to be idle if it is not doing anything of value.

As for users and their precious experiences, this distinction is actually really interesting. It means you can do this thing where you’re reading RSS feeds in NewsRob and there’s a link you want to follow, so you “open in browser”, and then you switch back to NewsRob while it’s loading. Later, you go to the browser and the page has loaded. If you’ve used a computer since 1995, you’ve probably experienced this feature already, which is called “multitasking”. You don’t have to do anything special to make it work.

Of course, Mobile Safari is made by you-know-who, so it already multitasks swimmingly in the current iPhone OS. It will keep on loading pages while you are playing Doodle Jump. But poor iPhone Opera is crippled with amnesia: not only do loading pages fail to finish when you leave the app, they’re forgotten entirely. In iOS 4 they will pause or something, but Opera can’t just load them like normal because it is not Pandora or a jogging route recorder.

Or who knows, maybe Opera will be allowed to multitask because as a browser it’s already “duplicated functionality” and the ever-changing, non-binding platform rules are nothing but a complex piece of misdirection.

[Android] [Mobile] [Multitasking] [Cocoa Touch] [Originals]

2 billionth Cocoa Touch developer sold out

Sadly, he learned nothing from the experience:

There is no alternative platform, despite what others may say about Android, it’s immature and their app store(s) are a wild west nightmare. It really is Apple’s way or the highway, and that really stinks.

Often in history the powerful have confounded the weak with a false dilemma: that the alternative to absolute power is chaos. Just give Mr. X ultimate authority and he’ll use it to improve your little life. But dictators once empowered never seem to rule as benevolently as their admirers expect. They’re self-interested and cruel. They are terribly human.

Even and especially the most devoted followers of a personality cult find themselves among its collateral damage. Ruined, some take refuge in their faith—a belief in the ruler’s divine appointment or perhaps his dedication to the mystery known lately as user experience. Others snap out of this spell by invoking an older one: WYSIWYG.

We’re lucky, at least in computing, to still have choices.

[Apple] [Cocoa Touch] [Software Freedom] [Originals]

Upcoming Scala Meetups, on Earth

If you don’t see a map here, click through to the post!

No pins near you? Add one.

[Google Maps] [Javascript] [Meetup API] [Meetups] [Scala] [Originals]



12 notes

On Praise of Closed Platforms

The greatest damage of Cocoa Touch’s exclusive-distributor policy is not its effects on individual users, programmers, or software companies. It’s how it has corrupted our decades-long discussion on computing platforms.

Our computing culture encompasses many different views on software freedom and access, but over time its trajectory has curved towards greater openness. Even proprietary systems have benefited from incorporating open-source into their foundations, Mac OS X being the most famous example. Open-source projects have in turn been improved by salaried contributions from some of their beneficiaries. And most importantly, these symbiotic relationships have bubbled up to platform interoperability: I don’t have to worry if my Mac ssh client will work with a server on Linux when they’re built off the same codebase, and this confidence creates a stable platform for higher level platforms like git.

Things were looking swell for a liberating and innovative future in software. That is, until a formerly counter-cultural computer company in Cupertino decided to disruptively innovate in extreme software market control. Dude. What? If you had told me in 1998 that it would be intellectually fashionable in 2010 to support a reversal of computing’s trend towards openness because of Apple Computer, I would have spewed Zima all over my Performa.

But here we are, with Apple Employee #66 Bruce Tognazzini:

The blogs have been filled for three years now with the constant wailing of the technorati complaining bitterly about the iPhone’s, now the iPad’s, closed system.

The blogs! They complain bitterly and wail constantly—this is a popular thing to type! Let’s never mind that this “free webzine” article is itself a blog post: it’s text that would not have been written or read if not for web publishing, which is blogs. They’re a good thing.

Until blogs we weren’t often able to learn about technology from people who made it happen, the great inventors and designers of our times. I really appreciate being able to read what people like Tog have to say. The web has opened the floodgates of mass publishing and it’s making our civilization collectively smarter. :) Even so, our species remains tragically susceptible to the ancient vice of ad hominem fueled by hubris. :(

… the iPhone’s, now the iPad’s, closed system.

It’s nothing new.

Yeah, that’s not actually true.

[The first Mac] was designed to always have a fixed amount of memory—128k—with no way of ever expanding it. The core of the OS was in ROM, not RAM. It was Steve’s vision that if you made every single computer with the same exact OS and the same amount of memory, developers would always have a fixed platform for which to develop, making their jobs easier.

No hardware expansion, okay.

Users could forget about plugging in add-ons, too, because there wasn’t anywhere to plug them. The system could not even connect to anything as basic as a hard disk, for example, again “supporting” developers by giving them a single, known quantity for which to develop.

Also, no hardware expansion.

Sound familiar?

Notsomuch.

In hardware terms Apple’s Macintosh started off less open—expandable is the natural term—than the PC and Apple II platforms. And when Mac add-ons were enabled their adapters were of course proprietary. The much later adoption of PCI and USB standards were the significant cross-platform measures in this vein, taken in desperate times by the formerly go-it-alone platform.

But to pretend the original Mac, current Macs, or any Mac in between is evidence of the value of “closed platforms” in the context of Cocoa Touch is foolish of people who don’t know better, and dishonest of the rest. Our new platform debate is specifically and significantly about software distribution, and in that respect the Mac has never set itself apart.

In fact the original Mac proved that a culture of excellent software can thrive without centralized software distribution. You could even unfairly point out that the plain old Mac software market had a lower share of junk than the fancy authoritarian App Store, but that’s of course because the cost of distributing software back then helped keep the rabble out. Apparently the accidental capitalist solution worked better than Apple’s army of bureaucrats—that is, if you think the availability of crappy software is a real big problem in the first place.

Slippery Hopes

As much as the Cocoa Touch situation sucks, don’t despair that computing in general will slide that direction. For one thing, the platform will be overtaken by its unimpeded competition. That’s what happens. But as for those who do support Cocoa Touch’s legal and technological meshwork because they support closed platforms as a general rule (wtf), they are not so much sliding down a slope towards software disempowerment as taking a swan dive into it. If such restrictions are necessary to progress, what exciting next step are they anticipating after ceding exclusive control over software to a single corporate entity? Tasers? [Update: almost!]

A timeline for iPad competition was evident even before it was announced. By January 2010 Google had already, remarkably, caught up with Cocoa Touch’s lead in mobile touchscreen computing. While Android 2.0 predictably fell short in its user interaction, it got close enough for its killer feature of mobile multitasking to strike fear into the hearts of the Cocoa Touch gods. If the ability to switch between blocked and responsive activities is worth more to you than a few dropped animation frames, Android was already in the lead. (And webOS probably even more so, but sadly without the marketplace clout.)

So when the iPad made its inevitable appearance, the significant revelation that day was not the initial version’s lack of a camera (which is just mean) but its lack of anything technologically surprising, at all. It seemed to come without any advancements, an observation that reliably attracted two retorts: “it’s not about the tech features, stupid” and “it’s a post-computer device, stupid”. Both of these condescending fireball talking points avoid the intended point admirably.

Which is, that without gap-widening tech the iPad was set to be challenged within months, and even surpassed by Android devices. It does not take so long to produce hardware that is like current devices, but bigger and bigger. And as for the software platform, Android was born ready for the move to larger devices capable of richer computing. They had prudently built device-independent pixels and multitasking into it from the start. It seems Google does not typically let Tog’s “young geniuses” run wild without those annoying design constraints.

“Start your xeroxes” would have been a little awkward

To close his free webzine article Tog characterizes the fated arrival of larger Android hardware as “Google” using its “copier”. That is just weird. These devices have been on drawing boards since the computer screen was first imagined, especially in the offices of computer and touchscreen phone manufacturers. The difference now is that the market has been primed and several viable platforms are ready to go.

Whatever you think about Android’s past borrowings from Cocoa Touch, there is not that much new stuff to copy. Neat-o pop-up menus were in Android 2.1’s gallery app before the world was inexplicably impressed by them on the iPad. Mostly Apple seems to have spent their iPad prep-time setting a good interface example with their office software. That’s a fine idea and I’m sure I’d be impressed if I used office software, but its inspiration will help people design better big-Android apps as much as it helps Cocoa Touch apps. Yay for unwanted openness.

Now if I were inclined to return the copier jeer I could call Cocoa Touch’s long awaited interpretation of “multitasking” a carbon copy of Android’s.

But, that would be a pretty ignorant appraisal.

[Android] [Apple] [Cocoa Touch] [Mobile] [Originals]

To be continued…

import scala.util.continuations._

size(500, 200)
frameRate(15)

var cur: Unit => Unit = { (u: Unit) =>
  reset {
    var x = 0
    while(true) {
      x = (x + 1) % width
      background(255)
      color(0)
      line(width - x, 0, x, height)
      shift { k: (Unit => Unit) =>
        cur = k
      }
    }
  }
}

def draw() {
  cur()
}

… at Delimited Libations, Stimulated Saturdays, and Scala Days.

[Originals] [Scala] [Continuations] [FP]



1 note

Curried and Confused

The best post on the internet got some sweet linkage again this week. You know, the one where Scala is too complex because you can express the sum of a list of numbers like so:

def sum(nums: List[Int]) = (0 /: nums) { _ + _ }

In the intervening years since that expression prompted a ‘verdict’ that Scala was too difficult for us regular folks, a lot of us have written a heck of a lot of Scala. We had to make implicit.ly just to keep up with the flow of Scala software that people are publishing these days. The pump is primed and the machinery has finally come to life. It’s an exciting time! For some.

But since it’s come up, let’s review that old /: scarecrow. What makes him so perplexing to newcomers? Some have blamed the use of non-letters in the name. Okay then, how much clearer would Joe BeanFactory find this definition?

def sum(nums: List[Int]) = (nums foldLeft 0) { _ + _ }

Not much really! Well, maybe the problem is the infix notation?

def sum(nums: List[Int]) = nums.foldLeft(0) { _ + _ }

Yeah, I don’t know. By this point our rhetorical corporate programmer has gone out for coffee. Perhaps he will be back later to decide which programming languages we’re all supposed to use for his convenience. Maybe he would rather express things like 1 + 1 as 1.plus(1) —or, maybe he just doesn’t give a Dilbert about orthogonality.

But seriously guys, I don’t think it’s the infix notation or the permitting of symbolic characters in syntactic symbols that make applications of /: difficult to grok at first. It’s the blessed currying. Setting off the first function application with parentheses prevents one’s uninitiated mind from cheaply translating it to a familiar series of parameters. Instead you have to recognize that the first function application returns a second function, which is applied to another set of parameters. It’s trippy.

Truth be told, this perplexed me at the time. But instead of rejecting the language for supporting functional constructs beyond my experience, I decided to keep learning—and I’m happy with how that has worked out. So it’s interesting that two years later, this particular functional freak-out has been ‘cited’ to brand Scala as overly complex (Perl-y) while a second thread of spite bemoans Scala’s insufficient promotion of currying.

It’s simple, you see. The currying in Scala makes innocent enterprise developers cry in their frappuccinos, while similar encounters in OCaml inspire a rapturous session of functional mind-blowing.

Well. At least you can learn Scala at your desk.

[Functional Programming] [Scala] [Useful Idiots] [Originals]



1 note

iNanny cracks whip

Right after Apple made us ridicule their sorry quest for a mobile “bring-up” loser, Phil Schiller has gone and blabbed a bunch of 1984 crap to the Times, which he foreshadowed back in November. It’s awesome.

See, just over the last few weeks the world has gotten really Naughty. Schiller himself has blushed at

an increasing number of apps containing very objectionable content.

Oh my! Let’s just hope Schiller was not forced to evaluate each and every one, in private. Apparently this is a Unique Crisis:

It came to the point where we were getting customer complaints from women who found the content getting too degrading and objectionable, as well as parents who were upset with what their kids were able to see.

Now hold on a sec, Mr. Schiller. Women have been known to disagree with each other on many things, including what is too degrading (?) or objection-able. It’s a little iffy to completely ban products based on what you say the women say. And those parents, maybe you should tell them about the famous “parental controls” you now build into everything?

We obviously care about developers, but in the end have to put the needs of the kids and parents first.

Much like it has always been necessary to ban racy items from bookshelves, computers, and the internet because some anonymous prude in the employ of a private business was offended/aroused.

But what about Sports Illustrated’s beloved mainstream pr0n—which (some) women have been objecting to for ages—is there some kind of special, or double, standard in place to protect our big old-media brands?

The difference is this is a well-known company with previously published material available broadly in a well-accepted format.

Well that’s a relief. S.I. is just appropriately degrading to women.

On the other hand if you want a software platform that isn’t run like a bought-off nursery, there are alternatives.

[Apple] [Twerps] [iNanny] [iPhone] [pr0n] [Originals]

God hires assistant

The job posting from the Cupertino, CA, company specifically calls for an engineering manager to handle “platform bring-up.” In the job description, Apple states that it’s looking for a manager “to lead a team focused on bring-up of iPhone OS on new platforms.” It seems like Apple wants some outside talent with very strong technical experience, especially when it comes to bringing software onto multiple hardware devices.

Whatever a “bring-up” is, this job posting is weird because Apple is supposed to have the next decade specked out already, if not in product testing. We (consumers) learn about the future of computing at Apple events, when they decide to tell us. Our 2015 portable computers will be descendants of Apple’s “iPad” invention, like those copy-cat props in Avatar and Minority Report.

But this job posting would imply that Apple is in a competitive marketplace where other companies have ideas, too. That open mobile platforms may be on the verge of a cambrian explosion of unexpected, unplanned, useful devices that will be difficult to fight off with a platform that is locked down in both hardware (old news!) and software (evil news!). That the world hasn’t been standing still in the two years that the iPhone has … grown. (Not that there’s anything wrong with that.)

[Apple] [Mobile] [iPhone] [Originals]



1 note

Mobile multitasking for dummies

At our last New York Scala Enthusiasts Meetup I presented on Android. I started the talk with a series of 1980s magazine ads that extolled Apple personal computers as world-changing tools for creative expression and invention. Android is a platform for hand-held computers in this proud tradition.

adams-apple

We’re looking for the most original use of an Apple since Adam.

After that ironic stroll down memory lane and after I presented [Snapup] a simple photo-snapping application I wrote to post Meetup photos, we had one of those conversations that are, ultimately, the reason we gather in public. I hadn’t gone there to talk about multitasking and didn’t have anything prepared for the subject. I didn’t hide the fact thatI knew little about the greater Android platform; I had only learned enough of its API to make my app workie.

But I had shown a number of internal background image-loading threads being created as Scala actors, and someone who did know the Android platform wanted to know if those were still chewing through valuable mobile cycles. So we opened the Dalvik Debug Monitor—-my first time!—-and quickly discovered (in front of forty people) that my app was stealing some cycles when it should have been idle, and actors were part of the theft.

Was this the greatest actors crime since the Lincoln assassination? Well no. I should have been telling the actors to exit after they were done. I wasn’t even really using actors, just somewhat idiomatically using an actor for a simple background thread (mentioned in the last post, actually). I assumed that the zombie activity there was negligible, but, in the Android model there is no such thing. Any wasteful polling picks the battery’s pocket all day long.

So after the Meetup I pushed ahead my plans to implement non-blocking interfaces in Dispatch using java.util.concurrent as a foundation. Once Snapup was refactored to use this higher level HTTP interface, ddms showed no activity at all from my background threads. But, there was still a significant amount of CPU burn when the app should have been idle. What was it?

It was a stupid indeterminate progress dialog animating itself off-screen. See, Android replaces the desktop concept of windows with a new concept of activities, better suited to small (or large?) touchscreen interfaces. Snapup has one activity that does nothing but OAuth token exchange, and the only face it shows to the user is a Please wait… dialog. Once it has the tokens it starts the another activity but it doesn’t stop itself. Neither, apparently, does its animation.

After stopping that nonsense, Snapup’s idle activity went down to zero where it belonged. Whether on-screen or off the process is voluntarily cryogenically frozen, the same as if the operating system had forced it to pause. Problem solved!

Yo mama

But oh my god, doesn’t this mean that your ‘mom’ or ‘wife’ is going to have a hard time using an Android contraption because of bad apps like version 0.1 of mine? First of all, That’s sexist. Secondly, No. This story means the Android human-interface to multitasking needs work.

Sure, I’m a dummy for not profiling the application before releasing it. I like making things and it worked so I jumped the gun. And there’s a lot of dummies in the world. One option is to cut us off from users and require bureaucratic approval of all software binaries before anyone can run them. Another option is to solve the problem, with design.

The old desktop software model puts users in charge of starting and quitting applications. A bit of sloppy processor use was expected, and generally harmless. When computers began to run on batteries, the task fell on users to be vigilant. Road warriors that depended on battery life learned to quit any app that they didn’t immediately need.

In the new model that’s been adopted by all successful mobile platforms, you don’t quit applications: you leave them. On platforms that support multitasking this shifts responsibility to application programmers: they are the ones that need to be vigilant. If they do their part things work great: Android’s technical implementation of multitasking is excellent. It’s up to applications to be good, or bad.

The design problem is that users (and casual programmers) aren’t exposed to this new dimension of bad. Normally you can judge software just by using it. The user interface is good, bad, or ugly. The app is fast or slow, it crashes or it doesn’t. But for battery waste the feedback loop is broken.

Android tries to address the problem with a kind of shit-list for applications. It’s is offered up when your battery runs low: Dang, who’s been using up my battery? The shortcomings of this measure are obvious. For one thing, batteries are meant to run out. Reaching the end of a cycle is not a sign that any app has been misbehaving. To find any bad apps you have to mentally subtract your historical use of each one listed. And who wants to start that investigation with an uncertain few minutes of battery life remaining?

Battery waste information, which all users now require to judge applications, is just not adequately exposed in Android.

All Activities on Deck

Where does application activity information belong? The place you go to switch running apps, at the very least. And as it happens, that place is a dump in Android right now anyway, an alt-tab popup lifted from Windows 95. In this problem domain the Palm Pre’s card metaphor is so far the only effort worthy of the touchscreen medium. There’s plenty to be inspired by there, so much as the lawyers will allow it.

Because Android doesn’t have an activity switcher worth talking about anyway, it can kill two birds with one interface and bake battery usage deep into whatever does emerge. It should be as obvious which applications are using the battery as it is which ones are running at all. This is critical information to anyone using the platform. Especially your ‘mom’ needs to know which applications are wasteful!

The Android people at Google, they’re no fools. The current lame task switcher is a sign, if anything, that there is a big fat real-task-switcher branch that their work is going into. It needs to land soon. This is the year that people are picking up and trying Android. They need to be able to say, “hey, I’m not using that app right now and it’s using my battery for no good reason.” DELETE. Otherwise, their experience will be bad.

The difference between this and the old model is simple: you don’t quit applications that might be wasting resources, you remove applications that you know are. You aren’t managing tasks, you’re firing applications. It raises the awareness of programmers making the apps too, and the incentives to write a well behaved app. By filling that information gap, we can finally reach a level of abstraction that many of us have been anticipating for decades: applications that are just there. Your trusty software is always available, right where you left it and doing only what you told it to do.

Apple thinks they can guide us into that future with an army of bureaucrats, who are surely enrolled in profiler training courses at this moment. It’s surprising how long that is taking, actually; it has made their cherished new product unveiling the butt of resonant jokes. And when they finally start to white-list ‘background’ apps it will at least be one helpful purpose of their degrading software approval exercise. But even so, a platform that enlists informed masses to collectively rank software will run circles around one administered by, well, your dad.

Just ask the first company that tried to fight off Google with an army of classifiers.

[Android] [Meetup] [Multitasking] [Scala] [Originals]

}