Seven Days with Windows Phone 7

Last Friday I decided to put the Blackberry down for a week and use a new phone for seven days. If you know me, you’ll know I’m an avid Blackberry user. I pretty much don’t need a laptop, on my Blackberry I’m nearly as efficient as I am when I’m sitting at my desk at my computer. For this test, I chose a Samsung Focus, a Windows Phone 7 device with the stock operating system (no Mango) and used it for a week. Here are some of my observations:

Pros:

  • The screen is beautiful. Inky blacks, vibrant colors, everything looks beautiful on the device.
  • The UI. For the iOS diehards out there, you might find Windows Phone’s animations a bit over the top but I’m absolutely in love with them. I found myself often swiping the UIs to just play with the animations.
  • The phone feels alive with data. It does a fantastic job integrating my Facebook, Google and Windows Live accounts and giving me a holistic view of my friends and contacts.
  • Live tiles. I wish there was more of this, but the live tiles as the app icons is sexy. They pulse with information that’s hiding under them. Some of them aren’t really that useful or interesting like the Zune app or the Photos app (I don’t need to see Lady Gaga’s for two straight days — show me my album art).
  • The browser. Before you jump down my throat, remember I’m coming from a Blackberry. Even though it’s IE7, the browser to me is a huge step forward from what I’m used to.
  • The camera. Beautiful photos and great videos. Love taking photos with this phone.
  • Windows 7 Phone Connector for Mac. I was surprised to see how much care and attention went in to making the phone work on the Mac. Music syncs seamlessly over from iTunes (altho there’s no audiobook suport and the Zune app keeps forgetting my location within a podcast).

Cons

  • The keyboard. Oy, I miss a real keyboard. Of course compared to a Blackberry keyboard, the on-screen keyboard holds no salt. On the other hand, I also own an iPad and I have an iPhone, and I feel that I’m 10x more accurate typing on iOS devices and it’s 100x better at making suggestions than Windows Phone. This, more than anything, holds me back from making it a full time phone. I constantly found myself having to backspace because I accidentally started a new line, pushed space by accident, or something else equally obnoxious. I never had these issues typing on an iOS device.
  • Windows Live, Twitter, Linkedin. You can’t turn off the Windows Live contacts. Once you hook your device up to your Windows Live account, you can only turn off email sync from Hotmail but you can’t disable Contacts sync. Come on guys. My Hotmail address book is so dated and unused so showing me all those contacts is silly. Let me turn it off. No Linkedin app, which is a minor annoyance, but the Twitter app is a trainwreck. It’s slow, buggy and doesn’t integrate at all with the phone well.
  • Apps. The Marketplace has a dearth of content, and half of it seems like it’s made by Microsoft. In addition, navigating the Marketplace is impossible and it seems totally chaotic and disorganized.

There were other minor annoyances, such as there being no unified Inbox (e.g. my Sencha email and my personal Gmail have their own icons), but that’s more on the minor side. My understanding is a lot of this is fixed up and better in Mango, so I’m looking forward to that.

Overall, I think if I were to buy a phone, it’d be a two horse game between Windows Phone (assuming Mango is all that) and iOS. I haven’t spent a ton of time with Android, but based on what I’ve seen and having now used Windows Phone, I think the experience of Windows Phone is far better than Android’s.

Introducing Quick Group Chat

I’ve been working on a litte side project the last few weeks called Quick Group Chat. The site/service came from some IM conversations I was having with friends. I was talking to one friend on Gtalk and the other was on AIM and we were trying to plan a trip. There was no way for us to get in to a ‘quick group chat’ that let us ad hoc talk with each other.

I’d been looking for an excuse to play with nodejs and jquery, so I forked the node_chat example app. Since I started with the node_chat demo, I had a good structure to get started with. The app is basically built out of four files: server.js, client.js, style.css and index.html. To start off I added in a layer called ‘rooms’ in to the server that encapsulated a session, which represents a user. When a user joins, if they aren’t trying to join a room or if the server can’t find a room they were trying to join, a new room is created and an ID is given to it. The user’s session is assigned to that room and the chat buffer is kept for that room. The ID is passed back to the client, and the client updates the location.hash with the room’s ID.

From then anybody who has the URL with the location.hash can join the room. When the user navigates to that URL, the client passes the room ID to the server, and the server joins the user to the room. Since the chat buffer is kept for the room, every time a user joins the room they get to see the prior chat log. When the last user leaves a room, the room is destroyed along with all the data. Hence, quick group chat. Once you’re in the room, the URL is they to invite other people in.  It’s all pretty simple.

I also added in some styling to make it little more fun and easier to read. Each user is assigned their own color based on a color wheel. The formula is kind of fun and easy. For each user’s nickname the code goes over the nick and sums up the ASCII code for each letter in the name, then mod’s it against the total number of colors in the color wheel then assigns a CSS class for that color to the message. That way every time “Aditya” logs in, the user’s color is the same. There’s one exception, and that’s the “me” user. Your typing always looks the same always; thus, the way other people see “Aditya” is always consistent and they see a consistent color for you. I may change that later but it makes other people’s chat pop and your own words a bit more subdued.

Lastly, I hosted it on duostack. This was one of the coolest parts. Once I set up some SSH keys, I added duostack as a remote to my git. Every time I do a “git push duostack”, their remote repository is updated and the app recycles. It’s crazy easy to deploy to their service and it runs really well there. I’ve been amazed at how easy it is and really happy with the service.

Check it out, use it yourself, or fork it and let me know how it goes!

Hi, I’m The Insides of Your TV

As televisions and TV service has gotten more and more sophisticated since the switch over to digital, the insides of your TV have gotten more and more complicated. What’s actually inside those TVs and how do they tick? Well, it’s both simple and complicated.

In the United States, almost all television is viewed by some pay-TV operator (think cable or satellite) and your TV acts as a display. There’s a ton of smarts and processing in the TV to smooth out the video, deblock compression artefacts, process the audio, etc. But the core part of the video experience is delivered by the cable box and delivered through the HDMI cable. Since the cable or satellite company own the entire pipe, they are normally built with custom made solutions by companies like NDS, OpenTV, and the like. A small percent watch broadcast TV in the United States (think bunny ears). In that case, specs made by the ATSC describe how the digital broadcast is supposed to work and the TV does all the heavy lifting.

In other markets, like in Europe, there is a lot of free-to-air broadcasts, and they’re specified by groups such as the Digital TV Group in the UK or DVB in Europe. Like ATSC in the US, these standards basically describe how broadcast digital TV is supposed to work, including things like the video codec, the audio codec, channel guides, any other data in the stream.

Most broadcast systems in the world currently use MPEG2 as the video codec, and can transmit in the high 10s of bandwidth per carrier, typically the US about 18 Mbps. Systems such as DVB-T2 are looking to move to H.264 as their video codec standard to more efficiently use the same amount of bandwidth.

But enough about codecs, how does it all work? It’s acutally pretty simple. Inside the TV (or cable box) there are a bunch of electronics and at the core of it is a system-on-chip or SoC. In the TV world, there are a few quite a few companies that make these SoC, such as Broadcom, MediaTek, STMicro, Trident, Intel, Zoran, MStar and probably more I can’t recall off the top of my head. These SoCs handle all the work required to make TV happen. They process the incoming stream, whether it’s a raw feed from a cable, satellite or broadcast TV feed, decrypt the streams if it’s protected, then decode the audio and video and sync it up, then sent it along, either to the display or on to the TV.

This picture is the inside of a flat planel TV. There are there major components shown here. On the far right is the logic board. On the logic board is the SoC, connectors to HDMI, cable and audio, memory chips, and a few other parts. In the middle is the power system, which powers the actual panel. On the far left is the speaker. The most impressive part of these systems is how slim hardware vendors have now managed to make everything while still retaining quality, especially around the audio from the speakers.

TVs (and set top boxes) are typically very very good at decoding and rendering video. They can typically decode Bluray quality in their sleep (to put it in context that’s roughly 39 Mbps of data), all the while doing all kinda of real time image and video processing to make it look even better. It’s really quite impressive how much data goes through a TV system in a second when rendering 1080p (1920w * 1080h * 24fps * 24bit color + 448kbps-ish of audio).

So that’s how your TV works! Easy, right?

Announcing AIR 2.5 for TV

I’m sitting backstage at the Nokia Theater LA Live, working on final prep and rehearsals for our CTO’s keynote. The doors are open and attendees are starting to come in. In the keynote, one of the many things we’re announcing is Adobe AIR for TV. We’re very excited that after a year+ of hard work, crazy travel, late nights, and many conference calls between San Jose, San Francisco, Seoul, Tokyo, and Bangalore that we’re releasing the first AIR runtime to television sets and Bluray players

Our launch partner is Samsung, who will be embedding the AIR TV runtime on their SmartTV products. Very exciting opportunity for developers who want to get to new screens. There’s already been a ton of overage, but if you’re at MAX come to the keynote today to check out Kevin Lynch present some exciting demos that you won’t want to miss.

Here’s a list of places you can learn more:

Deleteing Duplicate Contact Lists On a Blackberry

This has been frustrating me for a few days now. If you have an extra address book / contact list on your Blackberry that you can’t seem to delete in any way, you can force it to resync from the server.

This is caused when someone moves or re-adds a BB user to the BES without wiping their Blackberry before reactivating. This will create a new contact list each time. To remove it, go to Contacts and click Options. Then type rset, it will pop up with a screen asking if you want to wipe the contacts, select yes through all windows. You can then wirelessly sync or use desktop manager to repopulate contacts.

Debugging iPhone App Submissions

In December, I posted about how to debug iPhone code signing issues. We’ve had a ton of developers building apps and the submission process to Apple’s iTunes Connect is far from straightforward. Here are some tips on how to debug your iPhone app submission. Most of these are specific to the pre-release of Flash Pro CS5, but all the certs stuff should apply all the same.

  1. Export your Distribution P12. Make sure it has a private key and a public cert. Use openssl to verify (instructions below)
  2. Download your Distribution mobileprovision. Open it up and sure that it has the right App ID (search for the string <key>ApplicationIdentifierPrefix</key>)
  3. If you’re using Flash Pro CS5, ensure you’re on Beta 4 or higher.
  4. Publish your app for App Store
  5. Rename the IPA to ZIP and unzip. Keep the ZIP.
  6. Dump your codesign for the .APP that’s inside the unziped folder and make sure it matches your Distribution P12 (must have the line in the dump which says “Authority=iPhone Distribution”).
  7. Inside the unzipped folder, look for an embedded.mobileprovision. Make sure it’s the same exact file as the distro mobile provision you downloaded in step 2, just renamed.
  8. Verify the inside of your all looks roughly like this the image below.
  9. Upload your ZIP to iTunes Connect.

Here’s an example of what the inside of the .APP file should look like. Key things in here are for YourAppHere to include an embedded.mobileprovision, Default.png, Icon.png, Icon-Small.png and of course your app’s binary (YourAppHere). The rest should be automatically generated when your app is packaged. It’s also probably a good idea to keep your file name to letters and numbers.

Lastly, for debugging your p12, use:

abansodmbp:~ abansod$ openssl pkcs12 -in ~/Desktop/asdf.p12
Enter Import Password:
MAC verified OK
Bag Attributes
friendlyName: iPhone Distribution: Aditya Bansod (8HHA9BB65G)
localKeyID: E8 3C CF A0 3B 7F 77 C1 E8 89 96 2F B7 8F 0D E4 FD D3 B9 19
subject=/UID=PSLAU6FDD9/CN=iPhone: Aditya Bansod (8HHA9BB65G)/C=US
issuer=/C=US/O=Apple Inc./OU=Apple Worldwide Developer Relations/CN=Apple Worldwide Developer Relations Certification Authority
-----BEGIN CERTIFICATE-----
<SNIP>
-----END CERTIFICATE-----
Bag Attributes
friendlyName: Aditya Bansod
localKeyID: E8 3C CF A0 3B 7F 77 C1 E8 89 96 2F B7 8F 0D E4 FD C3 B9 19
Key Attributes: <No Attributes>
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,B2347A9F38B7303D
<SNIP>
-----END RSA PRIVATE KEY-----

iPhone Hardware Specs

I compiled this list from the internets on the hardware inside the various revs of the iPhone and iPod touch.

  • iPhone 8GB – Samsung S5L8900 (ARM11) 400 mhz
  • Touch 1st Gen: Samsung S5L8900 (ARM11) 400mhz (almost none of these exist)
  • iPhone 3G 8GB: Samsung S5L8900 (ARM11) 412 mhz
  • Touch 2nd Gen: Samsung S5L8900 (ARM11) 533mhz
  • iPhone 3GS: Samsung S5PC100 (Cortex A8) 600mhz
  • Touch 3rd Gen: Samsung S5PC100 (Cortex A8) 600mhz

General rule of thumb is the Touch is faster than the equivalent iPhone, and the latest gen of hardware has moved to the ARM Cortex architecture and a PowerVR SGX GPU (e.g. OpenGL ES 2.0). Also, the iPhone 8GB only sold (legally) in the states, although via black market channels it has shown up all over the world.

Sprint Backlog Task: Ice Cream

One of the many, many reasons I love working on software is how whimsical it can sometimes be. I was reviewing a sprint backlog for one of the scrum teams that work on the Distribution Service and came across this sprint item.

Ice Cream

Building software is most of the time super stressful but I love when people find a way to add some funny in to the mix. Remember, getting the ice cream comes before updating the production server.

P.S. This backlog item reminds me of a similar story when I was working in China. One of our developers in China was reading a set up document written by a developer in the states. One of the steps read “install Windows Server”, and the step right after that said to “Enjoy a Dr Pepper” since the installation would take a while. Our dev had no idea what that meant and of course Baidu nor Google were of any help. In the end, he ended up having to ask his manager what that step meant.

Debugging iPhone Code Signing

Code signing on the iPhone can be frustrating, and it gets even more frustrating when trying to submit an app to the App Store.

There are two forms of builds, deployment and distribution. You can use the codesign tool from Xcode to verify the signature in your app bundle to ensure they’re signed correctly. The part that is bolded is which certificate was used to sign the app.

abansodmbp:~ abansod$ codesign -dvvvv yourapp.app
Executable=/Users/abansod/yourapp.app/yourapp
Identifier=com.test.builtwithflash
Format=bundle with Mach-O thin (armv6)
CodeDirectory v=20001 size=43398 flags=0x0(none) hashes=2161+5 location=embedded
CDHash=928599f1a2a6db645a3bbaf17388775912933f38
Signature size=4283
Authority=iPhone Developer: Aditya Bansod
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Nov 13, 2009 4:10:59 PM
Info.plist entries=19
Sealed Resources rules=5 files=7
Internal requirements count=0 size=12

In the above example you can see that it’s signed with my Developer cert. If the app isn’t signed with a developer cert it won’t run on your device. The same thing applies if you’re deploying to the app store. In that case, your app needs to be signed with your Deployment certificate, and you can use the same codesign tool to validate it’s signed with the correct cert.