Enyo on Phones
From WebOS101
With the HP Maps update from October installed on a Pre, Pre+, or Pre2, all webOS devices are now capable of using the Enyo framework. (it comes preinstalled on the Pre3)
However, it has come to many people's attention that there are several problems that are mainly related to the older versions of WebKit used in webOS 1.x and 2.x.
This page is an attempt to catalog those items and possible workarounds for them.
Disabled menu buttons do not appear any differently from enabled ones
jpiquard from the webOS Developer Forums, has supplied this solution:
I have seen the same problem in Emulator SDK 2210.
To bypass this bug I have used the following code in CheckAppMenu:
this.$.menuHelp.addRemoveClass("itemmenu-disabled", this.$.menuHelp.disabled);
With the following css overwrite:
.itemmenu-disabled .enyo-menuitem-caption {
color: DarkGray;
opacity: 1.0;
}
This will add the class "itemmenu-disabled" to the menuHelp component, or remove it if "disabled" is false. The CSS override forces the older WebKit to do the right thing with it's color.
enyo.Dashboard layers appear in all white
rwatkins from the webOS Developer Forums posts that this is apparently because the newer WebKit used on the TouchPad will handle background transparency with no specified color properly, but the older versions do not. He has fixed this by writing a new Dashboard and including that in his application.
eblade has (partially) solved this without writing a new sub-app, by doing:
dashboardActivated: function(dash) {
for(l in dash)
{
var c = dash[l].dashboardContent;
if(c)
{
c.$.topSwipeable.applyStyle("background-color", "black");
}
}
},
then specify that as your onDashboardActivated event when you create the dashboard.
rwatkins way of doing it is probably a better way, as the dashboardActivated method doesn't completely make the dashboard visible, and it is only called when the dashboard is made visible by tapping on it, not when it becomes visible in some other method.
enyo.fetchAppInfo() returns a string rather than an object
This apparently only bites on webOS 1.x. One way of solving this, is to use:
try {
var appInfo = JSON.parse(enyo.fetchAppInfo());
} catch(err) {
var appInfo = enyo.fetchAppInfo();
}
fahhem doesn't recommend calling fetchAppInfo() twice on systems that are 'correct':
var appInfo = enyo.fetchAppInfo();
if(enyo.isString(appInfo))
appInfo = JSON.parse(appInfo);
setStyle and other methods to compute styles are very slow
some configurations of a toolbar and buttons have a black bar in them
inputs in multi-pane apps do not scroll properly
When using an input in a sliding pane app, inputs on the right most (and possibly others, but not the left-most) sliding panes will not scroll properly -- you can scroll beyond the edge of the screen, and then the application itself will begin scrolling off screen!
At this time, I do not know of a work around or fix, but I do keep all of my inputs inside enyo.Popup or enyo.Dialog containers, and that seems to work well.
runTextIndexer ignores options
enyo.string.runTextIndexer() ignores the emoticon: false setting when passed to it, and attempts to display emoticons, which doesn't work on any device for non-Palm apps.
enyo.WebView doesn't work
The system component for WebViews (BrowserAdapter) was reworked in webOS 3.0 with a new internal interface. The Enyo code for talking with WebViews assumes this new interface and can't handle the older version of BrowserAdapter on 1.x and 2.x.
tapping links in slidingviews may cause the app to disappear!
Haven't completely tracked this one, but in at least one known case, an application with two SlidingViews would slide completely off the display when the user taps a clickable link in the right side's sliding view.
NOTE: This problem seems to be resolved on Pre 2's running webOS 2.2.4.
The "Sym" key doesn't work
The "Sym" key on the hardware keyboard does not work in Enyo inputs. Apparently the popup keyboard dialog is implemented in the Mojo framework on 1.x and 2.x, and therefore is not accessable. Someone could recreate it in Enyo, though.
Spell correction interface doesn't work
At least in 2.2.4, probably on earlier versions, the spell correction interface doesn't work -- spell correction works, but tapping on a word that had been spell corrected to attempt to change it or add it to the dictionary is not available. My guess is that this is also implemented in Mojo in 1.x and 2.x, but within the Luna system itself in 3.x. Further testing will be necessary, however, as some people have reported that their spell check interface doesn't work at all in 2.2.4.
Buttons in Exhibition Mode stick or don't respond
Buttons in Exhibition Mode stick or don't respond reliably. No error messages are logged.
