Got an email from dev.mobi today saying they’re re-branding to mobiForge.

I’ve stated my .mobi opinions in the past and you can imagine I’m pretty happy about this. The dev.mobi tools, standards and docs are such a great resource for the mobile development community, and they shouldn’t be confused with the .mobi or not to .mobi debate.

Let’s just make great, standards-based mobile apps and sites.

Full text of the email is below.

Next Monday, you’ll see an exciting new development to dev.mobi. After two fantastic years in its current form, we have redesigned the site - and we are changing the name.

We’re proud to announce that dev.mobi will become mobiForge.

(Don’t worry, all your bookmarks will still work, the same great content is there - and of course it remains the world’s largest independent mobile development community! If you’re interested in the amazing opportunities and technologies of the mobile web, then this remains the site for you.)

Since we launched, dev.mobi has truly exceeded our greatest expectations - the size of the community, the content we’ve been lucky enough to publish, and the great feedback we’ve had from you.

Confucius said that “only the wisest and the stupidest cannot change”. He might not have been talking about web sites, but we do know how surprising it can be when a web site that you know and love changes overnight, and the name, navigation, and layout you’re used to suddenly disappear.

Hence this advance notice! (And to ask you kindly to tolerate a little planned downtime on Sunday, 14 September )

Most significantly, the navigational structure of the site will change. We have created hundreds of articles, blog posts and forums over the last two years, and they weren’t categorised particularly well. That’ll be fixed.

Secondly, as part of mobiForge, we’re launching a new directory service with listings of resources, site builders, companies, tools and even people that will help you get ahead in the mobile web. We think you’ll love it. (And if you want to make sure you’re on it, drop us a line at
tech@mtld.mobi)

We’re also unleashing a new vertical search feature. You’ll be able to search not only mobiForge, but a wide range of other mobile development resources from across the web: all in one place.

Finally, the site will have a very new look and feel, which I think will speak for itself. Let us know what you think.

As you know, we’re madly passionate about the mobile web. And we’re also passionate about helping the people that make it happen. People like you - the tens of thousands of designers, engineers, and technology professionals
- from all over the world - who are living the mobile development dream.

Many thanks for your support, your feedback and your continued participation in the community. We’d love to know what you think of the new site come Monday morning, and we’ll see you on the forums!

James, Ruadhan, Claire, and all here at the dotMobi team.

Japanese company, Cross Borders Inc. made a cool way to create your own QR code.

Type in a URL and an army of small robots comes to build the code for you.

If you haven’t seen a QR code before, I’m not surprised. They’re much more popular outside the US, especially in Japan where they’re getting ubiquitous. They’re basically a 2D barcode, encoding a string (in this case a URL), with some error correction built in. They can be optically recognized, and are most frequently captured by snapping a picture from a mobile device The device can take action using the encoded string, like launching the web browser and heading to a URL.

So you can do things like run billboard ads with QR codes that take people directly to a mobile ad or coupon.

I found this via Asiajin - and check out the reference to Winksite there too! My opinion is that Winksite is the best example of QR codes being integrated into a mobile web product right now.

Stoyan Stefanov from Yahoo has a great slideshow up with tips on improving your web page’s performance. All of these tips apply to mobile sites as well, and are even more important given the constrained resources.

| View | Upload your own

There’s a specific section on mobile in there, with a few tips focused mostly on iPhone. Good stuff.

As I write this, I can’t even get to the SDK homepage on Apple.com due to all the load.

The portability and reach of web apps is great and all, but just wait and see how the buzz boils up for native apps for the iPhone. Even before we get the OS update that lets us run the damn things, you bet that people will be talking, developing, and gossiping like crazy about the potential for awesomeness with this native SDK.

As I said in my Android development thoughts post, the possibilities of native app development spark creative juices in developers. Web apps have their own draw, but the design process gets so heavily constrained from the outset, that it takes a lot of the edge off. It’s a sandbox that dulls the spirit a bit.

Another example - Nokia S60 and Maemo development. Such creative apps have been developed there. Now imagine similar potential with the added benefit of easy install, an enormous audience that includes the US (because Nokia really doesn’t right now), and a sweet development kit. Both Nokia and Android hit some but not every single one of those notes. But when they’re all put together…. well, if it’s not enough to get your little developer excited, then you don’t have a little developer in you.

So Android - you have to get the install base and the app distribution components in place to match Apple’s move. And Nokia, you pretty much have to do the same, and your choice of development runtimes is excellent too, since you try pretty hard to give each first-class citizen status on the device.

And Microsoft… Well. Your native development requires such an enormous ramp-up time, it doesn’t inspire excitement at all. .NET-CF doesn’t count either. It’s too slow, requires a large runtime and feels like a second-class citizen. If you wouldn’t want to build a game in it, it doesn’t count.

So here’s to native apps with excellent SDK’s, great tools, huge reach, and easy distribution. Some people say you’re a dying breed, but you have a lot of life left in you in my book.

If there was one place Google Gears could really make a difference, it would be mobile.

Now Windows Mobile gets the first version, and I bet the iPhone version will be coming along soon after the SDK hits.

The obvious benefit would be the ability to manipulate Mobile Web-based UIs while offline, syncing the data when a connection is reestablished. However, I’m excited to see it used as a UI accelerator, in both offline and online modes.

Stop making those AJAX calls as soon as the user interacts with a control. Pre-cache data in the background and populate from local stores.

Imagine the excellent Facebook iPhone interface when it doesn’t load each time you navigate to a new tab? Cycling back and forth between Profiles and your Events List, for example, would be immediate.

Load multiple resolutions of photos in the background to create a zoomable picture viewer.

The potential for user experience improvement here is great. I can’t wait to see what the developer community comes up with.

Vance from .Mobi was nice enough to send a counter point to my last post. The .mobi versus autodetection debate has gone on for a while, and I’ve stayed out of it, because I wanted to see how much traction .Mobi was able to achieve.

Although I thought that segmenting mobile content on the TLD level was suboptimal, promoting the existence and proliferation of mobile content through .Mobi could create a much needed rising tide - and I’d be all for that.

But in my opinion, the tide hasn’t come in.

Although I honestly love and use their tools, web validators and profilers, and think their promotion of standards and patterns really helps lower the barrier to entry into mobile web development, I didn’t realize until Vance’s post how much I’ve become anti-.mobi TLD.

So I thought I’d post Vance’s link to the .mobi blog post defending their TLD. Check out the link, and then read my comment below - it basically sums up my stance.

Vance’s comment:

dotMobi talked about this on our blog today. You may not agree but I think it’s worth considering all viewpoints. See http://dotmobi.typepad.com/dotmobi/2008/02/do-you-have-the.html

My reply:

Vance. I understand where your post is coming from, but I don’t agree. Mobile formatting is not akin to geo localization. Not at all.

Even looking at the trivial evolution of this, if we segment mobile formatted content from web content, how then do we further segment the mobile content into localized information? Do you want a .mobi.uk? That’s getting a bit much, don’t you think?

In fact, I’d argue in the opposite direction. I think instead of forcing the user to identify their locale on the web, companies should do an IP geo lookup and forward to the correct localized site. Sure everyone can’t afford an enterprise-class IP lookup service, but BMW certainly can.

Your point about indexing mobile content better through the .mobi domain may have some merit, but not for long. Search engines are getting smarter, and there are many metadata cues that can be used to index properly.

Moving forward, URLs will take a back seat to search and default browser behavior. If I have a brand name, I want a .com domain because that’s the first thing a browser tries if a user only types a single word, and empirically, I see that search engines put .com domains that exactly match single word searches first.

If you get all the phones in the world to default to .mobi first, and all the search engines to place .mobi domains at the top of the list when searching from mobile, then I might buy in.

But as it stands now, if I have a brand name, I want a .com after it, and I want to have as much smarts at the front door as possible to get people to the right content based on their location and their device. Right now that’s the absolute best way to get the most users to the content they want.

I’m all for continuing the conversation in the comments here. I honestly don’t want to bash .Mobi because a lot of what they’re doing is quite good - as I’ve said above. But this TLD thing is just not sitting well with me.

Can someone change my mind? Give it a shot.

Hey LinkedIn, your mobile site is really quite good. It’s going to be a big help adding new people while at conferences, etc. and not having to wait till I can sit down with a laptop.

But if you’re going to use m.linkedin.com instead of detecting user-agents on www.linkedin.com, you might as well have used a .mobi address. (Read: this is the wrong thing to do)

Here’s what you do:

- Redirect based on user-agent from linkedin.com.

- Put a link on the bottom of your mobile pages to get to the full version of the site.

- Feel good that you’re not losing users who don’t know to put an m. before mobile URLs

- Profit!

Come on, if Facebook can do it, so can you.

I’ve had some time to play around with Android developing an actual app and wanted to make a few comments on my experience.

In general, development was quite pleasant, as I thought it would be when I took my first look. But there are some issues from the SDK being a bit immature that poked their heads up.

My goal was to write an app that made use of Android’s WebView component, and right off the bat, I was sorry to see that the link to example WebView code was broken. Many other components had excellent example code, but WebView’s gave me a fat 404.

OK. No need to dismay, they put up a nice class hierarchy, so I just needed to dig in there for a bit to get started. But first I needed to learn how to create layouts and Views.

Turns out it’s pretty cool, and makes extensive use of preprocessors set to run on build when you create an Android project in Eclipse. In your project’s resource (res) folder, there’s a layout folder where you can put XML files for each of your screens. For my one screen, in my main.xml, I used the line

<webview id="@+id/webview" android:layout_width="fill_parent" android:layout_height="fill_parent" />

to create a fulscreen WebView.

The preprocessor processed this XML on the next build, and updated an R.java file in my src path, providing a unique ID for me to access the WebView using findViewByID(), and probably modified some stuff in /bin to create an actual instance of a WebView in the binary. This really creates a nice separation of UI design from code. Good times.

It was a relatively easy task to tell the WebView to load a URL, and it was refreshing to see a lot of hooks into the browser callbacks - you can even bind your Java code to Javascript calls in the browser. But many of these features were a guessing game or required a bit of searching on the forums to figure out how to do - the docs were really lacking. Again, this is just SDK immaturity.

Creating menus and other UI views was just as easy, but had some much better documentation to guide you. However in most cases, the android forums could be mined to find someone who has come up with a solution to holes in the docs.

Once a project is compiled, it’s packaged into a standard pkzip format file with the extension .apk. Given that an apk is the official install package for Android, you’d expect it to have a MINE type identifiable by the built-in browser, allowing it to be installed OTA. No such luck in the version of the browser in the rc37a version of the emulator. I assume in a final version, the browser will download and install them like we’re used to with .cab or .JAD/.JAR’s.

The Eclipse integration makes emulator control very nice. An excellent logging system allows you to create useful logs with their own error levels and easily activate filters to monitor specific logs and levels in real time. You can manage the emulator filesystem with simple get and put commands, and get a barebones sh-style shell into the emulator from the commandline.

All things considered, developing for Android was fun and productive. Though I only tried a few components, (with the WebView probably being the worst documented of all), the experience made me want to come back for more when the docs get a revision.

I finally had a chance to sit down and digest the Android API docs and emulator.

First of all I have to say that the Android emulator is the snappiest phone emulator I’ve ever used. After the KITT-sensor style startup animation, a very usable phone interface pops up, and everything seems to flow as it should on an actual device.

That said, I don’t know if this thing is throttling performance to emulate the expected horsepower of the devices themselves. If not, some initial developers may be in for a surprise if their smooth-running apps get choked on production devices.

Development seems dirt simple. The Activities, Views, Intents, Notifications.. component model is phenomenally simple and presents a natural architecture framework for apps that encourages readability and maintainability - perfect for the collaborative, distributed world of open source. User interfaces can be designed programmatically or with an XML descriptor file, providing a bit more MVC-style separation, and interface themes are a concept built in at the core.

Creating custom components is a straightforward affair as well, with relatively few methods to override, and with Android even allowing you to easily extend or customize built-in components, of which there are many. You can even create groups of custom or built-in components into a custom, reusable layout that you can then treat as a single component. I can see a wonderful world of websites dedicated to sharing, trading, and rating Android components popping up, encouraging experimentation and super-rapid development through public components. Who would have thought you’d be mixing and matching mobile software components like people mix and match Flash components now.

It’s nice to see OpenGL-ES included as a prominent API feature on a mobile platform. It is listed as an optional API - meaning it might not be on every phone. But when it’s there, it should support hardware acceleration. Even though the Android 3D API is based on J2ME JSR239 OpenGL-ES, they say it may deviate, so here’s another point of fragmentation concern. But the basics are all there, drawing on inspiration from the famous GLU toolkit. This includes plenty of matrix ops, but only on 4×4’s it seems - the standard 3D transform matrix. You’re not getting a generalized matrix toolkit built in, but since their matrix representation is just a float array, you can easily create your own operations and interchange them with the provided ones.

Playing and recording media is handled by some nice provided classes - MediaPlayer and MediaRecorder. MediaPlayer can handle both local files and streaming over the net. I don’t see exactly what codecs it supports, but I assume it will be a plugin model as it matures. You can have the player draw to any Surface object, which is a building block for UI’s in Android. This is neat, since you can do a lot of things with Surfaces at runtime, including size and stack order transforms and alpha value mods. So I’m assuming you could move a video around the screen, resize, and alpha blend with other objects easily. On a mobile device. Nice. One thing I’d like to see is some kind of binding between a Surface and an OpenGL texture. You see what I’m getting at. Yeah - yummy. But I don’t see that in the current API.

Check out some GL surfaces in action in the emulator:

There’s an optional LBS API as well. This is still in a preliminary form, and isn’t complete. But they’ve given you a way to create some fake LocationProviders to test your next mind-blowing LBS app before real devices are released.

One super-unique API here is the Android Interface Definition Language (AIDL). You’d think this was the name of the XML UI descriptor format, but it’s not. It’s a way to define inter-process communication (IPC) between two separate processes running on the device. Yeah, we’re talking about kernel-assisted IPC messaging here. Very cool. There’s no shared memory, but AIDL lets you define your objects using primitives, and will pass them around for you. Makes the imagination run wild, doesn’t it?

For years, my imagination has produced some exciting ideas for mobile applications, and no matter what devices I wanted to aim for, the implementation details, limitations, and write/test cycles have just stifled my energy and enthusiasm. This is the first time I’ve read a mobile API and have actually been inspired to dream harder rather than restrict myself. It’s unobtrusive, organized, straightforward, and has a low barrier to entry while providing cutting edge functionality to the developer. This is the crux of the Android announcement. This is what the excitement should be about.

Now lets get some of these phones out there so the dream can live in the wild, not in a desktop sandbox.