Happy Ada Lovelace Day!

Posted by banane on October 16th, 2012 — in feminism, technology


I’m sitting here at work kinda slammed and sick, but hey, it’s ALD, and that’s kinda cool.

At work, we were talking about Ada Lovelace – interesting because we are in fashion, and her first application was making jacquard. I love that fact.

In thinking about Ada with this coworker, I realized that she is an important lesson in what one can do with childcare, money, and education. She heard about someone making a machine, thought about how she’d apply the technology, and wrote him a long letter with instructions… before it was even built. She had the leisure and time and energy to pursue science and math.

So next time you’re judging an industry on its lack of women, don’t say “because they don’t have interest/ability/”they don’t have minds like that”” think instead of how the world would look, and be, very different if everyone had equal access to good math and science education, childcare if they chose to have children, and time to study and pursue free projects, if they could afford it.

Why non-native mobile frameworks suck

Posted by banane on September 18th, 2012 — in android dev, iphone dev, ruby on rails, technology

Hm. Opinionated a little?

A couple of times, folks ask me: do you know X? And I say, why, no I don’t. I do know the language that X avoids. X is: Objective-C, Java, etc. the list goes on. Tonight at a study group, a friend who had just learned Objective-C agreed with me (I had told her- “… just learn it, it’s not that hard”) that “It’s not that hard.” See??!! OK maybe an anecdote isn’t enough to prove my point.

So you want an iPhone/Android app. You’re worried that:
– You will invest a lot of code into one operating system
– You will alienate the other users- iPhone or Android (OK, face it, usually Android)
– The native language is hard

None of those are good reasons. Why?

1: Think investing in Android/iOS is faulty? Think of investing a lot of time and effort in a framework that, while fancy and fun today, will go out of favor in (count them) 4 months approximately. Rarely do these last that long, for various architectural reasons. It’s a total b***ch keeping up with two different platforms (iOS/Android) that are constantly evolving- think of this from the framework’s perspective. At least Google & Apple have a lot of developers building out their SDKs. Most hybrid/cross-platform frameworks have a few open source fans, or a crew of 5-20 developers in a start-up/funded environment with various levels of skill.

2. Different businesses and apps have different target markets. Figure out what devices your users have, how they use them, whether they use native drivers (camera, voice, etc.), and build a simple, native or web app for them. And then roll out a comparable one (or even diminished in features) for the smaller represented set. Or, build in the most popular native operating system for your target demographic, and create a web version to encompass the others. Or, what I like to do, wait for people to complain. If enough do, there’s your market, develop for that.

3. Native languages are not hard. They are quirky (iOS) or very evolved (Java) but they are not hard. Learning JavaScript and then adapting it to the iPhone (PhoneGap) is hard. Learning Ruby and Rails and then rejiggering it to run as an Xcode app is hard – with little or no documentation (RubyMotion). And, well, there are a literally vasts amount of people developing native and they’re writing about it, and helping you, and available for hire.

My most conservative, time-saving, and risk-adverse advice is to build out testing. And rarely do new frameworks that straddle both native systems have good testing frameworks. That’s a pretty strong reason in itself.

Demo Gods Were Not With Us… #iosDevCamp

Posted by banane on July 23rd, 2012 — in iphone dev, technology

My hackfest-programming-partner Stacie Hibino and I submitted ChickenDance to the 2012 iOSDevCamp Hackfest. We were in the first batch called up to demo, and had various network issues that resulted in the much competed for prize: “Best App with Demo Fail.” I had been holding out for a “Had Most Fun Making App” award, but had to lower my hopes when our names were called.

It’s the third “win” for us at the iOSDevCamps. We won “Best New Developer” for DicePad (throw a dice from iPhone to iPad), then “Best Social Game” for “SocialPong” (play Pong with X number of people, consoles are your phone in HTML5).

I’m still suffering from the blow of the Demo Gods. Our app takes a voice input “song” and mashes it up randomly with a 7-second dance video. You can also input video “dance” and that will mash it up with 7-second long songs that were recorded earlier. So, oddly the video worked later in the hallway. We got this fun mash-up of the audience doing a wave to my song “YMCA”:


Of course, it’s a sign of loving inclusion to get the award. The worst would be – being ignored – no prize, or having it fail just generally. The fact that the app works, and that we had a lot of fun playing it earlier, is testament to something, right??

Future mods will be: using a database (instead of Amazon S3 exclusively- was a delay in scanning directories) and using Facebook network, as right now it might devolve into a Chat Roulette problems.

The tradition with the dev camp is to mod the giant skeleton head booby prize. for the next poor soul. Stacie has some fun secret ideas. We put an Angry Bird in the eye socket as a hint to what may come. I’m thinking some kind of vicinity detection that emits smoke from its eyes.

One of the camp founders, Christopher Allen, tweeted:

@banane @staciehibino it is not a booby prize, but a celebration of effort! Freedom to fail is important! #iosdevcamp bit.ly/Miezqp

Very true, very true. Still, it’s hard when your super cute app flails. I do usually learn from failures, from this one, the lessons were: don’t change your wifi settings right before the demo, and, test the exact sequence of the demo BEFORE the demo.

Mayer & the Glass Cliff

Posted by banane on July 16th, 2012 — in feminism, technology

The New York Times just announced: Marissa Mayer took the position as Yahoo’s CEO a few minutes ago. She has broken through the glass ceiling at Google only to encounter the “glass cliff”:

via Wikipedia/Univ. of Exeter:

A glass cliff is a term coined by Prof Michelle Ryan and Prof Alex Haslam of University of Exeter, United Kingdom, in 2004.

Their research demonstrates that once women break through the glass ceiling and take on positions of leadership they often have experiences that are different from those of their male counterparts. More specifically, women are more likely to occupy positions that are precarious and thus have a higher risk of failure – either because they are appointed to lead organizational units that are in crisis or because they are not given the resources and support needed for success.

The telltale signs that make this a classic glass cliff situation are:
1. It’s a position of leadership
2. The company is in crisis
3. Average or under-skilled for role

She’s inexperienced at being a CEO, and the company is in huge crisis. The former CEO’s (with lots of experience) have bailed and/or been chucked out (see: Carol Bartz). She’s also quite young. Her background is in engineering, not management. Unlike Campbell’s woman-CEO, who is very experienced, trained for the position, and the company was not in (this level of) crisis when she took over. Or, Jobs swooping into Apple when it was in the shitter. Hm. WWSJD?

Why is Yahoo in crisis?

Here are Yahoo!’s latest headlines:
450,000 Yahoo users hacked
Yahoo calls off patent battle with Facebook
Yahoo CEO resigns after resume scandal
Yahoo! founder leaves, paving way for possible sale
… and so on.

Uh, OK.

Here’s a metaphor: I see Yahoo as a tall-masted ship in the era of WW2 battleships. They lost the search wars, and have been unable to innovate at the same speed as their competitors. Now, they’ve hired a top artillery midshipman. But the ship still has cannons. See what I’m saying? She’s managed a ton of people, true, and been at a really great organization- Google- but now she’s at Yahoo!, floundering on a model built on ad revenue, a failed inbox, and corrupted data. Compare corporate acquisition strategies: “… Google products originated as services provided by companies that Google has since acquired” (Wikipedia on Google Acquisitions), whereas Yahoo has “acquired and killed” startups (Gizmodo).

Best of luck, Marissa (gulp). If she figures this shit out, I have 2X the respect for her, than I already do, and that’s quite a lot.

(photo credit: Horrible Tianmenshan glass cliff in Zhangjiajie, Hunan)

Important Failures

Posted by banane on July 12th, 2012 — in technology


I really like attending conference talks on how people screwed up. Not just to laugh at their mistakes, but to learn from them. It’s important to fail, and so many people are afraid of admitting it, for various reasons. Thing is, if they failed at something awesome– a new gaming console, a cure for cancer, a self-cleaning apartment robot, learning Tlingit– you end up respecting them. If it’s a stupid mistake, yeah, that’s not that interesting.

1. What did you fail *at*. Was it a worthwhile, ambitious, interesting, valuable goal? Did you expect a certain outcome and get another? Was it unexpected? Was it worth the doing?

2. Interesting people fail a lot. For example: Abraham Lincoln, had quite a rocky life and career. Do I want to sit next to the skyrocket-to-the-top success, or the one who endured struggle and challenge after challenge? It’s not just that I’m a blind lover of the underdog, but find it more interesting when someone can speak intelligently as to how they got where they are.

3. From that last point, why is someone who has failed a lot more interesting? It’s the magic of:

an important/ambitious/boundary-risking task + an attempt (sucess or failure) = interesting lesson

Easy success? Not a lot learned. Safe success? Also rather boring. “We kept selling the gizmos that were already selling well!” Not as good a story, nor as useful, as, “We tried digital cameras but they were too expensive (our users said). Next time, we’re making them from cheaper parts/less features, and lower price.” A lot more interesting.

Work Isn’t Play

This is true, and one of my pet-peeve buzzwords in this industry is “play.” I had a teacher who called coding “play” and while I know what she means, it’s largely not “play” to write test scripts. Writing “f**k you” over and over again recursively on your screen (as I saw a teen do in a Ruby class) is, though, play. And funny. She didn’t innovate, but let her doodle around some more for a few days/months, and who knows.

What we get from playing, though, (reference: Jane McGonigal’s talk on gaming) is that, obviously, we’re goofing around. We’re having fun. We’re experimenting, being creative, testing boundaries, all great ingredients for innovation. Still, we need safe parameters, lack of repurcussions, etc. Interesting that when we were kids playing on the playground, I personally remember falling *a lot*. But I didn’t think “I should never play again on the jungle gym again,” I simply went out there the next day, with bruises fresh and callouses, and climbed up a different way, or held on longer, or something.

Failing Safely

Similar to anything, you can fail a bit more safely: fall better, cushion the blow, fail fast. Talking to a client the other day, I was like “you can fail long and painful and expensively, or fail fast.” Not that failure was imminent, but he was worried about whether the idea would be good, proofed in the market, etc. I’m a fan of course, as we all are, of failing fast. It’s a bit of an oxymoron, failing safely, because if you were attempting something safe, it’s not a very interesting failure. How you can “cushion the blow,” though:

– put metrics on everything
– lock down a time frame (fail fast)
– make sure the only variables are the ones you are testing (no new talent, no new features, etc.)

Testing? For iPhone? Mooooo….*

Posted by banane on July 10th, 2012 — in iphone dev, technology

I wrote a blog post about Cedar way back in the day. Now, Xcode ships with OCUnit.

I’ll go through a basic way of adding tests to an existing project, as that’s a very common task, and not very well documented thus far. Props to the following blog posts- I’m consolidating their advice basically in a single one, with screenshots.

Why do tests? Well, it’s a great way to work. If this is new to you and you’re more interested, check out tons of resources referring to Test Driven Development (TDD). Of course, if you read this from a Google search, you already know what that means.

1. Add New Target

1. In Xcode 4 (.3.3, for me), add a Target. Took me forever to find this. It’s the “+” circle at the bottom of the Project pane:

2. Set to Cocoa Touch Unit Testing Bundle

2. Change Target Build Phases & Settings

Click “Build Phases”, expand “Target Dependencies” and add your App.

Click “Build Settings”, and add:
Under “Links”, “bundle Loader”, “build/Debug-iphoneos/[yourapp].app/[yourapp]

Under “Unit Testing”, “test host” put in “$(BUNDLE_LOADER)” (will populate with bundle loader).
3. Change App’s Bundle Settings

Set “Symbols Hidden by Default” to “NO” – frankly, this is usually already set to No.

4. Test to Run!

So let’s run this, even though the sample test sends a failure. Still, it’s good to see that in action right off.

Now, if you’ve installed this into an already made project, you will select the target in the “manage scheme” area, then select Product/Test from the menu.

One distinction- if you’ve started a project with OCUnit “baked in”, then you don’t have to select the scheme/target in the upper left, simply use Product/Test from the menu.

5. Check Out Those Errors

Unlike the lovely test frameworks in rails, and some other languages, OCUnit prints out boring black and white console log errors: so have your console up and running when you Product/Test. Here’s some live test results!

* Testing your Bay Area cred… this title is from the ad that ran 50s… 90s in the SF Bay Area for Berkeley Farms, that had a very catchy tagline: “Farms? In Berkeley? Moooo…” Several radio spots can be heard on their site now, and you can check out some old photos of this neat Berkeley dairy.

The Imposter Syndrome and Knowing What You Don’t Know

Posted by banane on July 3rd, 2012 — in feminism, technology

I really have never thought I had Imposter Syndrome. I’m not a shrinking violet, I tend to talk pretty authoritatively, I’m confident, like to speak in public, etc. Yet, I joined a mailing list for women-techs and during discussions this term came up. I looked it up, and started locating this behavior in a few of my interactions.

Imposter Syndrome is the feeling of inauthenticity, that you will be “found out,” that you don’t belong, and roughly that everyone has reached some basic level of knowledge or performance, that you haven’t.

Your accomplishments are due to:

  • luck
  • timing
  • or as a result of deceiving others

I only got that award/Hackfest win because of tokenism, or because our competition wasn’t that great. Or, they thought it did something it patently didn’t (good/fake demo?). Not only do I think these things occasionally, but, others tell me this. I’m not kidding. Right after presenting Ruckus at AngelHack this guy accused our demo of not working, of being faked. To our faces. Most presenters didn’t even have a demo, and very few had one that worked.

For me, the imposter syndrome rears its ugly head during technical interviews. No matter if I’m a subject expert, no matter if I don’t know the backgrounds of the guys (and they are always guys) interviewing me, I will give them more authority than they’re worth, and think they know things I don’t know, and doubt or diminish my own accomplishments.

Afterwards, when reviewing the transcript in my mind, I am amazed at my lack of confidence and surity, and, generally, how I give them more than the benefit of the doubt. My solution to this- work more and more on doing LinkedIn checks before the interview, or, ha, ask what material’s going to be in it so I’m prepared. Also, as women (or people,) we’re taught not to be braggy, but we have to be able to state our accomplishments clearly.

I also tend to over-estimate the knowledge and experience of speakers at conferences. Recently volunteered to be on a panel simply because I wanted to attend and I was wait-listed. It was on contracting in iOS. Turned out I was on the upper-median spectrum of experience on the panel. Why did I assume that they were qualified to speak with authority? Because they were men? I didn’t know the facilitator, and yet assumed he knew his stuff. So in a way the Imposter Syndrome feeds off itself, as more people undervalue themselves, they are also overvaluing those around them.

We all know that an accurate understanding of your own knowledge is what helps you grow and learn. It’s actually quite rewarding when I find out a pocket of knowledge that I don’t have, and I’m eager to get better at it. I am actually, as I write this, embarrassed to admit my latest learning. I recently tackled and won a battle with threaded programming, in Android and iOS, that has me eager to redevelop all of my old titles. I should write about it, but, having had bombed a (cough) technical interview about threading in Rails, I am shy of mentioning that it’s hard, and that I’ve figured it out, and it has really improved my apps. I’ve also done some serious image and sound encoding and now want to add voice and image creation to all of my old games. I got shot down on StackOverflow by some guy about a sound encoding issue, so guess what, I’m shy about writing about that triumph.

Anyway, it’s a journey, but having an honest assessment of your own skills is vital to learning, so in a way it’s inhibiting our abilty to publicly admit: I didn’t know this, and now I do, and I can now share it with others.

I wonder if this is the key element to why the percentage of women on StackOverflow is so low.

My Latest Development Mantras

Posted by banane on July 1st, 2012 — in android dev, facebook, iphone dev, ruby on rails, technology


Maybe, perhaps because I’m an English major, I tend to notice patterns in my speech. So, I noticed recently that I keep saying the same phrases in discussions regarding mobile app development:

– secret sauce
– no login
– no back button
– mentoring
– phase 2
– did the customer want that
– don’t say user
– is it needlessly complex

These discussions came up in hackfests, in client work, and in advising on technical projects. What the repetition of these phrases means to me, is that I need to reinforce certain concepts. So we all like Lean Startups and Customer Development, but are we essentially practicing those behaviors in our day to day work? The fact that I have to repeat them means that they’re having a hard time sinking in. You can know something, but to do it is another thing entirely.

Secret sauce

What this app actually contributes, essentially, that is different in the market. The copyrightable/trademarkable essence. The actual chemical recipe for turning water into wine, for example. It’s the core concept that you’re testing, and everything else is a distraction, and muddies the customer testing. You need to narrow down the experience to highlight this secretsauce.

No login

It’s very hard to start a project and not begin at the login process. But, you know what? Logins are assuming that people are going to come back. It’s not actually a pre-requisite for an app. You can grab session information, conduct a Facebook login later down the line, heck, just leverage Facebook entirely for login, etc. There are other options. Is it part of the secretsauce? Largely, it’s not.

No back button

I really hate them. It assumes that it’s important to store the customer’s “state” at all time, and it assumes that it’s core to the app idea or secretsauce. Back buttons are key to making a bloated big application with lots of overhead programming. This was a revolution in thought to me, to exclude them, and now that I’ve gotten over it, I’m not going back! I’ve met really horrified faces when I say this, but it’s true. Integrating a back button means sometimes 3x fold more work, so only include it if it’s part of the “secretsauce.” Usually, users can go through a flow and come back to home. No back button.

Mentoring

First introduced by none other than the wonderful Shaherose Charania of Women2.0, I admit it took me a while to get on the same page, and now I’m totally embracing it. This concept is awesome. Basically it’s a license to mentor, coach, or delegate the work to someone else. You hire a mobile developer, but you can also, (gasp) hire a developer to MENTOR you in mobile development, and then you can (gasp!) do the stuff yourself. You know, teach a man to fish, etc. It’s key to find someone who has good teaching skills, knows their stuff, and has time and interest (it’s non-competitive) to teach you.

Phase 2

During development, you will think of new things, and they will be great ideas. And you should keep a list of those ideas. And you should not involve them in the current phase. You should say no. Say no to the new idea. Keep focused, deliver the secretsauce.

Did the customer want that?

During development, you will think of new things. They will be awesome things. But you know what? You’re not the target demographic. I think the hardest part of Customer Development is not making an app that is precious and owned and used entirely by you, but spread out in the world and owned and used by others. So you have to constantly validate new ideas by the customer base (when you get them). We’re too close to the project and our opinions and use cases aren’t really worth much, essentially.

Don’t say user

From Sarah Allen, who said in a talk, “why call them users… are they drug addicts?” that cracked me up. Stylistically it’s outdated to call your customer a user. We are not all at terminals with our keyboard inputs. We’re at the playground watching our kid, checking Facebook, or in a club taking photos of old college friends, etc. Getting an idea of your customer and thinking of them that way is a big fat step towards making relevant, good apps. Recently at a hackfest my only feedback on a powerpoint pitch for an art festival presentation was – “call them festival goers” because it’s going to show that we “get it” to the judges. It shows you’re connected to the customer and not a bot. This is an old concept in Customer Relationship Management, but still is so maligned and not used, it’s sad. Basically, getting used to saying “festival goer” is 1/2 way to actually getting to know, and develop cool stuff, for your customer. Imagine going into a Disney pitch and saying, “user” instead of “parent” or “delighted kid” (who will become a parent, of delighted kids, etc.).

Is it needlessly complex?

A great thread on a geeky point probably worth an entirely new blog post, this thread brings up some key points- essentially the original poster wrote an abstracted class against the wishes of his client, and he was terminated.

I don’t consider myself a great programmer- my strengths are not in impressing other geeks, but impressing my clients and making great apps. One mantra that helps me “get it done”: I don’t make a routine, method or subclass unless it’s merited by repeat use. Essentially, don’t go all abstraction unless you need to. I can overprogram shit on my off hours. OK sorry to get all scatological, but certain architectural decisions are smart, some are … needlessly complex. For example, offloading logic onto the server, because you’re going to do two mobile versions, and you are using the iPhone simply as an interface controller: good idea. Building out a datamodel and data feed for a series of buttons that could be static in the first version: needlessly complex ( and, assuming that the options will change without customer input… “phase 2” and “did the customer want that”).

Do you have mantras? Would love to hear, if you do.

There Are No Women On StackOverflow… Or Are There?

Posted by banane on June 20th, 2012 — in feminism, social networks, technology

For a long time, years in fact, I used the site as a reference. You have an error message, and you can search for it, and find a lovely discussion of fixes, problems, etc. I had joined a year ago, but got some grief and didn’t login in again for a year.I’d run into a very difficult bug and posted it (Facebook deep linking on Android emulator). A guy answered in 4 minutes and helped me troubleshoot- there was no clear answer, but I was grateful for a sane head and new set of eyes. Full of good karma, I decided to give back. I made some classic newbie missteps before I got my footing. Of course, I ran into some douchebag opinionated guys, (“you don’t know what you’re talking about.”) but still pushed through, until there I was, up late one night, in a chat session with some high school student writing their first iPhone app. It was karma, and also wanting the +10 associated with being the correct answer.

As I got into the various features, I started exploring the user profiles. That’s when I realized that I’d only come across one visible woman’s profile, among the hundreds, or thousands of profiles I’d seen up until then. I posted an innocent question to a women’s engineering list:

Lately most of my annoying-male-behavior stuff comes from StackOverflow, which led me to think, are my lady programmers on there?

I’m enjoying the “roulette” style questions, going to “unanswered” and seeing if I know anything. And also trying to give back as it’s saved me a few times in the last week.

Anyway, I’m me on there, if you’re on there it’d be nice to know your username.

I was hoping to see maybe one or two – or to just see if they got nasty responses to their questions like I did. What happened is an 11-day discussion, 57 emails, from women about how largely they disliked the site, lurked, or joined and left.

So there’s good news, there are women on StackOverflow. The visible ones are far below the representative % of women in the industry.* So you can safely determine that it’s an unfriendly-to-women place. Many “men” are women. Some women have two profiles, one that they use to ask what they consider dumb questions, one where they answer questions.

Here’s a list of comments from our 57-thread discussion about why women aren’t on StackOverflow:
– The blatant one-upmanship of the site turns them off
– There’s nothing they can contribute (seriously, many women feel that way)
– They don’t want the grief of getting downvoted (because they are a woman) * (more on this later)
– Like me, just didn’t consider contributing
– They use neuter or male profiles
– One or two women were early users and got turned off by the online behavior of the sexism and discrimination they endure in real life.

We are now discussing creating a hosted, private question and answer site similar to SO. I honestly don’t think that’s a good idea for improving the visibility of women in tech. As one mailing list programmer wrote to me, “It’s a battle some of us just don’t want to fight.”

My Short History on Stack Overflow
Milestone #1: My first post- an answer (kinda ballsy!) Notice: no upvotes. Still, proud of it, and the content was solid.

Milestone #2: My first accepted answer! On the site, the question author selects the correct answer. I was chosen of 3!

Milestone #3: Answering (and being selected as the answer) in a language you don’t consider yourself all that great at. Oh, and people are grateful?!?!

Tips To Having Fun On StackOverflow
I largely use SO as a place to gain confidence, and a good prep for interviews. I also use it to procrastinate. I am a geek, so I like to browse it much like a bookstore, looking up issues or languages that have crossed my path recently. Mainly, of course, I use it to find answers to questions.

If you want to participate in the community, and not lurk, there are some tips to having fun:
– Post code. Your answers will be up-voted, and selected, if you do the effort of actually writing a sample few lines of code, or finding old code and popping it in. Most developers don’t read non-code formatted text, it’s true.
– Be polite, but don’t grovel, apologize, use disclaimers, or caveats. Simple, and direct.
– Don’t chat – use the chat tool if it gets to be a back-and-forth discussion.
– Comments are comments, answers are answers. That was my newbie problem, getting them mixed up; putting comments in the Answers box and vice-versa.
– Use tags – in searching, in finding questions to answer, in writing your question. It makes site more usable and faster. It took me a few days to find the use for it, and it is very useful.
– Don’t rise to the bait, avoid attention-seekers, etc. There are douches here, just avoid them. Let the moderators do the policing.

* Check out this Fiery discussion on “meta” StackOverflow regarding just this issue of women lurking, but not joining, StackOverflow, has quite a few references to QuantCast, a demographic analysis engine. One comment (that I didn’t verify its veracity) says 26% of degrees in CS are awarded to women. The QuantCast statistic reported in the thread is that 20% of those viewing the site are women (how it can determine this, I don’t know), with the author experientially saying “no women were in the active/leader board” for StackOverflow.

* Downvoting without reason: this is a pernicious behavior on StackOverflow that occurs to men, as well. Basically site users with a certain site-age can up or down vote answers, comments, questions, etc. The etiquette is to add a reason, if you downvote. Women perceive, that it happens more to them than men. We can only really verify it with the site statistics, or perhaps a sociological experiment of some kind? I’ve experienced downvoting, but it’s hard for me to tell if it’s from my age-level on the site (I think that has a serious impact) or my gender. Or, of course, it’s a bad answer (never!).

Playing Back Wav in 2.2 Androids

Posted by banane on June 7th, 2012 — in android dev

It’s tough, and I just got it to work. See zipped code here.

The key was writing the streamed URL code to a local disk space (always same file). Despite the purported support, Android 2.2.1 does not support WAV streaming. That is, you can’t play it directly from a URL.

Basically wrote our own “setDataSource” to buffer the data locally before playback. Then, another key is to wait until MediaPlayer has “prepared”, this is done on a Listener method. Only do “start()” once it’s “onPrepared”.

This demo API code was invaluable for breaking down the process flow and troubleshooting. I borrowed the setDataSource method from Davadum Srinivas – great stuff. Also, so nicely formatted and written!

I had determined WAV to be the right format to record and playback on iPhone and Android, and it all tested well, on my device which is 2.2.3. Sadly, my colleague’s (and 2 of his roommates!) devices are 2.2.1 and that broke the easy playback.

Here’s the code, if you like to scan before downloading (like I do)

package com.banane.chicken;

import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
import java.net.URLConnection;

import android.app.Activity;
import android.media.AudioManager;
import android.media.MediaPlayer;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.webkit.URLUtil;

public class ChickenActivity extends Activity implements MediaPlayer.OnPreparedListener {

        private MediaPlayer mMediaPlayer;
       
        private static final String TAG = "ch aPlayer";

       
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }
   
    public void playMedia(View v){
        try{
             Log.d(TAG,"brawk");
             String tmpPath = "http://s3.amazonaws.com/lyricsgame/ly_100001882208569_mountain.wav";
             mMediaPlayer = new MediaPlayer();
             mMediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC);
             mMediaPlayer.setOnPreparedListener(this);

            // this is where we do local buffering and writing
             setDataSource(tmpPath);
             Log.d(TAG,"done setting ready to prepare:");

             mMediaPlayer.prepare();
            // good test to see if properly prepared
             Log.v(TAG, "Duration:  ===>" + mMediaPlayer.getDuration());

        } catch (Exception e){
                 Log.e(TAG, "error: " + e.getMessage(), e);
                 if (mMediaPlayer != null) {
                     mMediaPlayer.stop();
                     mMediaPlayer.release();
                 }

        }
    }
   
    public void onPrepared(MediaPlayer mediaplayer) {
        // start here, and only here
        Log.d(TAG, "onPrepared called");
        mediaplayer.start();
    }

    public void stopMedia(View v){
        if(mMediaPlayer.isPlaying()){
                mMediaPlayer.stop();
                mMediaPlayer.release();
        }
    }
   
    private void setDataSource(String path) throws IOException {
          if (!URLUtil.isNetworkUrl(path)) {
                    mMediaPlayer.setDataSource(path);
                } else {
                    URL url = new URL(path);
                    URLConnection cn = url.openConnection();
                    cn.connect();
                    InputStream stream = cn.getInputStream();
                    if (stream == null)
                        throw new RuntimeException("stream is null");
                    File temp = File.createTempFile("mediaplayertmp", "dat");
                    String tempPath = temp.getAbsolutePath();
                    FileOutputStream out = new FileOutputStream(temp);
                    byte buf[] = new byte[128];
                    do {
                        int numread = stream.read(buf);
                        if (numread <= 0)
                            break;
                        out.write(buf, 0, numread);
                    } while (true);
                        mMediaPlayer.setDataSource(tempPath);
                    try {
                        stream.close();
                    }

                    catch (IOException ex) {
                        Log.e(TAG, "error: " + ex.getMessage(), ex);
                    }
                }
            }
   

}