19. webOS SDK
• Standard HTML Development Process
• Optional Eclipse Plugin
• Command-line SDK tools
• OS X, Linux, Windows support
20. The webOS Emulator
• VirtualBox
• x86 build of webOS
• most things identical
• not all hardware features supported (camera,
multitouch)
• simulate events
22. Palm Inspector
• WebKit Inspector Based
• Connects to Emulator
• HTML Object View/Change
• Console
23. Emulator Host Mode
• Embedded web server
• Use your desktop browser
• Good for inspecting HTML
• ssh -p 5522 -L 5581:localhost:8080 root@localhost
• http://localhost:5581/Apps
25. Ares
• visual IDE and GUI builder: WYSIWYG
• runs in the browser
• makes the same apps as the command line SDK
• works with local emulator, debugging, logging
• works with real devices
• makes most coding tasks much faster
26. Ares vs Mojo
• slightly different style of coding
• Mojo widgets contained in lightweight wrappers
• not all widgets are supported (more coming)
• code is more concise
28. App Catalog
• App Catalog built into all devices
• 70/30 revenue split (Developer/Palm)
• Multiple Catalogs
• Multiple Countries
• Free submission
• PDK Hotapps Promotion
• $1 Million in prizes
• Downloads (Free apps) and Revenue (Paid Apps)
29. International Apps
• Translating is strongly encouraged, not required
• Metadata for each language (title, description,
screenshots, etc.)
• Set prices for each country
Thank every for coming
Thank Solstice for setting this up
Today: Intro to the webOS platform.
Background:
Palm Developer Relations Team: Goal is to provide resources to devs in form of training, support, and examples.
goal: Provide a high level overview of the webOS architecture, SDK, and ecosystem
What is the webOS?
The webOS is Palm's mobile operating system. It was designed from the ground up to be a mobile operating system for devices with a touch screen and a physical keyboard. It can scale to different screen sizes and hardware capabilities while presenting a uniform platform to you, the software developer.
- Use standard web technologies
- HTML5 = New web specs, NOT strictly HTML5 spec
- Storage
- Geolocation
- CSS3
- Etc
- Allows of cool UIs such as this one
Other option:- Faster
- Use of standards: Easy porting
SDL : Input controls and 2D surface APIs
PDL : Palm Specific APIs
PDK apps can be either pure PDK running as full screen, such as most of our 3D games, or hybrid apps where you mix some native code with an HTML based Mojo app.
application architecture
difference between a webos app and a web app. no webserver. everything is local. you implement state changes and program logic in javascript locally. you don't call back to a server somewhere.
cards, stages, and scenes
the webos uses the 'card' as the core ui metaphor. with a few exceptions, every app is shown as a card. the user switches between apps much as you would deal a deck of cards, flipping from one card to another. this is a very tangable metaphor that everyone can grasp very quickly.
from an application point of view you have stages and scenes. a stage is a card. a scene is a view within that card. you only see one scene at a time. if this was a webpage then the stage would be the browser window or tab, and the scene would be a page on your site. the user can navigate from scene to scene, or page to page. some apps actually have more than one stage, meaning they have more than one card visible. a good example of this is the email app. there is one card for viewing your mail. it has multiple scenes: one for the list of inboxes, one for the list of mails in your inbox, and one for the mail you are currently useing. the mail app also has secondary stages for when you compose an email. in this case it shows a full separate card so that you can write an email but still switch back to the inbox to read another email before you are done.
I’m not going to cover it in this session, but there is also another kind of stage called a dashboard. This is a little indicator at the bottom of the screen that lets you know you have a message or alert or some other notification. This can be expanded into a full dashboard, which is a wide but short window across the bottom that gives the user more info and the ability to take action. Usually this will open up the full app that created the notification, or it may provide the user with other controls, such as the music player which lets you pause or switch tracks.
Very simple scene
You then wire up the widgets using JavaScript. This code will turn the ‘destroyPlanet’ function into an event listener with the bindAsEventListener function. Then it attaches the listener to the button using the ‘listen’ function on the scene controller.
Here’s what that view looks like without adding any more code or CSS.
The framework defines a variety of widgets for common UI flows. Further more these can be customized directly through CSS and Javascript.
The webOS has lots of APIs for all sorts of things so I’ve divided them into four sections. First is direct monitoring of the hardware. Pretty much every piece of hardware in the phones has an API for it, such as the accelerometer and the GPS radio. Next are platform services. This are services apis for things that aren’t really hardware but let you request features from the operating system. This is stuff like the current state of the network, power settings, and direct embedding of video streams.
Next are application services. This are simply APIs provided to your app to interact with the user’s data on the device, with the appropriate privacy safeguards.
Finally we have application actions. These are apis that let you request another application to do something for you, usually by opening that application in a particular state. For example, with the Email API you don’t directly send an email. Instead you ask the email app to open up a new message with the recipient and subject you provide.
The webOS has lots of APIs for all sorts of things so I’ve divided them into four sections. First is direct monitoring of the hardware. Pretty much every piece of hardware in the phones has an API for it, such as the accelerometer and the GPS radio. Next are platform services. This are services apis for things that aren’t really hardware but let you request features from the operating system. This is stuff like the current state of the network, power settings, and direct embedding of video streams.
Next are application services. This are simply APIs provided to your app to interact with the user’s data on the device, with the appropriate privacy safeguards.
Finally we have application actions. These are apis that let you request another application to do something for you, usually by opening that application in a particular state. For example, with the Email API you don’t directly send an email. Instead you ask the email app to open up a new message with the recipient and subject you provide.
The webOS has lots of APIs for all sorts of things so I’ve divided them into four sections. First is direct monitoring of the hardware. Pretty much every piece of hardware in the phones has an API for it, such as the accelerometer and the GPS radio. Next are platform services. This are services apis for things that aren’t really hardware but let you request features from the operating system. This is stuff like the current state of the network, power settings, and direct embedding of video streams.
Next are application services. This are simply APIs provided to your app to interact with the user’s data on the device, with the appropriate privacy safeguards.
Finally we have application actions. These are apis that let you request another application to do something for you, usually by opening that application in a particular state. For example, with the Email API you don’t directly send an email. Instead you ask the email app to open up a new message with the recipient and subject you provide.
We provide a variety of tools to assist with development, SDK command line, Eclipse plugin, Emulator, Ares.
We do have an eclipse plugin and our Ares visual tool, but I'm going to just use the core SDK with command line tools to show you what's really going on. It's sort of like in math class where your teacher taught you how to add and subtract before showing you how to use the calculator to do it faster. The command line tools also make it very easy to automate your development workflow using ant files, hudson, and other build systems.
commandline tools
our command line tools are written in [java? python? bash?] so they should run everywhere. The whole SDK is designed to be platform independent and usable from open source tools, which is why we chose VirtualBox as our emulator.
The webOS emulator is an instance of the open source project VirtualBox. It's an x86 build of our whole OS, so it really is very close to a real device except for the different hardware. Not all hardware features are supported, such as the camera. For some hardware like GPS you can simulate events using command line tools. This comes in very handy when building unit tests for your software.
[a note on virtual box: you must have version xxx]
In addition to the key strokes for simple accelerometer events you can also simulate some radio features from the command line. For example you can fake an incoming phone call like this. And you can fake a GPS fix like this.
You can also use the luna-send command to control the GPS Auto Drive feature. This lets you use a fake GPS route out of a csv file. It’s good for simulating the full GPS experience. Even if you have a real device to test on this can be useful for unit tests of edge cases.
As of 1.4.1 we added a mini webserver to the emulator. This lets you browse your apps from another webbrowser over an SSH tunnel. This is great for debugging. Just create a tunnel and then open our desktop browser to this page.
Does not work will all applications.
As of 1.4.1 we added a mini webserver to the emulator. This lets you browse your apps from another webbrowser over an SSH tunnel. This is great for debugging. Just create a tunnel and then open our desktop browser to this page.
Does not work will all applications.
Ares is our new visual IDE and gui builder. It lets you build webOS apps with a drag and drop gui builder. It’s entirely webbased but uses the real emulator locally on your computer. It can even deploy straight to your USB connected phone. It really makes coding webOS apps easier and faster.
There are a few differences between Ares and regular Mojo apps. Ares wraps the mojo widgets in lightweight containers and handles a lot of the boilerplate code for you. You can drop down to regular Mojo APIs if you want to, which sometimes you have to do for the widgets that Ares hasn’t wrapped yet.
Now let’s look at an example of Ares
open ares, create a simple one stage application with a header and the same ‘activate’ and ‘destroy’ buttons. make the destroy button have the negative class.
change orientation to show how stuff resizes automatically
run the app in the preview
show property sheet, add event handler to the button which prints to the log.
show the logging, undo/redo, jslint.
run the app in the emulator
use the ‘email’ non visual component to create a new message when the activate button is pressed
app catalog
rules and structure
submission process
extras:
sources of graphics and icons
tools to use: cssedit, jedit, netbeans & eclipse
