It's been quiet around here for the last few months, and I can't blame a lack of exciting developments at Google.
As Tony over at Blogoscoped mentioned, the reason for my infrequent postings is now listed and available for pre-order over at Amazon:
It's still a few months away from release, but Professional Android Application Development has taken up every spare moment of time (and plenty that weren't spare) but I think the effort will be worth it.
In other Android news, the top 50 place getters in the first Adroid Developer Challenge were announced a couple of weeks back. According to an anonymous comment on this site, at least one of the semi-finalists hails from my home-town of Perth(!). Nice.
The good folk at Android Community also put up some footage of the Android presentation at Google I/O last week. It's an impressive demo that features a look at what's becoming an increasingly polished UI, shown off particularly well with the street view featuring accelerometer control.
There's also been some discussion on a likely Android Marketplace--a Google hosted catalog of 'trusted' Android applications. The concept seems like a win / win, giving developers' applications visibility while guaranteeing a level of safety for end-users. It would be particularly nice if Google Checkout was integrated for developers that choose to monetize their mobile apps.
Wednesday, June 04, 2008
Android for Professionals
by
Reto
at
13:30:00
0
comments
Labels: android, google, programming
Friday, March 14, 2008
Android v iPhone: SDK Showdown
Apple responded to Google’s Android SDK gauntlet in some style last week when they released details on the much anticipated iPhone SDK. Is it a legitimate challenger? Let’s take a look.
| Feature | Android | iPhone |
| SDK Cost | $0 | $99 (to allow distribution) |
| Distribution Cost | $0 | 30% of the list price |
| Distribution Channel | Open | iTunes exclusive |
| Mashable Maps? | Yes | No |
| Location Services? | Per Hardware | GPS Pending |
| Accelerometer? | Yes | Yes |
| Multitouch? | No | Yes |
| 3D Graphics Support | Yes | Advanced |
| Background Services | Yes | No |
| Application Interaction | Supported | Disabled |
| Native P2P Comms | GTalk | No |
| Actual Phones that Support the SDK | Q4 2008 | 4 million and counting |
Free versus Really Not Free
A 30% cut of the list price? Even my agent would blanch at demanding that sort of cut. The $100 fee is just baffling. Why charge? I’d love to have a play with the SDK but I’m not convinced it’s 10 books worth of entertaining. I’m not writing mobile apps for profit so where is the return on my investment? It’s a system designed to provide a smooth distribution channel for approved 3rd party providers but it’s going to discourage those who are simply ‘iPhone curious’.
Android’s approach charges nothing to experiment and there’s no distribution cost. If one of my experiments turns into something people will pay for I won’t have to hand back a third of the price to Mountain View or Cupertino.
Foreground versus Background
Techcruch pointed out this gem in the iPhone docs. Your iPhone applications can only run in the foreground. If you switch away for any reason it will close. In the process of creating examples for my book on Android development I found that background services are one of the most exciting features of Android, albeit not the flashiest, so it’s very disappointing to see this explicitly disallowed on the iPhone.
Foreground only apps are great if you’re writing games (clearly the big target for Apple) but 90% of the time my mobile lives on my desk or in my pocket until it rings, flashes, or vibrates.
Background services let you create applications that extend this event driven model. Maybe it’s an app that keeps track of the football and vibrates the phone when your team scores, or maybe it changes the LED color when your team's ahead or behind. Maybe you write a service that sends your location to your friends so they always know where you’re at. This is the sort of thing that’ll make my mobile more useful not just more entertaining.
Interprocess Communication
The iPhone explicitly disallows communication between processes, to the extent that each application and all its data are completely sandboxed. There’re a lot of good security reasons to do this but Android manages to handle it without the sky falling. Then again, if your application is only allowed to operate in the foreground there’s not much point trying to communicate between two apps.
Native Map Support
Since the iPhone release Google Maps has been its most popular application. In Android I can write on-phone mashups, on the iPhone I can’t.
Bottom Line?
The iPhone SDK is a way for game and mobile developers to write the same sorts of programs as they always have but on the shiniest new device on the block. That’s great if you want a 3D, accelerometer controlled version of breakout, or to play Spore on your mobile, but it doesn’t bring anything new to the party. Well, apart from an extortionate 30% licensing fee.
Three of the four iPhone apps demoed at the release were games. The iPhone looks like a great platform for mobile gaming. It’s about the size of a PSP or DS and the interface has some great possibilities. While it’s an excellent portable platform for running software the SDK restrictions make sure that no one is ever going to download an iPhone application that fundamentally changes the way they use their phone. An iPhone will always look, feel, and work the way Apple designed it.
Android lets you write applications that do more than just run on a portable device. It has the potential to create software that extends the functionality of the phone itself, to change how and why you use your mobile phone completely. More on that later.
by
Reto
at
07:18:00
1 comments
Labels: android, google, iphone, programming
Friday, January 04, 2008
Android Developer Challenge 'Open'

It's a couple of days late, but those of you with a bright idea for a mobile app and a hankering for a slice of US$10 million in angel funding should head over to the submission page for the Android Developer Challenge.
Google is accepting submissions from today until March 3 for the first of two rounds of development funding. The 50 most promising entries will get $25k and be in the running for ten $250k and ten $100k prizes.
Project submission involves uploading a compiled .apk file along with your contact details and a readme file. You can include any additional information you like in the readme -- instructions for use, design documents, or a narrative describing your vision for your application.
The entries will be judged on their (i) originality, (ii) use of the Android platform, (iii) polish and appeal, and (iv) indispensability. So the perfect project will be one of a kind that leverages all the Android specific features, looks amazing, is well polished, and once installed you'd never want to remove it.
The challenge is more 'Iron Chef' than 'Dragon's Den', so the working application you submit is definitely the most important part of your submission. They're not looking for your plan for the $25k - $275k in prize money, they want to reward what is already a polished indispensable project. A detailed 'pitch' document submitted with a dinky 'proof of concept' is probably not going to get a look in.
Be sure to check out the new Terms & Conditions, here are some highlights:
- You can submit your application using any of the SDKs released on or after 3rd Jan.
- March 3 is a hard deadline.
- You can submit updates to your project(s) at any time until March 3.
- You can submit projects as an individual, team, or business entity.
The danger of this 'show me' rather than 'tell me' approach is that it is a reward for work rather than a submission for funding. The initial winners will be the development teams that have been able to implement and polish the most functionality within the competition time frame -- most likely the developers with the least need for funding to continue their development.
There's also the question of multiple similar applications. Obviously they'll be up against it on the originality criteria, so you'll need to make sure yours is the most polished and feature rich of the entries to stand a chance.
More details on the challenge can be found on the ADC FAQ.
(For those wondering, real-life Android phones are still expected in the second half of 2008)
by
Reto
at
08:20:00
0
comments
Labels: android, developer challenge, programming
Monday, November 19, 2007
Android in Action
It's been a week since Google released their first cut of the Android SDK and despite Scoble's claims to the contrary, thousands of developers spent last week developing their first Android applications.
Where Are My Friends?
Here's what I was able to do in about 14hrs of development.

It reads the address book to find my friends, uses the Location Based Services to show how far away I am from them, and then plots everyone within 10km on a map. Philipp over at Google Blogoscoped has published my experience, leave a comment here or in the Blogoscoped forum if you've got questions -- or send me an email at Reto.Android@Radioactiveyak.com.
Today I'm a desktop and mobile developer.
As a development platform Android is phenomenal; It's powerful and it's intuitive. I week ago I was a desktop developer dabbling with online apps -- today I'm also a mobile developer. I don't say this lightly, desktop development is what I do to pay the bills.
Doesn't it make sense to launch the SDK well in advance of any actual phones?
Erstwhile video blogger Scoble is disappointment with Android. It seems this is largely because the launch "videos were boring". Robert? Dude? Who gives a shit about the videos? Developers don't want videos, they want CODE. Code, samples, and a well documented API. I still haven't watched the videos, I was too busy using the SDK to spend time looking at the pretty moving pictures. Apparently the shiny lights distracted Scoble as he screeches "[I] DO NOT TRUST THINGS THAT THEY WON’T SHOW ME WORKING". Android works. I've seen it, I've used it. They announced a software stack not hardware, and the software stack is available right now.
True, there are no phones yet, but Android is about development tools for 3rd party developers, so doesn't it make sense to launch the SDK well in advance of any actual phones? Google aren't going to out Apple the iPhone but they may just out Microsoft Windows Mobile.
You can bet that there's more than one Android project to duplicate the iPhone interface in excruciating detail.
There's been some complaints about the Android UI. It's true, the emulator isn't groundbreaking. It doesn't have to. It exists solely to provide the functionality developers need to write apps. How many projects do you think are right now in the process of reskining that bad-boy? The iPhone interface is as inevitable as this MS Messenger skin. The shipping UI is irrelevant, it's the flexibility of the SDK to create a new UI that's important.
Despite Scoble not knowing "...a single developer who has had his/her hands on Android" there are more than 4,500 members on the Android developer forums and more than 4,000 messages. Even if only 1% of them come up with a useful mobile application that's still about 30 more useful mobile applications than I've ever come across for Symbian.
The Android phone won't have the iPhone's consumer appeal. It's very true, but it's also entirely beside the point.
Read enough articles and you'd think that if Google doesn't immediately grab 30% of the mobile market at launch they Fail. That's short term thinking. Developers will write applications for Android phones because they literally can't write them for other platforms. One will get you ten that the iPhone SDK won't have nearly the level of phone access that Android provides.
Eventually people will be buying Android phones because the applications they *need* only run on Android phones. Don't believe me? Do you think people run Windows for the pleasure of it? Worst case scenario? Android forces people like Apple and Symbian to offer the same SDK access in order to keep their market. I'll take that and still call Android a net win.
Google's strategy seems to be 'make it open' -- with 'make it popular' a distant second.
People probably won't be lining up around the block on the release day for the first Android mobile but just like Google search and just like GMail, Android is going to change the way we think of mobile phones.
What made the PC so popular? Why has the web taken off? Because *anyone* with the inclination could bring their vision to life at minimal cost. If you've ever tried programming for a mobile phone you'll know it's expensive and difficult -- that's why there's so few *good* mobile phone applications, and very few for free. The Android platform is going to get thousands of developers playing around with new applications for mobiles, in the same way early IBM compatible PCs got thousands of electronics hobbyists interested in programming computers.
Eventually the availability of popular apps on Android phones is going to encourage more phone makers to release Android versions and networks to release Android phones. It costs them nothing in licensing.
People love iPhones, companies love options.
I don't run Windows because I like it, I run it because 75% of the applications I use every day only run under Windows; plus I can write powerful software for myself really easily.
Corporations will start buying Android phones for the same reason almost every company that's not a graphic design house runs Windows -- it's a more universal development environment with deeper access to the underlying hardware. I work for an investment bank, they'd never dream of writing corporate software for the iPhone; do you think the 300 Java developers here might be able create something useful with Android?
by
Reto
at
13:14:00
3
comments
Labels: android, google, google phone, programming
Thursday, September 20, 2007
Javascript API for Google Calendar
Google has just released a Javascript API for Google Calendars.
The client side library supports full authenticated read/write access the the user's calendars, letting you create calendar mashups that insert and change a user's calendar entries.
It was the Maps Javascript library that drove the explosion of Maps Mashups, so it'll be interesting to see what the development community comes up with.
Interestingly, yesterday on Joel on Software, Joel Spolsky predicted the next paradigm for development will be an online SDK that lets developers create powerful Ajax applications that can interact with each other and have consistent interface elements. A 'NewSDK',
"...which combines a great portable programming language that compiles to JavaScript, and even better, a huge Ajaxy library that includes all kinds of clever interop features. Not just cut ‘n’ paste: cool mashup features like synchronization and single-point identity management..." - Joel SpolskyWith the Google Mashup Editor and a library of full access Javascript APIs, Google may be well on the way to creating 'NewSDK'. The Google Maps API has helped make it a ubiquitous online map. Will the same thing now happen with Calendar? Then Spreadsheets, Docs, Picasaweb, GMail, ...?
Windows made it easy for developers to create applications that looked and behaved consistently and provided a level of application interop. With Javascript APIs and tools like the Google Mashup Editor and GWT may be trying to do the same thing with web development.
by
Reto
at
08:09:00
0
comments
Labels: API, calendar, google, javascript, programming
Tuesday, March 20, 2007
When Offshoring Your Development Team Means Buying a Boat
Play word association with most developers and the response to 'offshore' will most likely be a city in India. Starting my career in the oil and gas game meant offshore development has an entirely different connotation. Let me share my first experience as an offshore developer. Sure you chose the oil and gas industry, but you joined as 'the lynch pin of a new technical department'. Sick of relying on external resources for their software, you were hired to write some for them. By the time you realise their office isn't exactly in Portland, you're sitting in a 10' sea container floating in the middle of the Indian Ocean pressing a button every 108 minutes. What three things would you bring to a desert island? You're going 150km (95mi) offshore for 3-6 weeks where there's no broadcast TV, no radio, no phones, and absolutely no internet. There is a satellite phone, so if you're ready to pony up $1 / second you can reach out and touch somebody. I chose to suck it up and surprise my girlfriend on her birthday to learn that our cat was sick and her grandfather had just died. Right then. If the boat's orientation is right (and the stars are aligned) there might be a nightly email uplink when you can send / receive today's emails on a public, unsecured PC running Outlook Express. Nothing larger than 50kb and absolutely no attachments. What to bring? The following are verboten : alcohol, women, drugs, explosives. The challenge? Your total allowance is 10Kg (22lbs) which includes a hardhat and steel-capped boots. 3 pair coveralls (pre-washed and worn to avoid that n00b look), hard hat, steel tipped safety boots, sandals, underwear, socks, t-shirts, and toiletries (the latter will last longer than you expect. Don't think about why). Then the essentials: You mobilise from Karratha, a remote but booming resources town, and no-one but fellow but oil & gas workers are flying there at 6am on a Monday morning. Most smoke, and some look like they've prepared for 6 alcohol free weeks by drinking for the last 24 solid hours. Three hours on the plane, then straight for the heliport. You catch a chopper out -- with any luck this won't be opportunity to put your HUET to the test -- and so far things are pretty sweet - even if the music piped in through your headset is less 'Flight of the Valkyries' and more 'Best of Tracy Chapman'. No - that's not a fire exit. Questions? No, there is no fire exit. You're in a part of the world where there are two seasons, hot / wet and hot / dry. Today it is definitely hot, and the humidity must be 150%. Perfect beach weather, but you're changing in to full length coveralls, boots, and a hardhat ready for your vessel safety induction. Years of StarTrek means when you're told to 'report to the bridge' you have a brief Wesley Crusher moment. You're shown your muster station and which alarm means to head there -- and which one means you're better off going straight over the side. You also get assigned a room about the size of a smallish walk-in wardrobe that you'll share with 7 others, each group of 4 on opposing shifts. You learn that your Your induction moves on to the mess (where posters like this do little to quell concerns), the galley, the smoking room, and the rec room. More often than not, these are all the same room. The rec room has the TV and DVD player and houses the ship's library - filled with all the classics: Playboy, FHM, Barely Legal, People. The DVD selection is more mundane but all have foreign covers and a distinct homemade feel. Next, before anyone can even think about heading to bed comes the 24 hour living nightmare known as 'mobilisation'. Just like a LAN party, but with more water and fewer pizzas There's cables everywhere. Access to everything is awkward, and there're always three people trying to occupy the same piece of space, and work with the same piece of hardware. All this is happening on the back deck of a support vessel as it ploughs out to the field at full steam in 2m seas and 24knot winds, with green water coming over the back deck. They paid for a qualified inspection engineer. You Sir, are a disappointment. Hourly cost of support vessel and crew: $20,000. Hourly cost of ROV crew and vehicle hire: $10,000. Look on your party chief's face when you tell him the software's crashed and will take 30mins to bring everything back up so everyone can get back to work: Priceless. You're a programmer, you know this and so does your employer. But the client paid for an Inspection Engineer and expects to get what he paid for.This would be less of a problem if your employer didn't insist on you doing both jobs, or if inspection shifts were less the 12 hours long, or didn't require your full attention. Now, rather than being the cutting-edge developer on the front lines you're a barely adequate inspection engineer who seems more interested in the software he's using than the job at hand. Don't try this at home The job runs 24/7, no weekends, no downtime. You can simulate the daily offshore experience at home: At 7am the sun's up and you've done the handover to your replacement. After downing a cholesterol loaded deep-fried heart attack, you should be heading to bed. Instead you're front line support for the day-shift, fixing bugs, and implementing features. Around midday you have one last 3 course meal before wedging yourself in to bed so you don't plummet from the top bunk when the boat rolls 30degrees. You get up at 5pm and head to the mess for breakfast; a quick look at the menu and you opt for the low GI staying power of pork spare ribs and mashed potatoes with gravy. Breakfast of champions. The ROV crew is on midday to midnight shifts, so there's another full dinner put on at 11:30am and another at 12:30pm. Play your cards right and you can get 5hrs sleep a night and still squeeze in 4 full 3-course dinner meals every. Single. Day. Do I know you from somewhere...? Three weeks in you realise that this three week job is not likely to finish in the next 24 hours. You email your loved ones explaining that rather than being home by the weekend, you'll be out here for another month. Despite being around sailors for three weeks, the language in the reply makes you blush, and about then you're pretty thankful that you can't get phone calls. Time passes. At 5 weeks the homesickness has replaced seasickness. You're swearing like a sailor and you've not shaved since day three. It's been a month since you've seen your girlfriend (or any other three dimensional woman). You've watched so much porn you're genuinely surprised you've never met any of these people in real life. You've fixed everyone's notebook at least once, have challenged and defeated the entire crew in a series of all-in Quake3 Arena death matches, and the backup video server is effectively a 3.65 terabyte mp3 /porn archive. It's full so it's time to go home. Homecoming Last night everyone worked 24 hours to get the demobilisation finished, those on night shift (like you) are heading for 36 hours straight. Everyone is barely recognisable having washed, shaved, and put on their 'good' clothes for the first time in over a month. The flight back to Perth is a blur of G&Ts. For the first few days home you're walking with a swagger and when attending to nature you still lean forward and support yourself against the wall (to counter the non-existent swell). You sit back and reflect. Your bank account certainly enjoyed your trip, and you will never in your life know your code as well as you do now. Was it worth it? No. Will you be going again..? I was back offshore within a month and did almost a dozen stints over 4 years. I've worked with people who went on one job, got choppered off after 3 weeks and quit the second they hit dry land. Your mileage may vary. [Based on a much earlier submission to Everything2]
Offshore -- meaning 'out at sea'Lesson 1: The sole developer of untested, mission-critical software, should expect to be going wherever the aforementioned software goes.
Note: If it's a decent sized job they'll do your laundry nightly, so a few clothes go a long way; just remember they wash them at around 150C, so don't bring any delicates. Or nylon. Or dark colours.
porn mp3s and an empty 400Gb portable hard drive to copy items 3 and 4 from everyone else.communal death trap room adjoins the engine room and there's only one entrance / exit -- up the stairs. If the stairs are burning you have no chance to survive make your time.
You glance sidelong at your DVD case when you hear the bridge crew talking about the scourge of piracy, but relax when you realise they're talking about actual pirates... until you realise they're talking about actual pirates.
You're building Windows boxes, installing software, and fixing bugs. Then you're stringing CATV and 440V mains leads around the back deck. Telemetry from the ROV has to be fed to survey on the bridge, then back down to you in your inspection shack, so you've got the RS232 breakout box in full effect. Four live video feeds need to be recorded onto four digital video recorder PCs, a frame grabber on the online inspection PC, the bridge, and also backup VCRs. Lesson 2: Mission critical means if the software goes down, the job stops. When the job stops the company responsible starts footing the bill. Feel the burn.
by
Reto
at
07:30:00
11
comments
Labels: offshore, oil and gas, programming



