WOG OSK does it again!

New keyboard look!

Here are the youtube videos posted showing that the new WOG OSK will have slide to type capability, along with bubble letters, editing capabilities and it still inetracts with all of your Palm apps!

Slide to type!

Shorter version – Slide to type on the Pre!

No hacking a virtual keyboard into your phone, or having it pop up over your app – this sits in the notification area and we love the new look! The slide to type is very cool and easily done with one finger. We also still love the ease of use of the quick keys. With 57 programmable keys to choose from it makes life much easier.

The new update has been submitted to Palm and will hopefully be released soon!

Alos found the the landscape keyboard now opens up in the browser, but it is slide to type only!

Landscape in Browser

WOG O.S.K. was just released!

Typing into webpage!

It is the first virtual keyboard in the app catalog that can type directly into your other apps, browser and even webpages!

They have told us that they are already working on an update to make the “slider” keyboard more accurate by adding pop-up letters and the ability to simply slide around the board and lift your finger when you’re on the key you want. They say that the next update is scheduled for some time in April.

We have found that it takes some getting used to, and is really handy for quick responses, but find it easier to type longer texts and emails in “App Mode” (function key, then rocket key) because you can tap in the text box behind the keyboard and edit. Close the App Mode, pop up the kayboard in front of your target, hit the clipboard button (bottom left when shift is on) and it pastes your text that you wrote. Tap on the To field, type some of the contact name, hit the address book icon twice and select the contact – all without having to slide the phone open!

What’s also nice are the “Quick Keys”. We stored pimpmypre.com on one key, username on another and password on the next. It made logging in from my phone extremely easy.

Overall, we like it. It’s not a true virtual keyboard, but it’s a nice addition to the app catalog, we believe.

All applications have been moved to WebOS Group.
http://webosgroup.com

Pimp My Pre will still host ringtones and wallpapers and will have more news soon.
We are currently working to reorganize the site.

All applications have been moved to WebOS Group.
http://webosgroup.com

Pimp My Pre will stil host ringtones and wallpapers and will have more news soon.

Viewt he new PreLoad here
http://webosgroup.com/2009/08/18/preload/

Apparently, some people wanted to see the actual standalone app we made to change ringtones for SMS and Email.  So we made a vid of the one that’s installed on my Pre, instead of the one hacked into the Sounds and Ringtones section. The plan is to expand that app to include more functionality. We’re also busy working on getting the repository app working; which shouldn’t be too long now. So start getting wallpapers together and, as a preview of what it can do, get some icons ready to build your own themes.

Sorry – we can’t install this app on your pre — YET! But an installer can’t be far behind with how quickly we’re working.

Remember to use the forums or email us with any questions or comments!

Mitch

The core OS is based on a version of the Linux 2.6 kernel with the standard driver architecture managed by udev, with a proprietary boot loader. It supports an ext3 filesystem for the internal (private) file partitions and fat32 for the media file partition, which can be externally mounted via USB for transferring media files to and from the device.

The Wireless Comms system at the highest level provides connection management that automatically attaches to WAN and WiFi networks when available, switches connections dynamically, prioritizing WiFi connections when both are available. EVDO or UMTS telephony and WAN data is supported depending upon the particular device model. Palm webOS also supports most standard Bluetooth profiles and provides simple pairing services. The Bluetooth sub-system is tightly integrated with audio routing to dynamically handle audio paths based upon user preferences and peripheral availability.

The media server is based upon gstreamer and includes support for numerous audio and video codecs, all mainstream image formats, and supports image capture through the built-in camera. Video and audio capture is not supported in the initial webOS products, but is inherently supported by the architecture. Video and audio playback supports both file and stream-based playback.

Of course the best way to get started writing webOS applications is to continue reading this book, but you should also go to Palm’s developer site, http://developer.palm.com and register as a Palm developer and download the Palm Software Developer Kit (SDK). The SDK includes the development tools, sample code, the Mojo Framework, along with access to the Palm Developer Wiki, where developers will find formal and informal training materials, tutorial and reference documentation. Palm also provides registered developers with direct technical support by email or through interaction in a hosted developer forum.

The Palm Developer Tools (PDT) are installed from the SDK and include targets for Linux, Windows (XP/Vista) and Mac OS X. The tools enable you to create a new Palm project using sample code and framework defaults, search reference documentation, debug your app in the weOS emulator or an attached Palm device, and publish an application. Chapter 2 includes more details about the tools in Palm’s SDK and third-party tools, but you’ll find a brief summary in Table 1-1 below.

The tools can be installed and accessed as command-line tools on every platform and include some bundles for integration into popular HTML editors and as a plug-in to Eclipse and Aptana Studio, a popular Javascript/HTML/CSS editor for Eclipse. Refer to Palm’s Developer portal for the most current list of supported editors and tool bundles.

The SDK installation includes a copy of the Framework and sample code to help you design and implement your application. Unlike most JavaScript frameworks, you won’t need to include the Mojo framework with your application code since Palm includes the framework in every webOS device. The framework code included in the SDK is for reference purposes to help you with debugging your applications.

The sample code is also for reference. There are samples for most of the significant framework functions, including application lifecycle functions, UI widgets and each of the services. Simple applications are included to give you some starter applications to review and leverage as you choose.

Your main entry point is http://developer.palm.com/, which is where Palm hosts the Developer Portal. The portal provides access to everything that you might need to build webOS applications, including access to the SDK, all development tools, and documentation and training materials.

The Developer Portal provides your application signing services and access to the Application Catalog. This is an application store that is published and promoted with every webOS device through a built-in App Catalog application. Applications need to be signed for installation on a webOS device, and through the portal you can access the signing tools and related support.

In this introductory chapter, you were introduced to webOS, Palm’s next generation operating system. The following chapters will cover each of these topics in far more detail but this chapter should have helped you understand the webOS architecture and application model along with the basic services available in the SDK.

You’ll find that it’s pretty easy to get started writing webOS applications. After all, you’re simply building web applications, using conventional web languages and tools. You can port a very simple Ajax application by creating an appinfo.json file for your application at the same level as your application’s index.html file. With as little as that, your app can be published and available for download to any webOS device.

From there you can invest more deeply by building in the Mojo UI widgets to take advantage of the fluid physics engine, gesture navigation, beautiful visual features, text editing, and the powerful notification system. You can move beyond simple foreground applications that rely on active user interaction, and adapt your application to run in the background or even be headless. Or consider an application that can open new windows for each new activity, enabling the user to multi-task within a single application. There’s a whole new generation of applications possible on the webOS platform, just waiting to be built.

Supporting webOS’s user interface are UI Widgets and a set of standard styles for use with the widgets and within your scenes. Mojo defines default styles for scenes and for each of the widgets. You get the styles simply by declaring and using the widgets, and you can also override the styles either collectively or individually with custom CSS.

The List is the most important widget in the framework. The webOS user experience was designed around a fast and powerful list widget, binding lists to dynamic data sources with instantaneous filtering and embedding objects within lists including other widgets, including other lists, icons and images.

There are Simple Widgets, including buttons, checkboxes, sliders, indicators, and containers. The Text Field widget includes text entry and editing functions, including selection, cut/copy/paste, and text filtering. A Text Field can be used singly or in groups or in conjunction with a List widget.

Menu widgets can be used within specified areas on the screen; at the top and bottoms are the View and Command menus and they are completely under your control. The App Menu is handled by the system, but you can provide functions to service the Help and Preferences items or add custom items to the menu. Each of the various menu types is shown in Figure 1-10.

For Notifications, you can choose from a Popup Notification or a Banner Notification, both of which post notifications for applications in the notification bar.

Pickers and Viewers are more complex widgets. Pickers are for browsing and filtering files or contacts, or for selecting addresses, dates or times. If you want to play or view content within your application, such as audio, pictures, video or web content, then you would include the appropriate viewer.

A widget is declared within your HTML as an empty div with an x-mojo-element attribute. For example, the following declares a Toggle Button widget:

The x-mojo-element attribute specifies the widget class used to fill out the div when the HTML is added to the page. The id attribute is required to reference the widget from your Javascript and must be unique.

Typically, you would declare the widget within a scene’s view file, then direct Mojo to instantiate the widget during the corresponding scene assistant setup method using the scene controller’s setupWidget method:

This code directs the scene controller to setup my-toggle passing a set of attributes, toggle, and a data model, togglemodel, to use when instantiating the widget and to register the togglePressed function for the widget’s propertyChange event. The widget will be instantiated whenever this scene is pushed onto the scene stack.

To override the default style for this widget, you would select #my-checkbox in your CSS and apply the desired styling (or use .checkbox to override the styling for all checkboxes in your app). For example, to override the default positioning of the toggle button to the right of its label so that it appears to the left of the label:

There’s a lot more to come so you shouldn’t expect to be able to use this to start working with any of these widgets at this point. Chapter 3 and 4 describe each of the widgets and styles in complete detail.

Palm’s user experience architecture provides for a greater degree of application scope than is normally considered in a web application. To support this and specific functions of the framework, Palm has introduced a structure for webOS applications built around stages and scenes.

A stage is a declarative HTML structure similar to a conventional HTML window or browser tab. Palm webOS applications can have one or more stages, but typically the primary stage will correspond to the application’s card. Other stages might include a dashboard, or other cards associated with different activities within the application. You should refer back to the earlier example of the Email application where the main card held the Email inbox and another card held a draft Email. Each email card is a separate stage, but part of the same application.

Scenes are mutually exclusive views of the application within a Stage. Most applications will provide a number of different kinds of scenes within the same stage, but some very simple applications (such as Calculator) will have just a single scene. An application must have at least one scene, supported by a controller, a JavaScript object referred to as a scene assistant, and a scene view, a segment of HTML representing the layout of the scene.

Most applications will have multiple scenes. You will need to specifically activate (or push) the current scene into the view and pop a scene when it’s no longer needed. Typically, a new scene is pushed after a user action, such as a tap on a UI widget and an old scene is popped when the user gestures back.

As the terms imply, scenes are managed like a stack with new scenes pushed onto and off of the stack with the last scene on the stack visible in the view. Mojo manages the scene stack but you will need to direct the action through provided functions and respond to UI events that trigger scene transitions. Mojo has a number of stageController functions specifically designed to assist you, which you can find in detail in Chapter 2, Application Basics, and Chapter 3, UI Widgets.

Palm webOS applications are required to use directory and file structure conventions to enable the framework to run the applications without complex configuration files. At the top level the application must have an appinfo.json object, providing the framework with the essential information needed to install and load the app. In addition, all applications will have an index.html file, an icon.png for application’s Launcher icon, and an app folder, which provides a directory structure for assistants and views.

By convention, if the app has images, other javascript or application-specific CSS, then these should be contained in folders named images, javascripts, and stylesheets respectively. This is not required but makes it simpler to understand the application’s structure.

Launching a webOS application starts with loading the index.html file and any referenced stylesheets and javascript files, as would be done with any web application or web page. However, the framework intervenes after the loading operations and invokes the stage and scene assistants to perform the application’s setup functions and to activate the first scene. From this point, the application would be driven either by user actions or dynamic data.

Significantly, this organizational model makes it possible for you to build an application that will manage multiple activities, that will be in different states (active, monitoring and background) at the same time.

Applications can range from the simple to the complex:

• Single scene apps, such as a Calculator, which the user can launch, interact with and then set aside or close;
• Headless apps, such as traffic alert application that only prompts with notifications when there is a traffic event and whose settings are controlled by its dashboard;
• Connected apps like a social-networking app, which provides a card for interaction or viewing and a dashboard giving status;
• Complex multi-stage apps like Email, which can have an Inbox card, one or more Compose cards, along with a dashboard showing email status. When all the cards are closed, Email will run headless to continue to sync email and post notifications as new emails arrive.

Palm webOS supports the standard DOM Level 2 event model. For DOM events, you can use conventional techniques to listen for any of the supported events and assign event handlers in either your HTML or JavaScript code.

The UI Widgets have a number of custom events, which are covered in more detail in Chapter 3. For these events you will need to use custom event functions provided within the framework. Mojo events works within the DOM event model but includes support for listening to and generating custom Mojo event types and is more strict with parameters; Mojo checks parameters to confirm that they are properly defined and typed.

The webOS Service functions work a bit differently, with registered callbacks instead of DOM-style events, and are covered starting in Chapter 7. The event-driven model isn’t conventional to web development, but has been part of modern OS application design and derives from that.

Mojo supports the HTML5 database functions directly and provides high-level functions to support simple Create, Read, Update or Delete (CRUD) operations on local databases. Through these Mojo Depot functions, you can create a local database and add, delete or retrieve records individually or as a set. It’s expected that you’d use databases for storage of application preferences, or cache data for faster access on application launch or for use when the device is disconnected.

There are some foundational principles or values that support the overall webOS user experience; application designers can exploit these same principles to more deeply integrate the application into the overall device experience and enhance the user’s experience. Developers can rely on the framework to provide most of what is required at an implementation level, but the application design should anticipate these needs.

Here are the key principles to keep in mind while designing your application:

• Physical metaphors are reinforced through direct interaction with application objects and features, instant response to actions, followed by smooth display and object transitions with physics-based scrolling and other movement. For example, objects are deleted by flicking off screen and editing is in place without auxiliary dialogs or scenes.
• Maintain a sense of place with repeatable actions, reversible actions, stable object placement and visual transitions taking the user from one place to the next.
• Always display up-to-date data, which requires both pushing and pulling the latest data onto the device so that the user is never looking at stale data when more recent data is available. But this also means managing on-device caches so that when the device is out of coverage or otherwise off-line, the user has access to the last data received.
• Palm webOS is fast and simple to use; all features should be designed for instant response, easy for novices to learn while efficient for experienced users.
• Minimize the steps for all common functions; put frequently executed commands on the screen, the next most frequent under the menus. Avoid preferences and settings where possible and where not, keep them minimal.
• Don’t block the user; don’t use a modal control when the same function can be carried out non-modally.
• Be consistent; help the user learn new tasks and features by leveraging what they have already learned.

Palm applications have always been built around a direct interaction model, where the user touches the screen to select, navigate, and edit. Palm webOS applications have a significantly expanded vocabulary for interaction, but they start at the same place. Your application design should be strongly centered on direct interaction, with clear and distinguishable targets. The platform will provide physical metaphors through display and navigation, but applications need to extend the metaphor with instantaneous response to user actions, to smoothly transitioning display changes, and object transitions.

You can find a lot more on the user interface guidelines and design information in the Palm webOS SDK under the Design Guide. We’ll touch on the principles and reference standard style guidelines in the next few chapters, but will not be covering this topic in depth.

A webOS application is similar to a web application based on standard HTML, CSS, and JavaScript, but the application lifecycle is different. Applications are run within the UI System Manager, an application runtime built on standard browser technology, to render the display, assist with events, and handle JavaScript.

The webOS APIs are delivered as a JavaScript framework, called Mojo, which supports common application-level functions, UI widgets, access to built-in applications and their data, and native services. To build full-featured webOS applications, many developers will also leverage HTML5 features such as video/audio tagging and database functions. Although not formally part of the framework, the Prototype JavaScript framework is bundled with Mojo to assist with registering for events and DOM handling among many other great features.

The framework provides a specific structure for applications to follow based on the Model-View-Controller (MVC) architectural pattern. This allows for better separation of business logic, data, and presentation. Following the conventions reduces complexity; each component of an application has a defined format and location that the framework knows how to handle by default.

You will get a more extensive overview of Mojo in Chapter 2, and details on widgets, services and styles starting in Chapter 3. For now, you should know that the framework includes:

• Application structure, such as controllers, views, models, events, storage, notifications, logging and asserts;
• UI widgets, including simple single-function widgets, complex multi-function widgets and integrated media viewers;
• Services, including access to application data and cross-app launching, storage services, location services, cloud services, and accelerometer data;

Outside of the built-in applications, webOS applications are deployed over the web. They can be found in Palm’s App Catalog, an application distribution service, built into all webOS devices and available to all registered developers. The basic lifecycle stages are illustrated in Figure 1-9.

Downloading an application to the device initiates installation of the app provided that it has been validly signed. After installation the application will appear in the Launcher. If it is a headless application, then a card is not required and instead the application can utilize just a dashboard and communicate to the user through notifications. Headless applications typically include a simple card based preferences scene to initiate the application and configure its settings. Note that headless applications require at least one visible stage at all times (either a card, dashboard or alert) to not be shut down.

Other applications are launched from the launcher into the foreground and may be switched between foreground and background by the user. Each of these state changes (launch, deactivate, activate, close) is indicated by one or more events. Applications are able to post notifications and optionally maintain a dashboard while in the background.

Applications are updated periodically by the system. If running, the application is closed, the new version installed, and then it’s launched. There isn’t an update event so the app needs to reconcile changes after installation, including data migration or other compatibility needs.

The user can opt to remove an application and its data from the device. When the user attempts to delete an application, the system will stop the application if needed and remove its components from the device. This includes removing it from the launcher and any local application data, plus any data added to the Palm application databases such as Contacts or Calendar data.