Page 2 of 2 FirstFirst 12
Results 21 to 31 of 31
Like Tree31Likes
  1.    #21  
    A scene can be showing on the screen, without its activation method getting called. This will probably leave your scene improperly activated.
    Similarly, its possible for a scene to be activated without its DOM being loaded, such as on a launch event while the screen is locked but the scene is already open. This will probably cause a bunch of errors.

    Both of these bugs lead to significant problems when re-hydrating an app on an event other than a normal launch (like an alarm!) These Mojo bugs are infuriating to work around! Here are the cases:

    • Your app is active and the screen is on. Your scene which created the system alarm and wants to respond to it is active and in focus. You are re-launched by an alarm; the stage controller will respond. You will need to pop/push your scene off then onto the stack for your activate method to fire properly.
    • Your app is active and the screen is on. Your scene which created the system alarm and wants to respond is not in the stack. You are re-launched by an alarm; the stage controller will respond. You can choose to show a notification scene/stage or pop your primary responder scene back to the top of the stack -- your activate method will fire properly.
    • Your app is active and the screen is off. Your scene which created the system alarm and wants to respond is active and in focus. You are re-launched by an alarm, and your app is re-activated. Your activate method is called, but your DOM is not loaded yet. Your scene is probably now dead. Consider launching a notification window on an alarm launch instead. When the alarm window is closed, you can push/pop your main scene to have it properly activated.
    • Your app is killed. The screen can be on or off. You are re-launched by an alarm; the app controller (if present) will respond. You can choose to show a notification scene/stage from there, but you'll still fall through to the main stage controller, so you'll also need to push a main stage scene too or there'll be an empty "nothingness" behind your notification window.

    On this last point, it should be possible to launch only a notification scene+stage -- without needing a full-screen (main) stage. Other apps do it -- I just can't figure out how.

    Related note: Although the documentation says to use Javascript timers (setTimeout, setInterval) if these do anything with the UI/DOM on your scene, and your app navigates away from that scene (swapScene) or the user moves away from your app (multi-tasking or screen-off) these will generate errors. When your scene comes back into focus and is properly activated (see above) your timer UI interaction will start working again.
    Last edited by jonwise80; 11/28/2018 at 08:58 PM.
    Preemptive and Nafetz like this.
  2.    #22  
    Release Notification:

    Stopwatch 0.1.1 is available for download on GitHub:
    This app provides an elegant UI for stopwatch (count up) and timer (count down) functionality, with sub-second accuracy. Its been tested on webOS 2.x and higher (although it theoretically should work on earlier versions) and is objectively better than any other timer app in Preware today.

    Although there are a few UI bugs that remain, and some features I'd like to add some day, the base functionality is on par with iOS and suitable for regular use. Stopwatch supports background operation: The timer works even if the app is killed, thanks to the webOS alarm functionality. The stopwatch runs until stopped or the app is killed (I may be able to make this even more resilient in the future.)

    Feedback and bug reports are welcome on GitHub:
  3.    #23  
    As 2018 draws to a close, so does my experiment in developing with Mojo. The fruit of that labor was 2 apps, that are hopefully useful:
    - Stopwatch - chronicled above - downloadable here:
    - Night Moves - history here - downloadable here:

    I'll continue to update and bug fix them as necessary, and as my hardware holds out. Hopefully they'll get listed in an existing Preware feed soon, but if not, I'll work on creating my own feed.
    For 2019, and my planned Philips Hue app, I'm going to teach myself Enyo. While I don't claim to have become an expert on Mojo, I certainly learned a lot, and I thought I'd wrap up this thread with some reflections...

    Paul Mercer, a former software director at HP, told the NY Times that WebOS came too early, and that the rush to compete with Apple (apparently v1 was developed in just 9 months) led to some major flaws. Certainly the fact that they had to ditch Mojo and start over with Enyo is evidence that they didn't have the time to fully think through all the potential use-cases. I lead a couple dev teams, and I'm well aware that there's a balance between "just trying something" and "architecting defensively" for some use you don't know about now. I also know that engineers love a blank slate -- "let's just throw it out and start again" is a real temptation. It remains to be seen (for me at least) whether that was what happened with the Mojo to Enyo transition. There's definitely major flaws in Mojo (eg: you can't call it Model-View-Controller when most of the Controller code has to manipulate the View directly because its not actually bound to its Model except during setup). But it seems like it could have been evolved without a hard switch to a new framework. From what little I've seen of Enyo, its got its own issues -- which is often the case with starting over: you trade a set of known issues, for a new set of unknowns.

    Would developer platform stability have saved webOS, though? I'm not sure. Having pulled the full App Catalog FTP, and been through every Preware feed I can find, there's an incredible body of work on webOS. There are some really fun games, and useful (or formerly useful, when their web services were available) apps on this little platform. Obviously people liked it and liked developing for it, before it was suddenly and summarily executed. I suppose it could be argued that the TouchPad was never going to hold its own against the dual threat of Apple and Google, but I wouldn't credit the HP leadership with that kind of crystal ball -- they just plain chickened-out, that's what really happened. I worked for a major consumer electronics company in the relatively early tablet days, and Google wasn't a serious player in tablets at the beginning. To make our tablets, we had to do significant re-work of AOSP, and work closely with ISVs to support them refactoring their APKs for bigger screens, because Google wasn't doing it at the time. Eventually they caught up, obviously, but the fact that people are still managing to get the latest version of Android running on the TouchPad is evidence that the hardware was solid, and that the OS just needed more time. Time it didn't get.

    Personally, I'm not particularly happy with the winners of the mobile OS war. Tablets have long since past their peak, and smart phone sales are finally in decline. Apple and Google made OSes that just aren't that great... but they are the victors (with Samsung becoming a war profiteer along-the-way) and the opportunity for disruption will now have to come from significant technology changes, not from a slightly different (even slightly better) OS.
    While my Pre3 still delights me, my TouchPad has become a near daily use device, and I love that there's such a welcoming community trying to keep them alive, realistically, they're only viable platforms for a little longer. If we can't solve the TLS problem, then my webOS devices will probably fall into dis-use when Microsoft cuts of EAS access -- without email as a basic 2-way transport, and with HTTPS becoming less accessible, there's won't be much left that webOS can do on the "web".

    LuneOS and webOS OSE are valiant efforts. I finally got a version of LuneOS running, and downloaded a Pi image for OSE. Again, its great that there's a community working on alternatives. For daily use, though, both projects are a ways off -- hopefully anything I develop in Enyo can have a second life on LuneOS as well. But even if neither of these efforts succeed, there's still an incredible wealth of knowledge to be gleaned from the efforts that have gone into both the preservation of the history, and the maintenance of the code. The best product managers and software developers are ones who know how to "borrow" from good ideas from the past (and how to avoid the mistakes others have already made!) Clearly the fact that Apple is still copying ideas from webOS means that our favorite little OS, made of equal parts Linux and Javascript, was worth more than HP really understood at the time...

    I'll create a new thread for my Enyo efforts in 2019.

    If you've arrived here looking to try out some Mojo yourself, please check the common bits in my projects above, which solve a lot of problems, and will give you useful hints on how things work:

    • AppModel - simplifies stored settings for your app
    • SystemModel - simplifies many common OS interactions
    • Mojo Additions - work-arounds and simplifications for Mojo weirdness

    Also check out the ongoing effort to preserve and update the documentation:
    The SDK links in those documents work, and come with helpful tutorials and sample apps to get you started.

    And if you haven't already, join the community here and on IRC:
    Preemptive and Nafetz like this.
  4. #24  
    It seems a while since my last dumb question (but it probably isn't).

    I think that as the TouchPad was going to be HP's Android tablet (until the purchase of webOS), Enyo was originally an HP project. It was designed to be cross-platform and for a while there were hopes that if it were taken up more widely, there would be more apps available for webOS.

    My question is: As it's all basically javascript, is it possible to make a hybrid mojo / enyo app? Or perhaps 'paired' apps that work together? I expect there are limited use-cases, but it might be a way to combine benefits and mitigate the short-comings of the two frameworks.
  5.    #25  
    Quote Originally Posted by Preemptive View Post
    My question is: As it's all basically javascript, is it possible to make a hybrid mojo / enyo app?
    It might be, but in my (limited) experience, the Mojo lifecycle is very fragile. For example, while its possible to launch a Mojo app without a default HTML window (noWindow:true in the appconfig.json) doing so breaks everything. I suspect that since the Mojo and Enyo templates are different, it would take some real effort to get them both to load happily. There's also the possible issue of name collision, since Javascript doesn't have namespaces.

    Stopwatch 0.1.3 Released
    This release updates some common code bits, improving consistency with patterns in Night Moves. As an (intentional) side-effect, this addresses some re-launch issues when the countdown timer completes.

    Download it here:
    Preemptive likes this.
  6. #26  
    Quote Originally Posted by Preemptive View Post
    is it possible to make a hybrid mojo / enyo app?
    Apps that had a single ipk for phones and Touchpad were sometimes both Mojo and Enyo (e.g.: com.preciouscoders.pre.auctionmate_2.0.5_all.ipk) but the two do not interact and in that case, do not even share images as far as I can tell. In that case index.html defaults to enyo.html, but tests webOS version with:
               if (majorVersion < 3 ) {
                    app = "mojo.html";
    Once the app is specified with either enyo.html or mojo.html a completely enyo or completely mojo version of the app is loaded.
    I don't think mixing the two within the same actual app instance would work or fix any of the shortcomings of either framework.
    jonwise80 and Preemptive like this.
  7.    #27  
    Stopwatch 1.0.2 is Released

    This version handles re-launches in the stopwatch (count up) scene, in the same fashion as the timer (count down) scene. Meaning, both counters are durable, even when the app is killed.

    Stopwatch now counts to 599999999 milliseconds, and stores laps between re-launches. If the stopwatch is stopped when the app is killed, the last time will be added to a new final lap, so you can review historical stats.

    Timer alarms works on Touchpad and Pre, even if the app is killed, and now allow the user to select the alarm sound from the ringtones folder using a FilePicker.

    I've submitted Stopwatch to Preware, but until it gets approved, you can pick up the latest on GitHub:
    Last edited by jonwise80; 12/15/2018 at 10:52 AM.
  8.    #28  
    Stopwatch 1.0.3 Released

    • Fixes a bug in timers over 2 hours where the minutes weren't correctly calculated.
    • Finished a 599999999ms (166 hour) test run, confirmed stopwatch starts and re-starts as expected.
  9.    #29  
    Stopwatch 1.0.4 Released
    • Timer done notifications in MyWatch
  10. #30  
    Great to see this thread turning into a developers course for beginners! Just what I need for 2019 after blowing new life (WebOS 2.2.4) into my refound Veer.
    Last edited by Rob Vousten; 01/01/2019 at 01:54 PM.
    jonwise80 likes this.
  11.    #31  
    Glad to have someone else tinkering!
    Here's some other active threads with some resources:
    - Documentation:
    - IDE Integration (VS Code):

    Thought I'd post a pic of my environment, just for fun!
    Misj', Rob Vousten and gazaud like this.
Page 2 of 2 FirstFirst 12

Similar Threads

  1. My Pre 3's days are numbered
    By elvispre in forum HP Pre 3
    Replies: 34
    Last Post: 12/03/2018, 03:05 PM
  2. webOS Collection for sale!
    By Aeatherion in forum Marketplace
    Replies: 4
    Last Post: 11/13/2018, 06:55 AM
  3. LG WebOS 4.0 is rolling out for 2018 models.
    By akitayo in forum LG webOS TV
    Replies: 2
    Last Post: 10/14/2018, 02:35 AM
  4. WebOS 3.5 to WebOS 4 OLED55B7V
    By DroYze in forum LG webOS TV
    Replies: 0
    Last Post: 09/12/2018, 07:48 AM
  5. WebOS Ports Down?
    By Firepower in forum LuneOS
    Replies: 1
    Last Post: 09/03/2018, 05:40 AM

Tags for this Thread

Posting Permissions