HP webOS Developer Blog

There comes a time in a Linux-loving geek’s life when he or she needs a new challenge. Making desktop apps isn’t hacking it anymore and building yet-another-website seems passe.  If you want to jump into the world of mobile, here are a few reasons why HP webOS is the platform for you.

#1: It’s free.

There’s no cost to become a developer.  You don’t have to pay any sort of fee to download the SDK or submit apps. The webOS emulator is free and our tools support development on Windows, Mac OS X, and Linux. We also have discount programs to help developers to get their hands on real devices.

#2: We give you full access to your device.

You don’t have to jailbreak or root your device.What other platforms call jailbreaking or rooting, we call entering developer mode.  We don’t make you jump through hoops, purchase device certificates.  or use questionable tools; instead, we provide simple shortcuts from our launcher and phone apps.  Just tap on the “Just Type” search bar and enter “upupdowndownleftrightleftrightbastart” (the classic NES Konami code!); an icon appears that lets you toggle this mode on and off. In developer mode, you can get full access to the device over your USB cable.

Read more ‣

The last couple of months have been a busy time of travel for me, Ben Combee, and the HP Palm Developer Relations team.

Our tour started in mid-September with web 2.0 Expo in New York City.  Our former directors, Ben Galbraith and Dion Almaer were on a panel on the future of web browser, while HP Palm had a presence on the vendor floor where Kevin Hague, Lisa Brewster, and I talked about our system and phones, the Mojo JavaScript framework, and the Ares web-based development environment to attendees during breaks.

While everyone was in NY, we were able to take a break from the Expo and head over the Brooklyn Bridge to attend the NY JavaScript Meetup.  Ben & Dion did a version of their “Why the Web Will Win” talk while everyone enjoyed food and drinks at the reBar gastropub.  It was a great opportunity to meet with several webOS developers already in the area and expose our ideas and platform to some of the brightest members of New York’s technology crowd.

Our next event was in early October in beautiful Austin, Texas with Game Developer Conference Online. I attended as part of their iPhone/iPad Gaming Summit to be on a panel on Alternative Mobile Platforms.  I was on stage with representatives from Aurora Feint (who recently launched support for Android), Sony, Microsoft, and Cydia (the app store for jailbroken iOS devices).  I emphasized how many iOS developers have been able to quickly port over applications from Apple’s mobile OS to our system using the PDK’s support for OpenGL ES and I stressed how the Palm App Catalog provides a great way to gain access to a growing user base.

October finished with the first Mobile Apps World conference in London, England.  This was an event gathering application developers with brand managers, media buyers, and corporate executives, and HP Palm was there as a gold sponsor.  I gave a keynote address on the advantages of using HTML and JavaScript to build applications for a wide range of devices, and then followed up with an afternoon of hands-on sessions where I took developers through building an app using PhoneGap for both HP webOS and Google’s Android operating system. Look for a screencast soon with this material.

While in London, I also took the opportunity to visit with some of our London partners, including Quickoffice, who’ve done a great job building a first-class hybrid document viewer app that we’re including in webOS 2.0, and Ideaworks Labs, the creators of the Airplay SDK that allows building cross-platform C/C++ apps for webOS and many other systems.

Our next big event is the HP webOS Developer Day in New York City.  If you can get up to New York on November 19th and 20th, it will be time well spent.  We’re going to be going deep into some of the new features of webOS 2.0 while also featuring many of the cross platform technologies that can make you successful as a mobile developer and expose your apps to a huge audience of users.

It feels like it was only five months ago that we published part 2 of this series.  Sorry for the long wait!

This time, we’re taking our BadFont sample and going in two directions.  First, we’ll add some TrueType font display code using the SDL_TTF library.  Second, we’ll talk about packaging up your PDK app for installing on the device and submitting it to the Palm webOS App Catalog.  As a bonus, we’ll also provide a makefile you can use on Windows for all of this.

Here’s what it will look like when we’re done:

Read more ‣

When you build a C/C++-based application using the PDK for our webOS devices, you’re effectively doing embedded development. Here are some tips and hints for how you can get data back off the device to see what’s going on.

Getting a Device Shell

PDK developers usually need to get deeper access to their devices than developers using the JavaScript SDK. To facilitate that, we provide a pdk-device-install script in the SDK. This installs an SSH daemon on the device that listens to network connections coming over the USB cable. A tcprelay service installed on your desktop system redirects traffic from your localhost to the device. The usual way to shell into the device is:

1. If you’ve just updated your OS, or you haven’t installed SSH before, run pdk-device-install install, then wait for the device to reboot.
2. If you’re using Windows: putty -P 10022 root@localhost
3. If you’re using Mac OS X: ssh -p 10022 root@localhost

An alternative way to get a shell is available if you’re on Mac OS X. One of the utilities that comes with the SDK on OS X is novaterm. This uses the native novacom protocol to open a shell to the device. Unfortunately, novaterm isn’t available on Windows as part of the SDK, so you’ll need to use SSH/PuTTY there.

Once you have a shell on the device, you have most of the common Linux shell commands available, like cd, cat, ls, cp, du, less, more, and vi. (The vi implementation on device is a version from Busybox, so many of the advanced commands don’t work.)
Read more ‣

You may not realize it, but if you have the webOS SDK installed on your system, you’ve got the source for the Mojo framework there right on your machine available for reading. On Windows, we install it in the “share/refcode/webos-framework” folder under the location where the SDK lives (usually c:\Program Files\Palm\SDK), next to the code samples and webOS application source. On Mac, it’s in /opt/PalmSDK/share/refcode/framework.

In this folder, you’ll first find another folder with a number. In the 1.4.5 SDK, that’s 337, and it matches an internal “submission” number we use to control what version of the framework ships on the device. In that folder, most of the actual source code is in the “javascripts” folder, but the version of Prototype we use is in the “builtins” folder. The “templates” folder holds HTML template files used in building the widgets in the system, “stylesheets” holds the CSS files used by the system, and “resources” and “formats” have JSON that’s used to handle our various locales.

Reading the framework source can be a bit daunting, but it’s been invaluable for me in understanding how Mojo works. It also can be a great place to look to see how parameters that you pass into calls are actually used and how the various JavaScript objects are put together. Some of the classes, like Mojo.Controller.SceneController, have some useful properties (e.g. sceneName, stageController and window) that are used in our sample code but are currently missing from our documentation — we’re working on filling these gaps now. (However, don’t rely on any properties or methods that start with an underscore, as that’s a signal that the data is for internal-use-only.) There are some useful comments, but as with a lot of code, the comments sometimes have aged more than the code they describe, so reading the code is essential for knowing things like when you can omit an argument.

So, I encourage you to dive in and explore the framework source, along with the source for many of our Palm apps, which you’ll also find installed with the SDK. A quick note on licensing: use of the framework and app source code is governed by the terms of the SDK license agreement, which is permissive but not open-source. You’re free to explore the code, learn from it, and even reuse it, as long as you’re working on webOS applications—the license currently does not allow use outside of webOS.

(Note: this checklist is now official documentation!  See it with updates on the Palm Developer Center.)

With the PDK Hot Apps promotion starting in the near future, a lot of developers want to submit their C/C++ applications to our catalog. Here are a couple of things to check first to make sure your app doesn’t get rejected.

First, lets look at your application package and executable:

1. Is the app a full-screen app? We’re not accepting hybrid apps (ones that use both JavaScript and PDK code) into the catalog at this time.
2. Does your appinfo.json specify ‘type: “pdk”‘? Earlier examples used the ‘game’ type in the appinfo.json, but we changed that late in the 1.4.5 development cycle so we could better differentiate between apps that were put into the catalog early versus ones from the open submission process.
3. Did you strip the executable? We require that executable files submitted for PDK apps have their debugging information removed. This is normally done by either using the -s option for the compiler or by using the arm-none-linux-gnueabi-strip tool.
4. Did you include a “requiredMemory” line in your appinfo.json file? This is needed to tell the system manager how much memory your app is expected to use, as it helps us keep multitasking working well. One way to determine this number is to open a shell on the device while your app is running and use the “top” command to see its memory use.  If you’re supporting both the Palm Pre and Pixi, be sure to test the memory usage on both devices.
5. Did you build with the 1.4.5 SDK? We changed some API names between our PDK beta and the released version with the 1.4.5 SDK, so make sure you use the latest files to build your application.
6. Did you use only whitelisted libraries?  At this time, we’re only allowing applications in the catalog that use the set of libraries we provide with the PDK.  This list includes the standard C and C++ libraries, SDL (including SDL_image, SDL_net, SDL_mixer, and SDL_ttf), and OpenGL ES (1.1 or 2.0).  If you need other libraries, you should build them yourself and statically link them with your application.
7. Did you use the correct processor architecture arguments?  If you’re building to run on the Pixi, you should use “-mcpu=arm1136jf-s -mfpu=vfp”.  If your application will only run on the Pre, you can use the “-mcpu=cortex-a8 -mfpu=neon” switches to take advantage of the new instructions that are only available in the ARM Cortex-A8 processor on the Pre.

Now, let’s look at the actual submission process:

1. Be sure to you properly specify the devices your app runs on.  If you’re submitting a SDL graphics-based app, make sure you only specify the Palm Pre for your PDK app, as SDL-graphics-based apps don’t update the screen properly on the Palm Pixi device. If you did an OpenGL app, you should test on both devices before submitting. If you need to do separate builds for Pre and Pixi, that’s OK; we suggest you give your Pre version your main package ID, and add a “-pixi” suffix for your Pixi version.
2. Be sure to specify webOS 1.4.5 as your minimum OS version.  If you specify an earlier version, the PDK app will be rejected on upload.

Following these rules will keep your app from being rejected by our automated security scanners.  Of course, if the app is going into the catalog, it will still need to pass our friendly app review team.  However, you have to get by the scanner before they can look at it.

For more information on packaging PDK apps, see our helpful article in the PDK guide.  If you have questions, please feel free to ask them in our C/C++ Development with the webOS PDK development forum.

If you’re not an active participant in our developer forums, you may have missed some of the best conversations. Here’s some that are worth your attention.

There’s a long running thread on our ongoing promotion at “Hot Apps Leaderboard”. Most recently, developers have been excited about API access to the Hot Apps data, and Palm’s Josh Marinacci has been building web service endpoints that enable websites and apps like “Leaderboard” and “My webOS Apps” to show that data on our devices.

People are getting deep into work with the Plug-In Development Kit, and some of Palm’s engineers have been showing up on threads to chime in. ChrisT provided details about how the system shows applications when they’re rotated, while cwiebe showed how to have multiple executable files in a package using package.properties, and I joined in on a thread about how to poll for multitouch events when you’re not using a standard SDL “wait-for-event”.

In the Mojo development world, people have been asking questions about database performance: Depot vs. SQLite vs. CRUD storage: Better performance? focuses on what API to use, while the discussion at Feature Request: SQLite BEGIN & COMMIT to increase speed turned into an explanation of how HTML5 database transactions already allow going full-speed with SQLite storage.

Back in January, Palm started using GitHub as a repository for sample code and other open-source projects. We’ve got several different trees hosted there, including our collection of webos-samples, Frank W. Zammetti’s game Far Out Fowl, and the RSS reader sample app from the O’Reilly book “Palm webOS” called News.

We’re now proud to add a new tree to our forest… please give a big welcome to pdk-samples.  This collection shows off our Plug-In Development Kit that’s used to turn your C and C++ code into programs for webOS.

We are starting with two chunks of code.  The first is “simple” which you might recognize from the current PDK installer.  It shows a rotating shape using OpenGL ES, it’s a nice piece of bling for your phone that won’t cost you $999.

The second and more extensive sample is called “shapespin”.  It seems similar to “simple” at first glance, then you realize that it’s mixing Mojo-based JavaScript code with PDK-based OpenGL goodness in a way reminiscent of those peanut butter-and-chocolate cups.  Not only can you adjust the rotation using a Mojo slider control, but you also can freeze its movement just by minimizing the application to a card.  Lots of people have been asking for more help with hybrid apps, and here an example to get started.

This is going to be a pretty long post, so I’m hiding most of it from the main page.  However, I want to get people to click on the article, so here’s the pretty picture that we’re using for our fake game studio logo, created using my elite Inkscape skills.

What’s our goal with part 2?  By the end of this post, you’ll have a PDK application that shows a picture then waits for the user to quit.  In theory, this will give the user something to look at while we process all the data needed for our super hot game.

Oh, and one last thing “before the cut”.  I apologize to our PDK developers using Mac OS X or Linux.  I’m doing my development using Windows and haven’t been able to test on the other platforms.  It should be simple to follow along, and I encourage you to post corrections and tips in the comments.

Read more ‣

Hello, I’m Ben Combee, one of the newest members of Palm’s crack Developer Relations team.  If my name sounds familiar, it should — I’ve been around the Palm world for a while, first as an independent developer, then as the lead on the CodeWarrior developer tools, then in previous stints with PalmSource and Palm.

In this series of posts on the developer blog, I’m going to look at our new Plug-In Development Kit (PDK from here onward).  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. PDK-based apps, in contrast, are originally written in C or C++, compiled down to ARM machine language, and run directly on the processor of the device. WebKit is still there, but it mostly stays out of the way and just gives the PDK application 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.

In part two, we’ll start building a SDL-based full-screen application with some code to implement the most important part of a good game, the studio logo that shows up on startup.