Global Constant

Paul Graham’s essay on “What Happened to Yahoo” is very thought-provoking.

In technology, once you have bad programmers, you’re doomed. I can’t think of an instance where a company has sunk into technical mediocrity and recovered. Good programmers want to work with other good programmers. So once the quality of programmers at your company starts to drop, you enter a death spiral from which there is no recovery.

Paul talks about Yahoo being “taken over by suits and middle managers.” The effect of that is that any “hacker-centric culture” Yahoo might have had got crushed.

Google and Facebook, Paul says, still have this hacker-centric culture, and that’s why they’re so successful. He sums it up nicely:

So which companies need to have a hacker-centric culture? Which companies are “in the software business” in this respect? As Yahoo discovered, the area covered by this rule is bigger than most people realize. The answer is: any company that needs to have good software.

I interned for Kynetx earlier this summer and experienced that hacker-centric culture first hand. Nobody there wears a suit. For that matter, people rarely wore collared shirts. Diet Coke was a staple, and it wasn’t uncommon for the people to stay at the office late into the evening. Pretty much everybody is or has been a programmer. And what’s the result? Kynetx makes awesome software.

While I won’t mention where, I’ve also seen the flip-side of this, at a place where collared shirts are required, shorts forbidden, and normal business hours expected. The atmosphere feels more like a corporation than a software development shop. And it shows in the quality of the software they create and the time it takes to deliver it. Because that culture (read: not hacker-centric) has become so engrained in the organization, its chances of matching the innovation and success of companies like Facebook, Google, and Kynetx are significantly reduced. And its chances of attracting the brilliant talent a software shop absolutely needs to survive are also significantly reduced.

Anecdotally, this reminds me of “Simon the IT Dummy.” The whole series is hilarious, by the way–a great parody of the corporate culture so despised by brilliant hackers.

Two weeks ago, I bought an iPad. Just the normal WiFi version, nothing fancy. My original premise for buying it was that it might make a great device for school. I could buy ebooks for some of my textbooks. I could use it for taking notes in class, rather than carrying around my heavy HP Pavilion laptop. The battery life is much better than my laptop, and I’d have an always-on device ready for whenever I need it during the day. And between the ubiquitous WiFi at BYU and my Palm Pre as a mobile hotspot, it will always have connectivity.

The iPad really is a magical device. But for my needs as a student, it doesn’t measure up to my expectations. Here’s why:

---

E-book readers
Being one of the two primary reasons I bought the iPad, the e-book readers needed to be amazing to satisfy me. In short: I was disappointed.

iBooks is a fantastic app. It looks great and works well. All the expected functions are easily available (changing font size, screen brightness, bookmarking, annotations, highlighting, and searching). Beautiful app. The drawbacks are the lack of copy/paste functionality for the text and the immaturity of the ecosystem. By the latter I mean to say that the iBooks store is still quite small (especially compared to Amazon), and I can only read iBooks on my iPad or my iPod Touch. Not on my computer (even my Mac). If I’m going to buy e-books, I’m going to buy them from a good ecosystem.

The Kindle app is also good. It has the usual features with one notable (and fatal) exception: search. There is no way to do a keyword search on any Kindle product besides the Kindle itself (which has a physical keyboard). This is a deal-breaker for me, especially since most of the textbooks I would consider buying are available only through Amazon. The Kindle is a bit on the opposite end of the spectrum from iBooks: the ecosystem is excellent, but the app is only decent.

The Barnes & Noble app is pretty good. It has search, font controls, brightness, etc. Still no copy/paste. While the ecosystem is good (I can read my books on multiple devices–the Nook, all my Apple devices, and my PC), the book selection is not so great.

There are other e-readers I use, such as Stanza and Borders, but I won’t discuss them here. iBooks, the Kindle, and Barnes & Noble are the only ones that can really compete for my attention as far as reading textbooks goes.

My conclusion: Even among all the available e-readers for the iPad, I wasn’t able to find the ecosystem and functionality that I need. Kindle has the books I want, but doesn’t allow me to search them. None of the e-readers will let me export my annotations so I can use them elsewhere.

And there’s always the simple difference between reading a book on a screen and studying a physical book. It is now (and perhaps always will be) easier to flip through a physical book, to jump to the index while holding my place, or to open to a page where I left a sticky note for quick reference. E-readers have a long way to come before they’ll be considered a suitable replacement for textbooks.

Note taking
This is the second reason I bought the iPad, and it’s actually one in which the pros and cons are equally balanced.

There are several note taking apps I’ve tried out (including Mental Note, Idea Sketch, iDraft, Adobe Ideas, and Evernote). Mental Note, probably the best of the five for note taking, allows you to type as well as draw with your finger. It also allows you to embed sound clips (e.g., recording part of a lecture) and images (too bad the iPad doesn’t have a camera…). This is something that you can’t do very easily with a laptop (hard to draw diagrams) or plain old paper (hard to get down text quickly or use multimedia). The iPad wins on those fronts.

However, one of my prime criteria is that all the work I do on the iPad must be accessible and usable on all my other devices (phone, computer, even iPod). Evernote does a fantastic job of letting me compose content offline and then sync it in a sensible fashion if and when I come back online. I tried a word-processing app called Office² HD that lets me tie in to Dropbox and Google Docs. However, it requires that I be online to create or edit documents in those repositories, something I can never guarantee in a classroom. Thus, even though the iPad is a fantastic web device, it still falls short of my needs.

One other thing that’s the real killer: The iPad has a great on-screen keyboard; the very best I’ve ever used. But it’s still an on-screen keyboard. You get no tactile feedback and it’s really easy to hit keys you didn’t mean to hit. I can type about 80-90 WPM on a physical keyboard, but only 40-50 WPM on the iPad soft keyboard. And having to go back and correct my typos gets maddening even while writing a short email. If I were to use the iPad for serious word processing (including taking notes in class), I’d have to purchase the Bluetooth keyboard as well. And then I may as well be using a netbook.

Web browsing
Except for the absence of Flash (which I honestly only ever noticed once or twice), web browsing is great. Being able to pinch and zoom on any part of a page only makes it that much more enjoyable and interesting. And have I mentioned that the iPad is incredibly fast and very responsive? Web browsing is a pleasure.

Productivity
The calendar app is great–it’s what I was hoping to get from the iPod Touch when I bought it last year. It gives you an almost Google Calendar-esque experience, which is great. The Mail app also really benefits from the extra screen real estate. Other than that, the iPad versions of the standard Apple productivity apps are as good as or better than their iPhone counterparts. No complaints there.

Multimedia
The iPad wins on the multimedia front. Even though the screen isn’t as large as my 17″ laptop’s, viewing multimedia on the iPad is a pleasure. It’s very easy and well-integrated. The iPod app is great; it gives you a much better experience than you can get on the iPod Touch.

Showing photos to friends and family while sitting together on the couch give you the impression that the device was designed specifically for that. Very immersive experience.

And Google Earth is fantastic. No more need be said.

However, the iPad screams desperately to have multitasking. If I want to listen to Pandora rather than my own music collection, I’ve essentially incapacitated my iPad–it can’t do anything else until I’m done with Pandora. Word has it that iOS 4 will come to the iPad in November, but that’s still a long while to wait.

Gaming
I never bought the device to do gaming, but it wins on this front. Since several of my friends have iPod Touches, I bought the Scrabble app that lets us play together, using the iPad as the board and the iPods as tile racks for each person. Gaming on the iPad is awesome, even though I rarely have time for it.

---

Conclusion
The iPad is a great device. It has the potential to be revolutionary (whether it actually is now, as Apple claims, is debatable). It’s a joy to use, and the weight and battery life are great. It’s perfect for situations (such as at home) when you want to share multimedia with others. It all feels very natural. And I’m sure it’s great for business people.

But as a computer pseudo-replacement for a student, the iPad doesn’t fit the bill. E-book readers simply aren’t powerful enough yet to make studying with them productive and efficient. Typing for a long time is a pain without an external keyboard. And the benefits you get from having a touch interface don’t outweigh the drawbacks from not having a full-featured computer (including multitasking).

In short, it’s not worth the $500 I spent on it right now. Once the platform matures and the software gets better, I’ll reconsider buying an iPad again.

I posted quite a while ago about how I was switching to Android from webOS. I never actually did, and I’m very glad of it.

That was right around the time that the HTC Droid Incredible was getting all the hype in the Android world. It was the studly new favorite kid on the block: its specs were amazing (at the time) and it was on Verizon (which I have with my Palm Pre Plus).

As is the way with Android, the Incredible has since been eclipsed by the Droid X (also on Verizon). And I’m sure that in another month or two (or perhaps a week or two) there will be another amazing device to take it’s place.

Android devices are at the cutting edge as far as hardware goes. That’s great if you happen to have the newest device. But it also means that you’re almost guaranteed to be outperformed by the next device in a couple months. And don’t even get started on which devices are stuck with Android 1.6 or 2.1 and which ones won’t even be able to run Android 3. It’s a mighty competitive and fragmented world.

As far as hardware goes, then, the iPhone 4 is putting up some good competition. It’s a great device. The poor Palm Pre and Pixi can’t even compete any more with iPhone or Android.

But the reason I’m glad I stuck with my Pre isn’t the hardware. It’s the OS.

Take a look at PreCentral’s post today, “What switchers miss from webOS.” Seven of the nine points describe things about webOS that are superior to Android–they have nothing to do with the hardware at all. My personal favorites are universal search, gesture-based navigation, and Synergy.

• Universal search is super easy and really powerful: I can search my contacts and apps just by starting to type. Throw in direct links to Google, Google Maps, and Wikipedia and it’s just perfect.
• Gestures: Once I got the hang of these, they became a bit of second nature. I don’t have to move my finger up to the top of the screen and tap a small “back” button. I just swipe my finger back across the bottom of the screen (where it already was anyway). It’s a much more fluid system, less prone to errors.
• Synergy: All my contacts from Gmail, LinkedIn, and Facebook are all there, linked together. And seriously, what’s cooler than seeing my friend’s most recent Facebook profile pic on my screen when he calls?

I recently got an iPad. Ostensibly it’ll be a tool for reading e-books and taking notes in class without having to carry around my heavy HP Pavilion laptop. At the moment it’s more of just a toy. But one thing that has really struck me (again) is how beautiful the OS is. The apps have a consistent look-and-feel and they work well together. It’s a pleasure to use, and it does warrant the adjective “magical.”

webOS is getting quite close to this. The interface is very fluid and intuitive (in several ways more so than iOS). That consistency doesn’t always transfer to all the apps I have, but they do a pretty good job on the whole.

I’ve been using a Motorola Droid at my work for some mobile apps we’re developing. While it’s a powerful device that is (sometimes) faster than my Pre, the OS just isn’t as nice to use as either webOS or iOS. It feels like Linux. It’s still rather raw, and it seems like it was built for engineers. I’m an engineer myself, so I understand that. But when I’m using a mobile device, I’m doing it to have a fluid, pleasurable experience with my media on the go, whether that’s email, Twitter, web pages, or YouTube.

My Palm Pre is still slow. It still has a small screen. It’s still plagued with GPS issues. But I’ve delved a little into the Android world and found out that the grass isn’t as green there as I had thought.

I’m content to stay the course and see what great new things are coming for webOS this year.

There are a lot of websites I visit on my phone that haven’t been optimized for smartphones.

First of all, those websites bug me. Pinching and zooming and panning around just to find the tiny link I’m searching for gets old really fast.

So I have a proposition. I want a mobile app that will let me apply my own stylesheets to those websites. That way even though those webmasters refuse to optimize their site for me, I can still get an acceptable (read: usable) experience on their website from my phone.

Take BYU’s website for example. It was designed for a screen at least 985 pixels wide. That’s great on a computer, but it’s awful on a mobile screen that’s only 320 pixels wide.

Luckily, BYU’s web designers were smart enough to do almost all of the layout using CSS. This means that I can create a stylesheet of my own that will display only the stuff I want to see. For example, it could only show the Students and Route Y menus and hide the news feed and all the other links that I don’t care about.

The Web Developer add-on in Firefox will let me apply my own stylesheets to any website so I can make it look just how I want. Indeed, this sort of user modification of website styling was one of the core intentions of CSS in the first place. Users need not be at the mercy of webpage authors as far as presentation of content is concerned.

At the right, you can see the results when I disabled all linked stylesheets and instead used my own user stylesheet. At 320 pixels, you still can’t see everything, but it’s a start.

It would be cool if this app were a Kynetx endpoint. That would allow me to write rule-based modifications of websites in the cloud, without having to store anything locally on my phone. It would be even cooler if that app would just modify content right my default browser.

But even if that doesn’t work out, it would be possible to create a mobile app that displays the web pages in an embedded browser and then applies my favorite stylesheets to them as they’re being loaded.

It would be really cool if all browsers (including mobile browsers) would just support this natively. Opera does. Why does no one else?

Maybe I’ll just go write this mobile app myself.

I discovered Gabble this morning, a native Mac OS X client for Yammer. The interface is great, and it integrates seamlessly with Mac OS X. It offers threaded messaging, something the Adobe AIR client doesn’t do (even though it’s not quite as slick as the web application). It doesn’t artificially truncate URLs, meaning you can copy and paste URLs directly to/from the messages themselves without having to do any hoop-jumping or black magic.

It also uses Growl for its notifications.

The only catch is that you can’t use the default Yammer notification sounds. One of my friends particularly likes the one that says “Yam!” when a new message arrives.

I figured out a way to satisfy his “Yam!” fix.

Growl lets you customize notifications from individual applications, including specifying a sound that should play when a notification pops up. However, by default, only the typical Mac sounds are listed as options. But you can add a custom sound to that list if you put the sound file in ~/Library/Sounds.

Remember the Mac OS X program “say”? You can use it to create sound files as well. And if you use the voice “Cellos”, it sounds almost like the original “Yam!” sound from the AIR client. Run this command:

say -o ~/Library/Sounds/Yam.aiff -v Cellos yam

Now go to System Preferences and open up the Growl section. Click on Applications and then choose Gabble from the list. Click the Configure… button. You should now see an entry at the bottom of that list labeled “Yam.” Select that one and close Preferences.

There you go! Now you can have the goodness of a native Mac OS X Yammer client, message threading, and no annoyingly truncated URLs, all without sacrificing that beloved “Yam!” sound.

Enjoy!

This is a response to Mike Grace’s excellent post, Growl Notifications for Kynetx KRL Command Line Tool. The idea is entirely his; I’ve just implemented a solution for Linux. I recommend you go read his post so you know what this is all about.

Since Linux uses libnotify instead of Growl, it’s fairly simple to implement as similar solution to Mike’s on a Linux system.

You’ll need the libnotify-bin package installed. You can do that in the normal manner.

First, add the following to your ~/.bashrc file:

krl() {
  if [[ $1 == "commit" ]]; then
    command krl $@ | tee status.txt
    notify-send -i ~/.kynetx-x.png “KRL” “`cat status.txt`”
    rm status.txt
  else
    command krl $@
  fi;
}

This is basically creating a function that will run whenever you issue the “krl commit” command. It pipes the output of the KRL gem to a file and then uses the text of that file in the notification.

You can download the Kynetx “X” image to your home directory if you like with the following command:

curl https://kynetx-apps.s3.amazonaws.com/krl-commit-growl-notify/kynetx-x.png > ~/.kynetx-x.png

That’s it! Have fun!

I’ve finally come to the bottom of a vexing problem: XMLHttpRequest AJAX calls only work on the same subdomain.

In addition, cookies are passed to their proper places as you would expect, and redirects are handled correctly by the browser. But the ultimate result that the webpage making the AJAX request and the web service returning the data must be on the same subdomain is a little disappointing.

It’s possible to overcome this with JSONP or by having the web service wrap its return value in a callback function. But for security reasons, we decided that this was not the best model for our web services and are seeking other solutions.

---

If you’re interested in the technical details of how I came to these conclusions, I’ll describe them now.

Protocols and subdomains

First of all, I set up my /etc/hosts file to have localhost.byu.edu and snay2.byu.edu point back to 127.0.0.1 for testing purposes. I also set up my local Tomcat 6 to take requests both on port 8080 (for normal HTTP) and on 8443 (for HTTPS) to test the different protocols. These are the results:

• When calling from a page on the HTTP side, access to services on HTTPS is disallowed. That is, the jQuery AJAX call returns an HTTP status code of 0. Firebug reveals that the request is actually made and that a response comes back, but the browser refuses to process it.
• The reverse is also true: When calling from a page on HTTPS, access to services on HTTP is disallowed.
• AJAX calls can’t be made across subdomains. When I call from localhost.byu.edu to localhost.byu.edu the request succeeds (and returns data). But when I call from snay2.byu.edu to localhost.byu.edu (or the reverse), the HTTP status code is 0 and the browser won’t let jQuery handle the data that comes back.

The odd thing about all of this is that Firebug is showing that the requests were indeed made and that they come back with data. jQuery simply won’t invoke the callback function I gave it to use the data. If anyone knows why that is, please enlighten me.

Redirects and cookies

The other two issues that seemed to be involved in the problem (albeit indirectly) were redirects and cookies. CAS (Central Authentication Service) makes extensive use of HTTP redirects (usually a 302) to handle authentication. When initially trying to debug these web service calls, it was unclear whether the redirects simply weren’t being handled by jQuery or if there was something else going on. A few tests with PHP scripts allowed me to confirm that jQuery AJAX does indeed handle redirects properly.

The first PHP script makes an AJAX request (note that these scripts are all on the same subdomain):

test.php:

<html>
<head>
  <title>Test</title>
  <script src=”jquery.tools.customized.min.js” type=”text/javascript”></script>
  <script type=”text/javascript”>
    var callService = function() {
      var request = ‘http://www.scnay.com/coe/services/landing.php’;
      $.get(request, gotResponse);
    };

    var gotResponse = function(data) {
      alert(“Got the results!! ” + data);
    };

   </script>

</head>
<body>
  <input type=”button” onclick=”callService();” value=”Call service” />
</body>
</html>

The second one sends a redirect to the browser:

landing.php:

<?php
header(‘Location: http://www.scnay.com/coe/services/real.php’);
?>

The third script returns some data:

real.php:

<?php
echo ‘Success!’;
?>

Clicking the button from test.php sends a request to landing.php. The redirect is properly handled and the string “Success!” is returned from real.php. Redirects work!

The other issue in question was cookies. CAS stores a TGT cookie on the cas.byu.edu domain so that the user doesn’t have to re-login every time a CAS-secured request is made. The question was whether that TGT cookie was getting passed to cas.byu.edu when the request was made there, either explicitly or through a redirect.

To test this, I first modified test.php to set a cookie. Then I modified real.php to return “Success!” only if the cookie was found and otherwise to return an error message.

This simple test showed that the cookies are indeed passed along as would be expected.

---

Conclusion

While the answer is not wholly satisfying (XMLHttpRequest AJAX calls can’t be made across subdomains without using JSONP, callbacks, or proxies), at least we now know what’s going on. Now to search for a reasonable solution…

Do you have experience with this? Any suggestions I might try?

I’ve been using the Palm Pre Plus on Verizon Wireless since February this year. I really enjoy the operating system, webOS. And the hardware (once I got used to it) isn’t bad. It’s relatively lightweight, easy to hold, and overall a nice-looking device.

But the more I think about it, the more I’d rather have an Android. Here’s why.

The app paradigm

webOS is stuck in the app paradigm. So is the iPhone. Android isn’t, especially with the HTC Sense UI.

When I turn on my phone, I’m looking for information, not apps. My phone comes with me everywhere and ought to know my context. I’m not turning on my phone to open an app. I’m turning on my phone to accomplish something–to get some information from my friends, to see what my next tasks or calendar items are, to determine whether I need to bring an umbrella.

In the app paradigm, I have to open a Twitter client and read updates. Then I open a Facebook client and read updates. Then I open my calendar and look at appointments. Then I open a weather app and check the day’s forecast. All I really wanted was the information, not all the overhead of opening and closing apps, scrolling through and searching for the relevant things I wanted to know.

I don’t want to see minimized cards with some apps. I don’t want to see an array of pretty icons. The app paradigm is simply too inflexible and too siloed to provide me the information I want in the way I want it.

Hardware

Let’s be honest. As cool an operating system as webOS is, it’s confined to hardware that is all but antiquated. Small screen, slow processor, a finnicky keyboard that was only recently fixed.

Current Android devices are so much faster and more capable than current webOS devices. While rumor has it that hardware improvements are coming, I want a phone that’s up to snuff in the market today. A 500 MHz processor powering a small 3G phone can’t compete in this market anymore.

Geolocation

This is both a hardware and a software issue. Admittedly, the GPS experience on non-Verizon apps is spotty at best. It’s the unfortunate truth that the missteps of the carriers of webOS devices have tarnished its image in the location realm. Whether it’s caused by hardware limitations or carrier restrictions, the fact remains that geolocation on the Palm Pre leaves much to be desired.

Turn-by-turn navigation is only available on the Pre if you’re willing to shell out a few extra dollars a month for a subscription fee. Android phones come with turn-by-turn navigation by default at no extra charge. That, combined with the inherently better location capabilities of Android hardware, is compelling by itself.

Innovation and community

webOS has a very strong community. I have no complaints there. But the platform hasn’t garnered the attention of many developers outside that community, meaning that the app selection is extremely limited. There’s no Yammer app, for example (something that I desperately need). There are few Google apps for webOS (Maps and YouTube are the obvious exceptions).

Google is innovating incredibly fast with the Android platform. Android 2.2 brings incredible speed improvements across the board. Palm is in the middle of an acquisition by HP, so I’ll forgive them for the time being. But acquisition notwithstanding, innovation in webOS has been a slow process. Some are optimistic that innovation will improve with the better corporate backing that Palm will get from HP. I’m more inclined to run and develop for a platform that already has a proven track record of adoption and improvement.

Conclusion

Perhaps I’m being pessimistic. Perhaps I’m too easily distracted by new, shiny toys. But I’m more than likely going to make the switch to Android and devote my energies to that platform.

I still hope for the best for webOS. It is an awesome operating system with a lot of potential, but that potential has yet to be realized. Hopefully the new deal with HP will provide the necessary boost to get webOS onto its next wave of innovation.

---

UPDATE: I should note (as is duly apparent in the comments now) that I’m not yet completely sold on the idea of switching to Android. Feel free to leave your thoughts about either platform. Why should I or shouldn’t I switch?

I’ve been working with PhoneGap this week to create a simple geolocation app. It’s a framework for creating mobile applications in HTML, JavaScript, and CSS that will run on all the major platforms. You write your application and reference the APIs that PhoneGap provides. Then you simply drop your HTML and JavaScript into the various platform-specific template projects they provide and compile it with the platform’s native compiler. Simple as that.

But the devil is in the details. Every platform and device has subtle differences that make cross-platform development painful. There are even differences between how an emulator and a device run the application.

I’ve been testing on three platforms: webOS (Palm Pre Plus), Android (Motorola DROID with Android 2.1), and iPhone OS 3 (iPod Touch).

Here are a few of my frustrating findings:

Notification: alert, beep, vibrate

First off, webOS doesn’t support the alert() command at all. Android and iPhone do, in the typical fashion.

Beeping is fine on the devices themselves (the Motorola DROID even says “Droid” when you call that function). But the Android SDK emulator kills my app when I call it.

Vibration works on Android. I assume it also works on the iPhone, but I only have an iPod Touch at the moment, and it doesn’t have a vibrator in the first place. The Palm Pre won’t vibrate unless the package name begins with com.palm. Obviously for testing purposes it would be fine to label your app as coming from Palm, Inc. itself, but that won’t fly if you want to distribute the app. So no vibration on webOS. And can you guess what the iPhone simulator does with the vibrate() command? It makes the app hang. Go figure.

Moral of the story: Alert, beep, and vibrate won’t work reliably if you need to support every platform and don’t want your code to break in an emulator.

Location services

The webOS and iPhone simulators both show their location as the headquarters of their respective companies (Sunnyvale or Cupertino). The Android simulator doesn’t even provide location data, so it’s utterly useless for testing in that regard.

My Palm Pre Plus (running on Verizon) can get its location relatively accurately when I’m running it on 3G (even inside my office). Not so if I’m on the WiFi. If I get a fix at all, it’ll take a long time and may be quite inaccurate. (Note that this is the behavior I get everywhere in webOS, not just with PhoneGap.)

The iPod inexplicably thinks it’s in Lilburn, Georgia. For comparison, I’m in Provo, Utah. Only 1,927 miles off. Google Maps on the iPod gets the correct location, but not PhoneGap.

The worst of my problems, though, is the Motorola DROID. More than half the time, my app can’t find its location. It doesn’t matter whether I’m on 3G or WiFi, inside the office or out on ground level. When I compile and run the app immediately after I’ve changed something, it usually seems to get a location fix. But when I subsequently run the app (whether connected to the debugger or not), it fails to get the location. I’ve tried it on two different DROIDs and they both exhibit the same behavior. Google Maps and turn-by-turn navigation work perfectly–they find the location and track it reliably. But something between the phone’s GPS and the PhoneGap library is getting screwed up.

Device UUID

webOS and iPhone OS both return a useful UUID on the device.uuid property. However, Android (both on the emulator and on the DROID) returns simply the unhelpful “undefined.” My app needs to be able to identify users by the UUID of their device, which simply doesn’t work on the Android.

UPDATE: Android 2.2 (Froyo) returns a UUID as you would expect. Only problem is that hardly anyone has it as of now (July 2010), and a lot of older mainstream handsets won’t be getting it at all.

HTML Select boxes

This one really ought not to be a problem. But webOS won’t let you tap on an HTML select box inside a PhoneGap application. It’ll display just fine, but you can’t make a selection. Select boxes work fine on normal web pages. iPhone and Android both support the select box perfectly, including the native OS skins. No dice with PhoneGap on the Palm Pre.

EDIT: Ryan from Nitobi is working on a solution for this on webOS. You can read about it on his blog.

UPDATE: Ryan has fixed this now. See his comment below for the updated files for your project.

Conclusion

So. After wrestling with all of these issues, what have I determined?

PhoneGap is a really slick framework, and it makes it very easy to create a mobile app that is “write once, run anywhere.” But the actual implementation details get hairy, and even fundamental operations like geolocation services and vibration are not implemented uniformly across all these devices.

Caveat emptor.

---

For those interested, I’ve posted a few questions about these issues on Stack Overflow:

• vibrate() and beep() breaking in the emulators
• Dropdowns not working in webOS
• device.uuid on the Android

• The book you placed on hold last week at the BYU Library is now in for you to pick up. You receive a notification on your phone just as you enter the atrium. Want to check it out right now?
• Your favorite stand-up comedy group is doing a show right now next to the Cougareat. Your phone alerts you to such as you walk through the quad just outside the Wilk. Care to take a look?
• Your Physics 121 homework is in your backpack, all finished. Now that you’re in the MARB, your phone reminds you to run upstairs and turn it in before you forget.
• You’re still on the other side of campus and class starts in 10 minutes. Since you’re on your work computer, perhaps you’re deep in thought on a project. Don’t forget to leave in time!
• You’ve been searching Google, Wikipedia, and the Library’s website for 10 minutes with keywords all relating to Rembrandt and van Gogh. You don’t seem to have found anything satisfactory yet. There’s an art history subject librarian online right now. (She even has a specialty in Dutch painters.) Maybe she can help you break this mental block–care to chat?

---

Location-aware context automation is an extremely powerful and relevant concept. The possibilities are endless.

How do we make this a reality on a college campus?

BYU could use information I supply about my intent to give me relevant, useful information (call it advertising if you must): books I want to read, my favorite groups, academic interests, homework reminders, etc.

Such location-aware context automation is currently a hot topic at Kynetx, industry leader in pioneering the purpose-based, context-aware web of the future.

Kynetx provides the platform to enable the kind of context-aware applications I mentioned earlier.

What if BYU’s network routers were Kynetx endpoints? Then my smartphone (also acting as a Kynetx endpoint, probably through an app) could detect when I’m in range of one of these wireless access points. It can also trivially determine which building or perhaps even which classroom I’m in. That takes care of the location part of the context puzzle.

What if my laptop were a Kynetx endpoint that knew what building I was in and what I was working on–where I’m browsing the web, whether I’m online on my chat client, etc.?

Other data can be used to determine the intent part of my context–books of my Amazon.com wish list, books I’ve checked out or reserved at the library (both currently and in the past), classes in which I’m enrolled, clubs of which I’m a member, homework assignments that are due soon. Insert your favorite piece of data here. You get the idea.

Given that information, BYU could provide me contextually relevant information to make me more productive at my current location or the current time of day. That context automation could stretch across my web browser, my computer, or my smartphone.

That opens the doors for some really powerful applications that aren’t currently possible with the web as we know it.

What ideas do you have?