I’ve been writing some Flash components recently. I really like how they designed the component framework, and I’m curious to see how Flash 9 will improve on it. But they really need to do something about the Write->Test cycle that you have to use.

Now keep in mind where I’m coming from. I’m used to developing Java or C++ GUI apps, where you have an Ant XML or Makefile that runs through your dependency tree and builds your app. Then you run it and see what happens with your latest edits. Not so for Flash components.

First, you need your FLA file with any symbols and objects your code is going to reference, and an object representing the component. OK. Cool.

Next you have a separate .as file with your code. Still cool.

To build, you right click on the component symbol in the FLA and select “Convert to Compiled Clip”. You then get a new symbol with your compiled component.

Now we can run, right? Mmmm.. No.

You’ve got to have a separate test FLA sitting around first. Then you copy your compiled component from the component FLA library to your test doc’s library. If you already have a previous one there, you have to tell it to overwrite it with a dialog box. Then, assuming the symbol is on the stage, you can run it. Pheeeew.

Admittedly, it’s not that hard. But all this mousing around each time I want to test is very annoying. I want a more efficient update pipeline.

Does anyone have a trick they use to make the Write->Test cycle faster?

I recently decided to try out the bluetooth functionality on my TomTom One GPS. They offer a free month of traffic service, so I figured, what the hey.

Now I have to say that the TomTom is a great unit, regardless of the Bluetooth. It’s probably the cheapest device with a great form factor (not a nasty brick or blob) and an all-in-one, complete dataset ready to go. Sure it doesn’t do text to speech on the road names for you like the Garmin Nuvii, but who cares – it does the job supurbly. The only complaint I have is that the acquisition time when I get off the plane in a new city is pretty absurd. I’m talking 15 mins sometimes. Yikes. But I’ll live. All subsequent lock-ons are almost instantaneous when you turn the unit on.

So what’s with Bluetooth on this thing? Well you can do tons of stuff actually. Once you pair the phone, you can download new day and night color schemes to match your dashboard, new guidance voices (I even downloaded John Clease!), routes, POIs, traffic camera locations for Europe… But I was going to focus on the traffic, which is the most compelling reason to connect.

First of all, my phone (a Verizon XV6700) didn’t have a DUN profile, so I had to do the manual thing. Not a big deal since I did it on many other devices already – like my Powerbook. The good thing was that the TomTom discovered it right away and easily paired.

The problem I always hit with DUN over Bluetooth is that one connection works, but then something breaks and it never works again till you reboot both devices. But for some reason, this wasn’t the case with the TomTom.

What happens is that the TomTom sits happily on your dash, connecting through the phone every 15 mins (configurable), grabbing traffic reports, and putting little markers on your screen to let you know what’s coming. It just works(tm)! What’s more is that it will route you around traffic automatically if you’d like when the situation changes. I expected some sort of BSOD on the TomTom or flames to start shooting out of my phone sometime during the trip. But nothing like that happened. If I turned off Bluetooth or was on the phone, the TomTom didn’t make a stink – it just waited a bit, kept the old data and checked again later. Nice.

Now if only my Powerbook would stay connected through Bluetooth.

I know it’s late, but I’ve just been able to post some pics from CTIA.

MoCoMixer Photos – we were on top of the Staples Center!

MoMoLa Pics.  They suck.  No, I wasn’t drunk – just busy talking and reconnecting with people:

Some cool Symbian-powered phones:

A couple from the new batch of Windows Mobile Smartphones:

Hello Moto:

A Tony Hawk chaser:

I expected mobile advertising to be fairly big at this year’s CTIA, but I didn’t realize that it would be one of the center-stage topics of the show. Everyone from publishers to platform providers to carriers were out to learn all they could about the offerings, and how they differ from each other. But the best part was how much excitement publishers felt for having another monetization method for their content. It’s been a long time coming.

One thing I was worried about was the overlap of all the companies in this space. But in all honesty, everyone seems to be taking a different approach, all of them valid. I discuss more about how AdHoc differs below.

Now this isn’t to say everyone is jumping in feet first. The CPC rate and clickthrough numbers being reported by the players in our area still vary widely from each other, and the true revenue streams that these different services offer have yet to be quantified or validated. But everyone is in agreement – mobile advertising is the engine that will push mobile innovation forward.

Yeah, I work for a mobile advertising technology company and this is starting to sound like a fluff piece. So let me just go through some of the common questions we’ve fielded over the past few days:

Q: What are the click-through rates being reported?

A: In the tests with our initial developers, we’ve been getting 3.8 – 5.8 percent click-throughs. This is for WAP, not applications. The application developers have longer release cycles, so we’ll certainly be collecting more data as they are released and start pumping real ads to real users.

Q: What are the normal CPC numbers you’ve seen advertisers agree to?

A: $0.10 to $0.25 has been the range that our early-partner advertisers have been willing to pay.

Q: How much will we make?

A: You get 60% (as a standard baseline) of the CPC on each click. If you bring your own advertisers or have something more to offer, we can negotiate.

Q: What is your business model?

A: We have focused most of our effort on creating a solid middleware solution with a programmatic web service API that we can whitelabel to carriers, major media companies, etc. We are also building an open-market solution around this middleware to create our own third-party mobile ad service – and we’re already seeing around 2 million page views per month and are growing.

Q: What ads will I get? Can I pick?

A1: Our system has a detailed targeting mechanism that automatically helps narrow down the ads best suited for your request. You can select some defaults for your app, but you can target each request for an ad differently at runtime. If, for example, you have a social networking application with different chat rooms, you can request different types of ads (eg. food, news, music, etc.) depending on which chat room the user is in. There’s a ton of targeting parameters you can use, and we’re expanding the system heavily in future cycles to take advantage of the mobile device even more.

A2: You can bring your own advertisers and just use those ads. You can pull from our public sets of ads, or a combination of both. You can blacklist certain public ads as well. Basically, you can create your own ad ecosystem, specially targeted to your application.

Q: Do I need to use a library in our app? Do I need to use javascript in my WAP site?

A: No way. We’re a simple REST XML or JSON web service. Integration is fast and easy and you determine how you want to present the ads and register the clicks.

Q: I don’t want to make network calls from my app. I already talk to my own server and don’t want to talk to yours from the phone too.

A: That’s not a question. But I kid, I kid. Your server can talk to ours and pull the ads there. Cache as many as you want and then send them out to your clients with the rest of your data. Register clicks to us from your server when your clients report back.

Q: What about reporting and control? Can I make this a part of my infrastructure or do I have to go through a web interface?

A: Our first level of control is a REST XML interface for all administration and reporting tasks. You can do everything you need through that. Our web interface that layers over that web service is coming in the next month or so, and both will be available to publishers, advertisers, and infrastructure partners.

Q: I want the ability to manage and serve ads in my platform or infrastructure. I don’t want a third-party service, can I bring it in house?

A: Yes. The core system is designed to be a middleware component, and we can license the platform to you for use with your own service.

Q: Are the carriers cool with this?

A: The short answer is “probably”. However each carrier is addressing/experimenting with the mobile advertising opportunities differently. As an example, one of the application publishers we are working with has gotten approval from Verizon to include ads in their app.

Q: How do you differ from (insert other mobile advertising company here)

A: Depends on the company. We have our little comparison sheet, but the general answer is that our the ability to become a part of your infrastructure through a straightforward web services API, our focus on apps (in addition to WAP and SMS), and the ability to give publishers much more integration choice are our major differentiators.

I was at the MoCoMixer last night and got a chance to speak with some guys from the Qualcomm MediaFlo group. They’re in the middle of a test with Sprint, and they have a buch of major metro areas lit up with the service now.

Some interesting facts from their trial. Keep in mind, these guys are from Qualcomm so it’s going to be biased:

• People love watching shows on it. Some have even said watching movies is not a problem and even quite enjoyable.
• Women love the service – surveys have stated that they watch it while their husbands watch a show they don’t like on the big TV
• People love it in bed – like curling up with a book
• It runs between 24 to 30 frames per second at around 320×240
• The system is running about 12 channels in the test now, but is theoretically capable of running up around 20
• Qualcomm also makes DVB-H components, but they see more promise in MediaFlo
• DVB-H is more power hungry by about a factor of 2 and runs at around 8-15 fps

They were unable to show me the service live, because it’s not lit up in LA yet, But I did check out the Sprint SPH-M250 and the MediaFlo interface (pictured above). I have to admit – very very impressive. They say that MediaFlo streaming time is about the same as talk time on one battery. Not bad.