I’ve been looking for a good solution to serializing object/data streams from mobile environments to services. Object serialization doesn’t really work well here since these mobile environments all have different flavors of Java… some run Android, and others JavaME. On Android, object serialization between the DVM and a JavaSE VM works with lots of caveats, so that’s not really usable.

I came across Google’s Protocol Buffer API recently. Protocol Buffers are similar to XML schemas, that you can compile from a language neutral schema definition into code (in different languages like Java, C++, and Python). However, there’s no XML involved here, it’s a lightweight binary encoding/decoding mechanism. You create your schema definitions in a .proto file and you compile that into Java code that you include with your applications (services, and mobile apps). Google extensively uses this technology internally, throughout their apps, services, and infrastructure, so it’s vetted, and well supported.

You can get started using this technology with Java by reading this tutorial.

Here’s some interesting history that prompted Google to create this technology:

Protocol buffers were initially developed at Google to deal with an index server request/response protocol. Prior to protocol buffers, there was a format for requests and responses that used hand marshalling/unmarshalling of requests and responses, and that supported a number of versions of the protocol. This resulted in some very ugly code, like:

 if (version == 3) {
   ...
 } else if (version > 4) {
   if (version == 5) {
     ...
   }
   ...
 }

Explicitly formatted protocols also complicated the rollout of new protocol versions, because developers had to make sure that all servers between the originator of the request and the actual server handling the request understood the new protocol before they could flip a switch to start using the new protocol.

Protocol buffers were designed to solve many of these problems:

• New fields could be easily introduced, and intermediate servers that didn’t need to inspect the data could simply parse it and pass through the data without needing to know about all the fields.
• Formats were more self-describing, and could be dealt with from a variety of languages (C++, Java, etc.)

However, users still needed to hand-write their own parsing code.

As the system evolved, it acquired a number of other features and uses:

• Automatically-generated serialization and deserialization code avoided the need for hand parsing.
• In addition to being used for short-lived RPC (Remote Procedure Call) requests, people started to use protocol buffers as a handy self-describing format for storing data persistently (for example, in Bigtable).
• Server RPC interfaces started to be declared as part of protocol files, with the protocol compiler generating stub classes that users could override with actual implementations of the server’s interface.

Protocol buffers are now Google’s lingua franca for data – at time of writing, there are 48,162 different message types defined in the Google code tree across 12,183 .proto files. They’re used both in RPC systems and for persistent storage of data in a variety of storage systems.

I came across this nice blog post on why not to use cheap development outsourcing companies. The gist is you get what you pay for. There’s a cost associated with everything… there is no free lunch. Experienced and talented resources don’t come cheap.

Google has announced that it will invest $10M into a startups working on a new kind of geothermal energy - called Enhanced Geothermal Systems, something that MIT is backing. EGS makes it’s own steam by drilling into the earth’s surface and pumping water into the cracks that are formed to make steam… this steam is then used to run generators to make electricity.

1. Chevy Volt - This cool new electric car has a naturally aspirated engine that simply recharges the batteries onboard, that drive it’s electric motor! It has a small 1.4L 4 cylinder engine that recharges onboard batteries. When the battery reaches 35% charge, the gasoline motor kicks in to recharge the batteries. Due out in showrooms in 2010, if GM doesn’t go out of business by then .
2. Disappearing Car Doors - A company in California called JATECH has created a new kind of car door. You have to see it to believe it. Unlike suicide doors or scissor doors, this door disappears into the bottom of a vehicle when opened. Very cool.
   
3. 2009 Porsche 911 engines getting a workout - This a really cool video of the 2009 911 Carrera and Carrera S engines getting tested to make sure the new dry sump system works. The new dry sump system now has a variable-flow pressure pump that needed to be tested extensively at the ‘Ring, but the new system can perform the same task whenever engineers want, and at a fraction of the cost.
   

Sadly, the tools that were supposed to allow you to easily create Nimbus based Look and Feels is not going to be ready in time. JDK6 Update 10/N should be released soon, with the new Nimbus Look and Feel. If you can’t wait for the LnF creation tools and want to get a head start, this is a nice tutorial by Jasper Potts (Nimbus’ author) to get you going: Skinning a Slider with Nimbus.

Here is more information on Nimbus itself:

1. JavaOne 2008 Nimbus Talk - ps_ts-6096-nimbus.
2. JavaOne 2008 Nimbus BOB Presentation - nimbus-bof.

Enjoy!

When you think of a car, you think of something that has a solid body (steel, aluminum, carbon fiber, fiber glass, etc). BMW questioned that very basic assumption, and has created something really different - a car that doesn’t have a ’solid’ skin! They make the argument that tubular space frame cars (like many race cars) don’t really need a metal skin… so they applied that to a road car . But with a big twist - they use a fabric skin. And this fabric is wrapped over a structure that can change! My words do no justice to the GINA Light Visionary Model:

I’ve been drooling over the Voodoo Envy 133 for a while now. And while it’s a very sexy and stylish laptop, the long delays in getting them shipped (and produced) has caused me to look elsewhere. Their ship dates keep getting delayed - last I read it was Aug 20th before the first Envy ships (they were originally slated to start shipping a month ago).

Sony Z Series

Sony is making a 13″ widescreen laptop that’s supposed to have lots of performance, while being portable, and durable. The specs are quite impressive for the Sony Z Series:

1. CPU up to 2.5GHz Core 2 Duo
2. 13.1″ LED backlit display with a whopping 1600 x 900 display! That’s a lot of pixels for a small 13″ display!
3. You can get 64GB SSD, or even have 2 of them striped (RAID) to get 128GB! That’s impressive, and expensive!
4. Hybrid video, so that you can switch between integrated (GMA 4500HD) or discrete (GeForce 9300 GS) graphics cards. All without rebooting, just like the Alienware 15″ laptop. Integrated for battery life, and discrete for performance, your choice.
5. Carbon fiber lid (not the entire chassis and body like the Envy 133).
6. Weighs only 3.4 lbs!
7. You can even engrave it… the engraving shows up inside the laptop lid, above the top/left edge of the LCD panel. You get 2 lines of text that you can engrave, at no cost.
8. Only knock against it is that these laptops are not very “serviceable“. It’s not so easy to replace components on these laptops… they are very MacBook-Pro-like in their obtuse internal design…  Thinkpads do it much better, and so do the badass HP Elitebooks.

So, on paper, this is one hell of a laptop! With the 64GB SSD, you’re looking at around $3000 for this laptop. However, you can go higher and lower, depending on your configuration. While this laptop and it’s specs are astounding, I was worried about build quality and the pixel density of the screen. I visited a SonyStyle store, near where I live, and couldn’t find a Z series. But I did find just about every other kind of Sony laptop, along with the SZ models - that have carbon fiber lids. To my dismay, I was disappointed at how flimsy just about every single Sony laptop felt - their build quality left a lot to be desired. The displays are gorgeous, and the keyboards are awesome, and the touchpads are great. But, all the laptops felt flimsy, there was too much flex in the lids, and in the chassis itself. Having been spoiled by Thinkpads, they felt flimsy and prone to damage from daily use, much less travel. Of course, I could be wrong, and the Z Series will be quite sturdy, but I won’t know until they have them at the SonyStyle store… Will update this blog post when I’ve seen one in real life.

HP “Badass” Elitebooks

So after seeing how flimsy the Sony laptops are in real life, I was looking for something more rugged… when I ran across the new line of HP Elitebooks that are hitting the shelves any day now! The Elitebook line of laptops, which includes 12″, 12″ tablet, 14″, 15″, and 17″ models, are all ruggedized to meet the MIL-STD 810F military standard for vibration, dust, humidity, altitude, and high temperature. Here are some highlights:

1. All the laptops have a magnesium alloy chassis, with brushed aluminum lid, which has a scratch resistant finish.
2. All the laptops have a built in web cam that can take a picture of business cards, and OCR them and load them into Outlook
3. They come with QuickLook2 software from HP, that basically allows you to boot into a non-Vista OS and check your email, contacts, and calendar in Outlook. Here’s a look at the older QuickLook software, which has been updated for the EliteBook… it not longer uses SideShow.
4. The 17″ laptop has the HP DreamColor Display (which was made in collaboration with Dreamworks). The DreamColor display shows over 16M colors, whereas normal displays only show 260K colors.
5. All the laptops (except for the 12″ ones) can accommodate 8GB of RAM.
6. Most of the laptops are easy to work on; you can easily replace the RAM or the HDD yourself. HP has great videos that show you how to work on these laptops on their site. Their software and driver support is awesome (everything works with 64 bit Vista). And with these DIY servicing videos, you can add and remove stuff from your laptop if you know what you’re doing.
7. They all come with HDD drive bays, to swap in place of the DVD drive. So you can add two SSDs later on in the year, and stripe them .
8. All the laptops come with an ambient light sensor (just like the Envy 133) and stereo speakers (not like the Envy, which has better speakers).
9. With a docking station, you get DVI-D output, in case you want to use a 30″ monitor. On the laptop itself is a DSUB connector.
10. They have a Thinkpad-like eraser-head mouse thing, and Thinkpad-like NightLight. They also have a dual array microphone, which great for videochats with Skype (along with the integrated webcam).

I was so impressed by them, that I ordered the 14″ model :).

Lenovo Thinkpads X200, X301, T400, T500, and W700

I was really excited about the X300, until I saw it in real life. The display is dull and sub-par… which is unfortunate, since the laptop is really fast! The X300’s replacement is coming soon - the X301. Here are some other interesting models that are in their lineup:

1. X200 - this is the 12″ widescreen replacement for the X61 (which I have). The keyboard on the X61 was too cramped for an adult human to use , so I’m glad they’ve made a widescreen version. The X300 laptop’s keyboard actually felt great, and was wide enough not to feel cramped, so I don’t know if this one will be cramped… Supposedly the screen in the X200 is 25% brighter than the X61, which should be great. It weighs between 3 and 3.6 lbs (depending on battery size).
2. W700 - this is a 17″ mobile workstation powerhouse! It has a built in digitizer . What a cool concept! It also has a gorgeous 17″ display (1920×1200) which is very bright (400NIT), and accurate color display. It comes with a bulit-in DVI-D connector, so you can hook it up to your 30″ monitor . Very cool! I love the built in digitizer. What a laptop!
3. T400 and T500 - 14″ and 15″ replacements for the 14″ and 15″ widescreen T61 series (both of which I own). They are lighter than their predecessors. They are faster. They have brighter LED backlit screens (the T400 one is supposed to be a huge improvement, but the T500 is not). It’s all good. Haven’t seen them in real life, so I don’t know how great the displays are. If you get the models with discrete graphics, you will be able to switch between integrated and discrete, without rebooting, just like the HP and Sony.

New SDK - 0.9 Beta

A new version of the Android SDK was released on Aug 18th 2008 - version 0.9 beta. There are lots of bug fixes that are in this SDK along with new functionality. Here’s a link with lots more detail on this. Here are more links of interest:

1. Changes in the 0.9 SDK from the M5 SDK.
2. Release Notes for the 0.9 SDK.
3. An API Delta Report.
4. Instructions to upgrade from M5 SDK to 0.9 SDK.

Here are some highlights:

1. There isn’t going to be a complete Bluetooth API ready for the release of the 1.0 SDK later on in the year.
2. Google hired the person who made DroidDraw, and the Eclipse ADT has an XML UI viewer, which is pretty cool - this is still a work in progress, but this is a big step in the right direction.
3. A utility is provided to draw 9 patch images.
4. APK files must now be signed before installing, and adb push is now replaced with adb install.
5. A new home screen is bundled, the old one from M5 is now a sample app in the examples.
6. On Windows, the emulator shouldn’t take very long to startup like it did before.

New Handset?

The first Android handset, the HTC G1, is supposed to be released on Sept 17th on TMobile only. However, TMobile exclusivity only lasts for 1 week, after which other carriers will be able to sell the HTC G1 on Sept 24th. Here are more details on this. This is a crappy video of what it *might* look like.

The HTC G1 is supposed to have the following:

1. 3G radio
2. Android as it’s OS
3. 3MP camera
4. slide out keyboard
5. big 5″ x 3″ touchscreen display.

The TAO of Android

1. The biggest unknown still is – what will an Android handset look like? Will it have AGPS? Will it have 2D accelerated graphics, or 3D graphics? Will it have a 2.5G radio or a 3G radio? Will it have WiFi? How much RAM will it have? How much flash storage? What kind of processor? How big will the display be, etc… Quite simply put, what does the typical Android phone look like? How many of the assumptions that you’ve made in the development of your Android project/product are going to be proven wrong? Without knowing more about what an Android handset will look like, it becomes difficult to justify spending time and money on development of features/functionality that will not exist in the hardware that your Android software will run on, sometime in the future.
2. Here’s my biggest concern with Google… why haven’t they publicly released the new SDK to all developers? For some reason, they’ve only released this to the 50 entrants of their Android Developer Challenge. Google must have “it’s collective Android head” up it’s ass with this decision. I can’t think of one good reason why an OPEN platform has PRIVATE SDK releases. Can you? When Sun open sourced Java, you could download the latest release and beta and alpha releases as they are being built, and you can even download pre-releases of the next version of Java… does Google not understand open source, from the perspective of 3rd party developers? I know they do, since they do one hell of a job with GWT… which is a marvel of technology… hard to imagine GWT and Android coming from the same ‘mother ship’… Anyway, my concern with this boneheaded move is what else do they have in mind down the line to really screw everything up at the last minute? For a platform that has no devices in the market… this is a really dumb thing to do… unless of course, they don’t really think anyone relevant is really interested in touching their platform at this early stage… who knows… I could go on guessing, but this decision stinks no matter how you look at it, or how inaccurate my guesses are.
3. The Android SDK and platform is undoubtedly more powerful than JavaME; it is as powerful as (if not more than) WinMo and iPhone (in API richness and capabilities). I’m not talking about fling scrolling, but really powerful APIs to deliver mobile experiences that have not been built yet . It’s like a little desktop environment rolled into a mobile device (with copy/paste, background tasks, embedded database, file system, and lots of other goodies missing from the iPhone). Clearly, Google is subconsciously targeting more powerful devices… Having said this, there are a couple of things in Google’s way… there are lots of good choices out there for companies to make software for – WinMo, Blackberry, iPhone. Each one of these platforms uses a different programming language and SDK. BB uses JavaME, and WinMo uses C#… I can argue that C# and Java are practically twins… and iPhone uses Objective C, which is an unfamiliar/unpopular language for most programmers in the world (talented and talentless alike). However, the Android SDK is very alien to anyone who’s done Java software development before . The headaches I’ve had with this API have made me think seriously about learning Objective C and learning the iPhone SDK . But I could pick up JavaME much more easily and build apps quickly and have all the BB’s in the world as my target platform… For Java people that’s a difficult decision to justify, ie, to use Android in favor of JavaME.
4. Symbian is ALSO open source. This is sure to be a thorn in the side of Android. And Symbian OS has full support for JavaME and PersonalJava – always has… so Nokia’s platform is quite attractive since it’s out there and being used, and is OSS. So if you’re a handset maker, would you go with Android or Symbian? Tough one to answer… since they are both ‘free’. Android being Linux based makes it so that device drivers are readily available, and relatively easy to build for a variety of underlying hardware (radios, CPUs, GPUs, and a whole host of other chipsets).
5. From the perspective of a mobile software ISV, it might make sense to stake a claim in the Android camp, while it’s still new… and it will be sure to get Google’s attention… but beyond that, I don’t know of any good arguments for Android…
6. Google is supposedly embracing the developer community with Android. This is total horseshit . If they were embracing developers, then they would not have private SDKs, and public SDKs without any source code provided… Even if they were embracing developers, that doesn’t make consumers want to buy handsets . Apple made the iPhone a status symbol, as much fashion statement, as electronic device… Anyway, that’s Google’s problem… They don’t have any handset manufacturers selling compelling handsets right now, though a few have made announcements (HTC Touch should be pretty awesome).

In summary. Android has a hostile SDK that requires special expertise to handle and leverage (sure to keep lots of developers away). There are no handsets out there yet, so lots of ISVs won’t touch this platform. Very few ISVs or developers to compete against.

Update - Aug 14 2008 - 219 developers signed a petition asking Google for more information about Android’s progress, and Google offering nothing substantive in response, replying merely with a ‘thank you’.

This tutorial discusses the various options that are available as of the M5 SDK of deploying Android apps to devices. As the next release of the SDK is provided, I’m sure more options and strategies will become available.

Proceed to the full tutorial - Android Application Provisioning Strategies