unwiredben

I took a few hours today to get back to an old open-source project of mine, the Webduino HTTP server library. Since I last touched it about 18 months ago, a few developers have forked it over on GitHub and even done some pretty cool projects. Martin Lormes has been writing at about his changes, including favicon.ico support to keep browsers from making extra requests and supporting HTTP basic authentication. I also saw a Christmas tree that had its lights controlled by a Webduino-powered form.

I've got my own fork going over at GitHub too now, and just checked in a bunch of small fixes that I'd been saving up. I've not had a chance to do tests yet, as I've got to dig up some of my hardware from where I left it after my September trip to New York City.

I just deleted all the "My Tweets" posts from this LJ account. I thought it would be useful, but it ended up just annoying me, especially since they still hadn't fixed the bug where the text around the tweets was Russian instead of English. However, now that we're working on releasing webOS as an open source project, I do plan on writing a bit more here about what's going on. I'm also working on a big revamp of my personal website that I'll publicize when ready.

In my job here at HP, I often need to reproduce bugs in our webOS browser or test out little web services. There are two tools I'm using more and more for these little ad-hoc tasks.

First is Dropbox. I've been using Dropbox for a few years now to sync files between my various computers, and it works great for that. What I've been playing with a lot lately is the Public folder. Anything you put in that folder becomes available to other users or devices via a easily copied URL. You can use that URL both as HTTP and HTTPS, and it seems to support a wide range of content types without problem.

My best practice is to put things in subfolders of public with not-easily guessable names. All the URLs for public items look like http://dl.dropbox.com/u//, so while you can't get an index and see all the public items someone has up, putting everything into the root folder means that its easier for people to guess the URLs for items that you might have up.

To make it easier to get to those URLs on my devices, I tend to use bit.ly (or it's shorter version, j.mp) to turn the long URL into a short opaque identifier.

A second useful tool is one I just started using last week: http://jsapp.us. I think of this as an equivalent to our own Ares tool, but for node.js server apps. You get a Bespin-based code editor, some file storage, and an easy way to run your node code on their services. You wouldn't want to make giant systems with this, but it's great for writing a 20 line script to test out HTTP error code generation or user authentication methods.

A final tool that I find myself using almost every day is our own Ares Debugger. If you're doing anything webOS and haven't tried it, please go to http://ares.palm.com/AresDebug and try it out. It will suck the JavaScript right off the device or emulator, let you set breakpoints, single step, and inspect variables.

Tags: technology, tools, webos

I get to try a lot of webOS applications as part of my job in developer relations. Sometimes they are beta apps that a developer has sent to me to review. Sometimes they're released apps that I'm using to validate new OS releases or hardware. Sometimes they're just fun apps that I use for my own productivity and enjoyment. Here's five that I always try to reinstall after flashing a device for day-to-day use:

Foursquare - Every week or so, I get really addicted to checking into places for a few days. Zhephree's app works very, very well for this task. It makes me wish that our GPS system would work better, since most of my wait time is for the fix. The user interface is very slick.

neato! - Another Zhephree app that's great. I don't always leave this running, but when I need to do some web site debugging, it's very useful. It lets me click on a bookmarklet in my browser and have the page almost instantly show up on my device. It also can be used to send selected text and bring up app pages.

Tweed - It may not be the most stylish Twitter client on webOS, but it's been very stable and nicely maintained, and it serves me well. I don't use the notification feature, as I tend to view Twitter as a pool of data that I can dip into from time to time rather than a email inbox.

drPodder - I like listening to podcasts, but I hate having to manage a desktop client to find and download them. This app does all that for me on the device. The interface is for the power user, but I love the way it uses system notifications to let you pause and resume your track. I just wish I could manage my feed list on the web somewhere -- it would be awesome if you could use the Dropbox API to store your drpodder.xml OPML file online.

SplashID - I was a long-time SplashID user on Palm OS, and I really liked that you could export your records from the desktop to the device. SplashData hasn't done a good job of updating this (where is sync!), but I still always load this up. If I can find a good cloud sync solution that's supported on webOS, I might switch to it.

TMaps - NY - if you navigate around NY, you need a good subway map. You especially need one that works when you're out-of-service. TMaps fits those needs well. I'd really love to see a port of the iPhone's Exit Strategy app which includes street-level apps and advice on where exits are in subway stations, but this will do.

I'm giving myself a bonus selection with Google Reader. I've tried a few of the client apps that use the API to access my Reader feeds, but I keep coming back to Google's mobile website for the best experience. I like that you're instantly synced with Google's own database of read/unread articles, and I like the "open drawer" method of moving quickly through a lot of news items. This isn't a true app, but I usually use the Browser's "Page / Add to Launcher" command to make an icon for it.

We just launched the PDK Hot Apps leaderboard; while looking at the growing list of free apps that will pick up a bonus, I had some ideas for some apps that won't take a lot of time to write but could be useful.

One is a sign generator. The SDL library lets you use Truetype fonts that you bundle with your app to draw to the screen. Take some interesting fonts, add some glow effects, and you can make a nice app for people to make messages that can be seen across a room. A "party sign" app was one of the big winners in the original Hot Apps promotion, so it would be natural to one-up that with the PDK.

Another idea is a nice 3D world time app. Show a nice 3D globe based on the current time with accurate sun charts, maybe allow touches on the screen to rotate the globe with a button to recenter it on the current GPS location.

A third idea is make a OpenGL ES-based photo viewer with some nice zoom and pan effects, aka Ken Burns mode. You can build your own copy of libcurl to do HTTP fetching of images, and grab from different Flickr tagged feeds. The UI might be a little tricky, but you can do a lot with just specializing in your own topics and maybe allowing the user to customize by editing a file read from /media/internal.

Finally, there's plenty of fun to be had by porting some of the existing SDL demos and games that are listed at http://www.libsdl.org. We fully support posting open source software in the catalog, just be sure to use a open source developer account and follow the license. That might mean adding information to your catalog description on how to get the source and build it yourself and adding notice to the user about the license terms.

This post is about esoteric dynamic linking issues on Linux... feel free to skip it if you're not a programmer.

( Read more... )

I really like JSON.  It's easy to write, easy to parse, and more compact than XML, and it works great as a way to pass around method parameters and return values.  However, it has a big flaw -- there is no way to write a comment in a JSON file.  The // and /* */ syntax used by JavaScript isn't supported, so many JSON parsers will reject files that have them.

Every application on Palm webOS comes with an appinfo.json file that describes key information like it's title, where it's icon lives, and it's application ID.  For some samples I'm doing, I'd like to write some comments in appinfo.json so people know where to change the values for their application.  However, I spotted a way out.  Deep in our documentation, we note that this file can contain other JSON attributes beyond what we specify.  So, I realized that no one has to use those elements, and if you name them something ridiculous like "// c1", they're unlikely to ever conflict with an application's use.  So now, I can write things like

{
   "// c1": "The next attribute, id, defines the permanent ID for your program. Change it!",
   "id" : "com.palmdts.example",
   ...
}

without invoking the wrath of the JSON parsers.

So, I had a bunch of fellow developer relations people basically jump me this morning, say they like what I've been posting, but that it really should go on the official Palm developer blog.  I'm cool with that, so effectively immediately, I'll be moving my Palm webOS-related posts over to http://developer.palm.com/blog.  I'm going to be reposting the first part of my series there, and we're getting the FAQ that I posted in part 2 turned into official Plug-In Development Kit documentation.  The true second part, the one that actually comes with code, should go up on Thursday -- I've been really busy this week with a secret project that you all should learn about soon. :)

Before I jump into my sample code, there are some frequently asked questions about the current 1st beta of the Palm webOS Plugin Development Kit (PDK) that I wanted to collect here.

Note: this FAQ is about the first release of the PDK.  This is not the final version of things that will ship on device.

(Update 1: clarified camera and microphone access to indicate that you can mix Mojo and PDK to get access to images)

(Update 2: this FAQ is now an official Technical FAQ and hosted at developer.palm.com.  Go there for the up-to-date version.)

( Read more... )

So, I'm finishing my fourth week with the webOS developer relations team.  It's been a really fun and busy ride,  I've been asserting my presence on the developer forums and many questions have been answered.

However, I really need to be writing and making sample code.  This will help avoid questions and help a lot of people.  I'm going to be doing both of those here, with the final product getting polished and put up on the Palm Developer Site eventually.  Consider these posts a working draft.

Our Plugin Development Kit (PDK from here onward) is a set of tools and libraries for making native applications on webOS.  Most apps now are written like websites; they have HTML, JavaScript, CSS, and images, and they run inside the special version of WebKit we call LunaSysManager.  Native apps, in contrast, are actual compiled code.  They're originally written in C or C++, compiled down to ARM machine language, and run directly on the device.  WebKit is still there, but it mostly stays out of the way and just gives the PDK app a window to draw in.

We've got three APIs that are used for PDK apps.  The first is SDL (Simple Directmedia Library).  Our current release is based on SDL 1.2.  This API gives you drawing surfaces, 2D primitives, image loading, fonts, events, timers, network access, accelerometer (via joystick APIs), touch screen (via mouse APIs).  It's well described at the libsdl.org website.

The second API is PDL (Palm Direct Library, perhaps?).  This gives access to some system services like screen orientation, the location system and the device ID number.  It also has calls that allow your plugin to register methods that can be called from JavaScript.  The reference for this is online.

The final API is Open GL ES.  We support both version 1.1 and 2.0, although not both in the same program.  Open GL ES 1.1 has a fixed-function pipeline and works well for a lot of 2D and 3D applications, while ES 2.0 uses a programmable shader system which is more complicated for simple programs, but very powerful in its ability to shift vertex transformation and shading into the GPU.  I'm still learning the Open GL way, but I hope to blog about my experience getting some GL ES 2.0 sample code running on the device.

Next time, we explore some basic SDL-based sample code.