.png)
When was the last time you burned a DVD so you could watch a video on your TV? Or set up a laptop on the living room carpet, cables strewn about, so you could watch a video on the big screen? That's all becoming old hat, thanks to apps like AllCast.
The ease with which we can stream media from one device to another has rapidly increased in recent years, as low-cost devices like the Chromecast or Roku become common sights in media cabinets. AllCast, created by Android developer Koushik Dutta, arose as a simple solution to "cast" media from Android devices to Chromecasts, and evolved for wider implementation.
A dozen or so year ago, I remember carefully encoding MPEG videos so that I could play them on my hacked Dreamcast; perhaps it wasn't worth the trouble, but there was a magical quality in seeing my videos on the television when there was no simple way to connect a PC to a TV. That simple satisfaction of utilizing the big screen is now easier than ever, of course, and I don't think my Dreamcast is much of a threat to the devices compatible with AllCast. We caught up with Koushik to learn a little about how and why he decided to create AllCast, and what he has planned for the future.
Where did the idea for the app come from? Were you trying to solve a problem you'd experienced, or did the inspiration come from somewhere else?
The idea had been floating around for a while; there was no obvious counterpart to AirPlay on Android. When the Chromecast was released, and they provided an SDK, it became a real possibility. Chromecast was the first device to make major inroads into the Android user ecosystem.
After you came up with the idea, what was the next step?
When Chromecast team decided to close some undocumented APIs that would allow developers to get around the beta API lockdown, I started investigating other solutions. This was in mid 2013, and smart TVs, which supported DLNA casting, were starting to become much more common place. I discovered that Xboxes also supported DLNA. At the same time, Roku also introduced their own casting solution. I realized there was an opportunity to make an all-in-one casting solution: Users don't care about what is hooked up to the TV, they just want their media on their TV. How it works is just a detail.
How did you choose which platforms to target and which to ignore or wait on?
I chose Android and Chromecast as my primary mobile/cast platforms. Android is where my existing userbase was, and Chromecast was selling by the millions. When Chromecast was initially slow to release a finalized API for indie developers is when I branched out to other targets. I didn't choose to ignore iOS, so much as make sure that I delivered a solid experience—I've never done any iOS development. The iOS crowd is a bit more discerning. There's a good chance I would have botched it if I did it myself, so I brought Jackson Harper on board to build that out.
It took a while for Chromecast to actually play friendly with indie developers. Do you think they just didn't anticipate the enthusiasm with which people wanted to make their own software and felt safer maintaining a walled garden?
I think a bit of both. From my chats with them, they were definitely caught off guard by the runaway success of the device. But I also think there were some business types within Google that wanted to keep the toys to themselves.
What was your biggest roadblock and how did you overcome it?
The toughest part to this day is learning how to deal with a user's home network. Odd router configurations can prevent discovery. Poor Wi-Fi hardware can prevent casting HD video from a phone—and phones have incredible cameras nowadays. HD video is 20Mbps on Android. Many Wi-Fi networks, depending on congestion with other networks, and many other factors, are only capable of 3-4Mbps. And there's an insane amount of folks that just use the cruddy Wi-Fi router that is provided to them by their ISP like Comcast, etc.
What was launch like for you?
Android launch was crazy. Leading up to the launch, I did a "casual" beta, that ended up having 30,000+ testers. Any time I did a prototype/beta/release, it seemed like every major tech site would cover it. The tech sites also seemed to love the story around when the Chromecast team hit the kill switch ending usage of the undocumented APIs.
How do you handle user requests and criticisms effectively?
I actually stopped reading reviews and emails. It's not healthy, hah. The comic that The Oatmeal did on "Making Things" has a panel that sums it up:
I've brought Ray Walters, a long time friend of mine, to manage support type issues like this.
Now, how do you split time between developing new features and managing existing ones?
Ray distills the bug reports and feature requests into usable feedback, and lets me know if a lot of users are complaining about a specific pain point. I don't have a process per se. I'd say maybe 25% of the time is spent on bugs, and 75% on features.
Besides simply adding support for more devices, what do you want to see in the broader future for AllCast?
I've got two different ideas for directions floating around my head, but I'm not ready to discuss them yet. One is in the prototype stage, the other is a much larger endeavour involving hardware (no it's not an AllCast stick).
What advice would you give to others that want to take on a similar project?
I've said this before elsewhere: There are plenty of opportunities to make a six-figure salary by attacking projects that would typically not be worth the time of a small engineering team. One person with a broad skill set can tackle it economically.
Every other Wednesday, Behind the App gives an inside look at how some of our favorite apps came to be—from idea to launch (and beyond). Have someone you'd like to see featured? Email Andy.
Illustration by The Oatmeal.
from Lifehacker http://ift.tt/1LEJcDL
0 comments:
Post a Comment