After taking a day off on Thursday the App Catalog was back and running with fresh new apps yesterday. Sadly, the collection of newness wasn’t that big, but even with only eight new apps there’s still some stuff worth pointing out.
There are a few other apps, plus a collection of updated ones, waiting past the break.
After taking a day off on Thursday the App Catalog was back and running with fresh new apps yesterday. Sadly, the collection of newness wasn’t that big, but even with only eight new apps there’s still some stuff worth pointing out.
There are a few other apps, plus a collection of updated ones, waiting past the break.
We've waited, we've asked, PreCentral forum members have lobbied, and now we're officially being rejected: DataViz announced today on its Facebook page that it "made the difficult decision to cancel development for Docs To Go for WebOS":
We regret to announce that we have made the difficult decision to not produce a Web OS version of Documents To Go. We understand that our delay in this area has caused much disappointment to our current and very loyal user base. We would like to explain in more detail the reasoning behind our decisions thus far.
Our intention had been to replace the Palm Viewers, which were based on the Documents To Go technology, with a full editing, aftermarket version of Documents To Go. In order to do this in a way that we felt would be most intuitive to users, we wanted to have the full version seamlessly replace the built in viewers. To do this, we needed some technical help from Palm. Because Palm was focusing on other areas at the time (including their very survival), and there was no official information available allowing developers to help ourselves, i.e., an SDK, there was a delay in getting us this information. Rather than do a substantially larger project that would result in a "sub-optimal" user experience, we decided to wait. This wait was much longer than anyone at DataViz expected. During this wait, we focused our efforts on other smartphone platforms, not because we were not loyal to Palm, but because it made "business sense" to do so. We have now come to the realization that it is not in DataViz' nor our users' best interests to continue the wait and produce the full version. We understand that another developer has chosen to create an editing Office product for webOS and we wish them the best. Again, we apologize to our users for taking this long to reach, what is for DataViz and many of our users, a disappointing conclusion.
This decision is both disappointing and irritating for many within the webOS community, especially those who have been loyal Dataviz customers since the original Docs To Go came out for Palm OS. Its rationale is also a bit suspect, given the ready availability of Palm's PDK for months, as well as the fact that the HP acquisition closed more than two months ago, with many, many PDK-based apps being developed and released, some quite sophisticated, since then.
Here's hoping that we get an editing solution in short order, possibly from "another developer" with the interest in webOS users' business that DataViz apparently lacks.
Source: DataViz; Thanks to BruceBradford in our forums for the heads-up!
UPDATE: Oh, well that might explain it. DataViz has been bought by BlackBerry maker Research in Motion for a cool $50 million. So it's not just webOS that's about to be left out of the loop; we wouldn't be surprised to see all non-BlackBerry OS DataViz products discontinued or left to waste away in the land of no updates. Read all about it over at CrackBerry.com.
We've waited, we've asked, PreCentral forum members have lobbied, and now we're officially being rejected: DataViz announced today on its Facebook page that it "made the difficult decision to cancel development for Docs To Go for WebOS":
We regret to announce that we have made the difficult decision to not produce a Web OS version of Documents To Go. We understand that our delay in this area has caused much disappointment to our current and very loyal user base. We would like to explain in more detail the reasoning behind our decisions thus far.
Our intention had been to replace the Palm Viewers, which were based on the Documents To Go technology, with a full editing, aftermarket version of Documents To Go. In order to do this in a way that we felt would be most intuitive to users, we wanted to have the full version seamlessly replace the built in viewers. To do this, we needed some technical help from Palm. Because Palm was focusing on other areas at the time (including their very survival), and there was no official information available allowing developers to help ourselves, i.e., an SDK, there was a delay in getting us this information. Rather than do a substantially larger project that would result in a "sub-optimal" user experience, we decided to wait. This wait was much longer than anyone at DataViz expected. During this wait, we focused our efforts on other smartphone platforms, not because we were not loyal to Palm, but because it made "business sense" to do so. We have now come to the realization that it is not in DataViz' nor our users' best interests to continue the wait and produce the full version. We understand that another developer has chosen to create an editing Office product for webOS and we wish them the best. Again, we apologize to our users for taking this long to reach, what is for DataViz and many of our users, a disappointing conclusion.
This decision is both disappointing and irritating for many within the webOS community, especially those who have been loyal Dataviz customers since the original Docs To Go came out for Palm OS. Its rationale is also a bit suspect, given the ready availability of Palm's PDK for months, as well as the fact that the HP acquisition closed more than two months ago, with many, many PDK-based apps being developed and released, some quite sophisticated, since then.
Here's hoping that we get an editing solution in short order, possibly from "another developer" with the interest in webOS users' business that DataViz apparently lacks.
Source: DataViz; Thanks to BruceBradford in our forums for the heads-up!
UPDATE: Oh, well that might explain it. DataViz has been bought by BlackBerry maker Research in Motion for a cool $50 million. So it's not just webOS that's about to be left out of the loop; we wouldn't be surprised to see all non-BlackBerry OS DataViz products discontinued or left to waste away in the land of no updates. Read all about it over at CrackBerry.com.
Actor, thespian, and all-around coolest man on the planet William Shatner has been a Pre user for a while now, and like the coolest man on the planet that he is he’s not afraid to show it off. He did so while taping an informal segment for The New York Times’ online Screen Test series, answering a call from his daughter Melanie. We have to say, we’re both fascinated and disappointed that The Shat uses the stock webOS ringtone, though we can understand that he wouldn’t want to use something so obvious as the Star Trek theme or a communicator chirp. Check out the video after the break.
Source: New York Times; Via: Eitan Konigsburg on Twitter
Actor, thespian, and all-around coolest man on the planet William Shatner has been a Pre user for a while now, and like the coolest man on the planet that he is he’s not afraid to show it off. He did so while taping an informal segment for The New York Times’ online Screen Test series, answering a call from his daughter Melanie. We have to say, we’re both fascinated and disappointed that The Shat uses the stock webOS ringtone, though we can understand that he wouldn’t want to use something so obvious as the Star Trek theme or a communicator chirp. Check out the video after the break.
Source: New York Times; Via: Eitan Konigsburg on Twitter
When you build an application for a mobile device you usually build it using the SDK specifically for that platform. This gives you a completely native look and feel, as well as full access to features specific to that device or operating system. Sometimes, however, you don’t need full device access. Sometimes you might want code at a very high level using just web standards and be able to run the application on multiple OSes. This is similar to coding a mobile website, except that as an local application your app can launch faster, work offline, and have access to local resources.
PhoneGap is an open source, cross platform tool for writing code once that runs on multiple mobile platforms using just HTML, JavaScript, and CSS. It is not a full OS toolkit and does not provide GUI widgets or high level features. It’s simply a common API and set of build tools that give you have uniform access to the browser and device services.
This is part one of a series on using PhoneGap to build apps for webOS and other mobile operating systems like iPhone and Android. In this first part we will build a simple webOS app using PhoneGap and HTML Canvas; no webOS specific APIs. In future parts of the series we will port this same application to Android and iPhone.
Note: this tutorial assumes you have already downloaded the Palm webOS SDK for free from developer.palm.com. See this article for full instructions.
Setting up PhoneGapGo to www.phonegap.com, click ‘download phone gap‘, to get the latest release (0.9.1 at the time of this writing).
You will get a zip file containing a bunch of directories, one for each platform. Put this in a safe place. You will use it as the clean base for all of your apps.
Make a copy of the phonegap-palm directory and rename it for your app. For this blog I’m going to make an app called stars.
From the command line, go into the stars directory and run make clean; make. If you have the emulator open or your webOS device attached via USB then it will successfully build, package, and launch the app. Congrats, you’ve built a phonegap app that perfectly does nothing. Now let’s make it useful by drawing a bunch of stars.
The actual app is in framework/www/ directory. Open up framework/www/index.html in your favorite text editor. This is the core of your app.
Put the following code in the header right below the phonegap.js line
<!-- include our own javascript --> <script src="Starfield.js" type="text/javascript"></script> <!-- include our own style for this page --> <style type="text/css"> body.palm-default { background-color : #000000; color: white; } h2, h3 { text-align: center; margin: 3px;} h3 { font-size: 75% } </style>this will set a few styles and include the starfield.js file where the actual code is.
In the body element put this:
<div id="myapp"> <h2>Star Field</h2> <h3>tap to start</h3> <canvas id="svgCanvas" width="320" height="320" onclick="starfieldStart()"></canvas> </div>This creates a header and a canvas ready for us to draw into. When you click on the canvas it will call starfieldStart(), which begins
the star simulator. Now let’s put in some real code.
Paste this into a file called Starfield.js
var ctx;var width = 320; var height = 320; var partx; var party; var partdx; var partdy; var PARTS=100; var count=0; var ramp=1; var intervalId; function circle(x,y,r) { ctx.beginPath(); ctx.arc(x, y, r, 0, Math.PI*2, true); ctx.closePath(); ctx.fill(); }; function draw() { ctx.clearStyle = "#000000"; ctx.clearRect(0,0,width,height); ctx.fillStyle = "#000000"; ctx.fillRect(0,0,width,height); ctx.fillStyle = "#FFFFFF"; for(i=0;i<ramp;i++) { circle(partx[i],party[i],2); partx[i] += partdx[i]; party[i] += partdy[i]; if(partx[i] > width || partx[i]<0) { partx[i] = width/2; party[i] = height/2; } } count++; if(count > 500) { ramp--; if(ramp < 1) ramp = 0; } else { ramp++; if(ramp > PARTS) ramp = PARTS; } if(count > 600) { clearInterval(intervalId); } }; function starfieldStart() { count = 0; ramp = 1; ctx = document.getElementById("svgCanvas").getContext("2d"); partx = new Array(PARTS); party = new Array(PARTS); partdx = new Array(PARTS); partdy = new Array(PARTS); for(i=0;i<PARTS;i++) { partx[i] = width/2; party[i] = height/2; partdx[i] = Math.random()*5-5/2; partdy[i] = Math.random()*5-5/2; } intervalId = setInterval(draw, 10); };run ‘make’ and you’ll the app start. click in the middle to start the stars. after a few seconds (technically 600 iterations of the loop) it will end, but you can click to start it again.
That’s all there is to creating an app with phonegap. Of course, we want to create the best possible experience for our users, so there’s a few things we need to fix. Let’s see if we can make it launch faster and give it a proper name.
Launch FasterMojo is the standard Javascript framework that most webOS apps are built with. However, if you aren’t using any features within it then it’s just costing you startup time. You can actually get rid of Mojo by just commenting out the script tag at the top of your index.html page.
<!-- <script language="javascript" type="text/javascript" src="/usr/palm/frameworks/mojo/mojo.js" x-mojo-version="1"></script> -->Mojo does one thing that we need however. It tells the window manager when we the app is fully loaded and ready to go. We can do this manually with a simple onLoad event handler. Add the following script to the head of the index.html page
<script language="javascript" type="text/javascript" charset="utf-8"> function onLoad() { if (window.PalmSystem) { window.PalmSystem.stageReady(); } } </script>then add a call in the body’s onload event.
<body onload="onLoad()">That’s it. Now the app will load without Mojo and start up very quickly.
A Better NameNow lets give it a proper name. Edit the appinfo.json file and change the id, version, vendor, and title to something more appropriate.:
{ "id": "com.palmdts.phonegap.stars", "version": "0.0.1", "vendor": "Josh Marinacci", "type": "web", "main": "index.html", "title": "Stars", "icon": "icon.png" }If you change the id or version fields above (which you should) then you’ll need to edit the deploy and run targets in the Makefile as well.
A New IconNow we can replace icon.png with a new image. Here’s the one I whipped up in Photoshop.
You may need to delete the app from your phone and reinstall it for webOS to pick up the new name and icon.
DebuggingIf you are having any trouble with your app code you can debug it using two methods. First, most of your code should run perfectly in a modern desktop browser like FireFox or Chrome. Start developing your app in the browser first, and port it to PhoneGap only after the core functionality works. This will give you access to the great debugging tools built into these browsers.
Second, once you have your app running on webOS you can watch the debugging log on the device using the palm-log command.
palm-log -f com.palmdts.phonegap.starsThis will start watching the log so you can see JavaScript errors and your debugging output to the console.
ConclusionNow we’ve done it: a cross platform canvas app for webOS using PhoneGap. In the next part of this series I’ll show you how to set up the android SDK and run this exact same app on Android with almost no code changes.
When you build an application for a mobile device you usually build it using the SDK specifically for that platform. This gives you a completely native look and feel, as well as full access to features specific to that device or operating system. Sometimes, however, you don’t need full device access. Sometimes you might want code at a very high level using just web standards and be able to run the application on multiple OSes. This is similar to coding a mobile website, except that as an local application your app can launch faster, work offline, and have access to local resources.
PhoneGap is an open source, cross platform tool for writing code once that runs on multiple mobile platforms using just HTML, JavaScript, and CSS. It is not a full OS toolkit and does not provide GUI widgets or high level features. It’s simply a common API and set of build tools that give you have uniform access to the browser and device services.
This is part one of a series on using PhoneGap to build apps for webOS and other mobile operating systems like iPhone and Android. In this first part we will build a simple webOS app using PhoneGap and HTML Canvas; no webOS specific APIs. In future parts of the series we will port this same application to Android and iPhone.
Note: this tutorial assumes you have already downloaded the Palm webOS SDK for free from developer.palm.com. See this article for full instructions.
Setting up PhoneGapGo to www.phonegap.com, click ‘download phone gap‘, to get the latest release (0.9.1 at the time of this writing).
You will get a zip file containing a bunch of directories, one for each platform. Put this in a safe place. You will use it as the clean base for all of your apps.
Make a copy of the phonegap-palm directory and rename it for your app. For this blog I’m going to make an app called stars.
From the command line, go into the stars directory and run make clean; make. If you have the emulator open or your webOS device attached via USB then it will successfully build, package, and launch the app. Congrats, you’ve built a phonegap app that perfectly does nothing. Now let’s make it useful by drawing a bunch of stars.
The actual app is in framework/www/ directory. Open up framework/www/index.html in your favorite text editor. This is the core of your app.
Put the following code in the header right below the phonegap.js line
<!-- include our own javascript --> <script src="Starfield.js" type="text/javascript"></script> <!-- include our own style for this page --> <style type="text/css"> body.palm-default { background-color : #000000; color: white; } h2, h3 { text-align: center; margin: 3px;} h3 { font-size: 75% } </style>this will set a few styles and include the starfield.js file where the actual code is.
In the body element put this:
<div id="myapp"> <h2>Star Field</h2> <h3>tap to start</h3> <canvas id="svgCanvas" width="320" height="320" onclick="starfieldStart()"></canvas> </div>This creates a header and a canvas ready for us to draw into. When you click on the canvas it will call starfieldStart(), which begins
the star simulator. Now let’s put in some real code.
Paste this into a file called Starfield.js
var ctx;var width = 320; var height = 320; var partx; var party; var partdx; var partdy; var PARTS=100; var count=0; var ramp=1; var intervalId; function circle(x,y,r) { ctx.beginPath(); ctx.arc(x, y, r, 0, Math.PI*2, true); ctx.closePath(); ctx.fill(); }; function draw() { ctx.clearStyle = "#000000"; ctx.clearRect(0,0,width,height); ctx.fillStyle = "#000000"; ctx.fillRect(0,0,width,height); ctx.fillStyle = "#FFFFFF"; for(i=0;i<ramp;i++) { circle(partx[i],party[i],2); partx[i] += partdx[i]; party[i] += partdy[i]; if(partx[i] > width || partx[i]<0) { partx[i] = width/2; party[i] = height/2; } } count++; if(count > 500) { ramp--; if(ramp < 1) ramp = 0; } else { ramp++; if(ramp > PARTS) ramp = PARTS; } if(count > 600) { clearInterval(intervalId); } }; function starfieldStart() { count = 0; ramp = 1; ctx = document.getElementById("svgCanvas").getContext("2d"); partx = new Array(PARTS); party = new Array(PARTS); partdx = new Array(PARTS); partdy = new Array(PARTS); for(i=0;i<PARTS;i++) { partx[i] = width/2; party[i] = height/2; partdx[i] = Math.random()*5-5/2; partdy[i] = Math.random()*5-5/2; } intervalId = setInterval(draw, 10); };run ‘make’ and you’ll the app start. click in the middle to start the stars. after a few seconds (technically 600 iterations of the loop) it will end, but you can click to start it again.
That’s all there is to creating an app with phonegap. Of course, we want to create the best possible experience for our users, so there’s a few things we need to fix. Let’s see if we can make it launch faster and give it a proper name.
Launch FasterMojo is the standard Javascript framework that most webOS apps are built with. However, if you aren’t using any features within it then it’s just costing you startup time. You can actually get rid of Mojo by just commenting out the script tag at the top of your index.html page.
<!-- <script language="javascript" type="text/javascript" src="/usr/palm/frameworks/mojo/mojo.js" x-mojo-version="1"></script> -->Mojo does one thing that we need however. It tells the window manager when we the app is fully loaded and ready to go. We can do this manually with a simple onLoad event handler. Add the following script to the head of the index.html page
<script language="javascript" type="text/javascript" charset="utf-8"> function onLoad() { if (window.PalmSystem) { window.PalmSystem.stageReady(); } } </script>then add a call in the body’s onload event.
<body onload="onLoad()">That’s it. Now the app will load without Mojo and start up very quickly.
A Better NameNow lets give it a proper name. Edit the appinfo.json file and change the id, version, vendor, and title to something more appropriate.:
{ "id": "com.palmdts.phonegap.stars", "version": "0.0.1", "vendor": "Josh Marinacci", "type": "web", "main": "index.html", "title": "Stars", "icon": "icon.png" }If you change the id or version fields above (which you should) then you’ll need to edit the deploy and run targets in the Makefile as well.
A New IconNow we can replace icon.png with a new image. Here’s the one I whipped up in Photoshop.
You may need to delete the app from your phone and reinstall it for webOS to pick up the new name and icon.
DebuggingIf you are having any trouble with your app code you can debug it using two methods. First, most of your code should run perfectly in a modern desktop browser like FireFox or Chrome. Start developing your app in the browser first, and port it to PhoneGap only after the core functionality works. This will give you access to the great debugging tools built into these browsers.
Second, once you have your app running on webOS you can watch the debugging log on the device using the palm-log command.
palm-log -f com.palmdts.phonegap.starsThis will start watching the log so you can see JavaScript errors and your debugging output to the console.
ConclusionNow we’ve done it: a cross platform canvas app for webOS using PhoneGap. In the next part of this series I’ll show you how to set up the android SDK and run this exact same app on Android with almost no code changes.
It’s apparently a day of price cuts. It happened with little fanfare, but now interested customers can grab a Palm Pre Plus for free from Verizon proper. It’s little surprise, what with Big Red set to phase out their current webOS devices by the end of next month. The freeness of the Pre Plus also handily undercuts Sprint’s just-leaked reduced pricing for the lesser original Pre by $50. All these price drops are obviously happening to help clear out stagnant inventory, but we can’t help but wonder if maybe, just maybe, they might be working to clear out inventory to make room for something new and exciting.
Source: Verizon; Thanks to unseenme for the heads up!
It’s apparently a day of price cuts. It happened with little fanfare, but now interested customers can grab a Palm Pre Plus for free from Verizon proper. It’s little surprise, what with Big Red set to phase out their current webOS devices by the end of next month. The freeness of the Pre Plus also handily undercuts Sprint’s just-leaked reduced pricing for the lesser original Pre by $50. All these price drops are obviously happening to help clear out stagnant inventory, but we can’t help but wonder if maybe, just maybe, they might be working to clear out inventory to make room for something new and exciting.
Source: Verizon; Thanks to unseenme for the heads up!
It’s taken a lot of poking and prodding, but Sprint has finally seen right to drop the pricing of their webOS offerings. According to the latest edition of The Playbook, Sprint’s internal employee newsletter, effective September 12 Sprint will be dropping the new-contract price of the Palm Pre to $49.99 and the Palm Pixi to flat-out free. Right now a Pre will cost you $149.99, while a Pixi costs $49.99 - both prices sadly still include the $100 mail-in rebate.
In addition to the new contract pricing, Sprint is also dropping the pricing for off contract purchases, with $200 slashed from the Pre (dropping it to $349.99 off contract) and the Pixi cut by $50 to $299.99. After a cursory glance at Sprint’s smartphone offerings, that’ll make the Pre and Pixi the cheapest way to get into the smartphone game on America’s #3 network. Unless, you know, you want a Centro ($80 off contract, free with a new subscription).
Thanks anonymous tipster!
It’s taken a lot of poking and prodding, but Sprint has finally seen right to drop the pricing of their webOS offerings. According to the latest edition of The Playbook, Sprint’s internal employee newsletter, effective September 12 Sprint will be dropping the new-contract price of the Palm Pre to $49.99 and the Palm Pixi to flat-out free. Right now a Pre will cost you $149.99, while a Pixi costs $49.99 - both prices sadly still include the $100 mail-in rebate.
In addition to the new contract pricing, Sprint is also dropping the pricing for off contract purchases, with $200 slashed from the Pre (dropping it to $349.99 off contract) and the Pixi cut by $50 to $299.99. After a cursory glance at Sprint’s smartphone offerings, that’ll make the Pre and Pixi the cheapest way to get into the smartphone game on America’s #3 network. Unless, you know, you want a Centro ($80 off contract, free with a new subscription).
Thanks anonymous tipster!