|
|
10/06/2018, 09:29 AM
#1
Although the documentation is better preserved than some other "dead" platforms I've tinkered with, there's still a lot of gaps to leap between in trying to figure out how to get started. I figured I'd start a thread of my own foibles, in case it benefits anyone else who wants to try.
A couple resources I've found so far:
- The Wayback Machine SDK Archive is in decent shape.
- At least 172 pages of the original O'Reilly Press "Palm webOS: The Insider's Guide" can be found on Google Books. I also ordered a paperback copy from Amazon. Its pretty good at filling in the gaps.
- This tutsplus Introduction to webOS SDK tutorial has some good stuff.
Some none-obvious things that probably should be obvious:
- Mojo means webOS 2.x and earlier
- Enyo means webOS 3.x and seems to only ever have come to the TouchPad.
I decided to start with Mojo, and try to figure out how to make my apps scale well onto the TouchPad. Not sure if that's possible, but it seems like others have managed to target both big and little screens with a single .ipk, so there must be a way to do it without writing the code twice.
Goals
Other than adding to the community, there are a couple things I want my Pre to do that I can't find nice solutions for. Once I get through a "Hello World" I want to start with these two apps:
- Stopwatch: This should be a simple starting point. I use my iPhone stop-watch daily for exercises, and other than a sample from HP, I haven't found one for my Pre. I'm going to "take inspiration" from the iOS one, and try to make it beautiful and simple, while adapting to the webOS widgets and design language.
- Philips Hue Light Control: Obviously a little harder than a stop watch, but the Hue Bridge has a nice and easy-to-understand REST API. I've written sample apps for it in a dozen languages, and it requires no service-side access, so i can do it all in client-side Javascript -- which should work well on the Pre. I've got 4 light zones, and almost a dozen bulbs in my house, so it'll be worth the effort for me.
Neither of these will exercise NodeJS for back-end services on the phone. But I'll get to that later. I use Node every day at work, so I'm hoping that'll be an easy next step.
Observations (So Far)
Palm went really hard-to-the-hoop with their MVC implementation, and its a bit of a pain in the bum. Fortunately, the phone won't complain too much if you just start hacking with a simple webpage with some embedded script. But I want to learn their intent, and in general, I agree with the MVC pattern, so I'm slogging through. Newbie things I had to learn the hard way:
- The SDK documentation goes on ad-naseum about their app model, but all you really need to know is that your app's card is called a Stage. Apps that spawn multiple cards (like e-mail) have multiples Stages. Think of the Stage like a browser tab. Just like a browser, you can move between pages within a tab, in webOS those pages are called Scenes. You navigate between Scenes by putting them on-and-off the stack, much like the back-stack in a browser. Most simple apps need only one stage, but only the simplest will have a single scene.
- The index.html that the SDK generates for you is a stub. Its used for setup of the Stage, but you won't have content in there. Instead, your content goes into your Scenes, which are other .html files that are fragments. These get loaded into your Stage when the Scene is pushed forward.
- The Scene .html is used for layout only. Their pattern is not to put content in there -- you can, but that's not what the tutorials want. Instead, the SDK generates a supporting javascript file, called the Assistant. The scene HTML and Assistant have the same file name, but a different extension -- that's how the SDK knows they're related.
- The Stage has an Assistant too, so far I've only seen it used for pushing the default Scene on start-up.
- Inside the Assistants, you have to "setup" your widgets that you've previously laid out in HTML. This is a side-effect of their strict MVC separation and is a pain. In normal web development, putting something in the mark-up also instantiates it in the DOM. In Mojo, you have to do this manually. (The analogy that works for me is that its like the "code-behind" in ASP.NET -- only in that, VisualStudio does these things for you!)
- Once set-up, you also use the Assistant to bind your handlers to your widgets. You might have done this manually in Javascript, but here again, in simple HTML this would have been...simpler. Obviously you have to define your handlers as functions in the Assistant too -- before they can be bound.
Dev Environment
You can set-up as much or as little environment as you want. At a minimum, you need the SDK itself. This gives you the command line utilities to generate app and scene structures, to build your app, and to deploy it to an emulator or Developer Mode phone.
Once installed, the SDK comes with a bunch of sample apps and source code. The most useful one so far, for me, has been the UIWidgets one -- which helps learn what's possible within the UI.
I haven't tried the Eclipse plug-in, mostly because it requires a really old version of Eclipse that I haven't been able to hunt down yet. It doesn't seem like it adds a lot of value -- I like VisualStudio Code for web development, and this is pretty close. The command-line tools are simple enough to use too.
The emulator is strictly a nice-to-have -- you can get away with just having a phone. The emulator requires VirtualBox 4.0 or 4.1 -- but even within those versions, specific builds just refuse to start the VM. I finally went back to VirtualBox builds near 2011 (when the SDK was last updated) and got 4.1.0 r73009 to work, on Windows 7 32-bit, as long as VirtualBox was started "As Administrator."
Obviously Windows 7 32-bit is not an ideal environment in 2018, but I suspect if I decide to abandon the emulator and just develop against my phone, I'll have much more platform flexibility.
Update
I found that once you have a VM made and started once, on a supported version of VirtualBox, you can then move that VM over to a new version. I'm now running VirtualBox 5.2.20 (r125813) on Mac OS X Sierra and Windows 10, with emulator images of a variety of webOS builds. I'll start saving my VMs here, so others can skip this step:
https://1drv.ms/f/s!Av5IQUxnr8DUjN5XGv7M4B6-W1jRLg
Hello World
With these learnings behind me, I was finally able to lay out a Scene that did something when a button was pressed. It says Hello World, of course, but its a start. Important note, you must do your widget setups before you do your bindings. Here's the scene Assistant code:
Code:
WatchViewAssistant.prototype.btnOkHandler = function()
{
Mojo.Log.info("The OK button was pressed");
this.controller.get("watchViewSummary").innerHTML = "Hello world!";
}
WatchViewAssistant.prototype.setup = function() {
/* this function is for setup tasks that have to happen when the scene is first created */
/* use Mojo.View.render to render view templates and add them to the scene, if needed */
/* setup widgets here */
var watchViewTitleElement = this.controller.get("watchViewTitle");
var watchViewSummaryElement = this.controller.get("watchViewSummary");
watchViewTitleElement.innerHTML = "Jon is cool!";
watchViewSummaryElement.innerHTML = "This is my first app!";
Mojo.Log.info("Scene started!");
this.controller.setupWidget('btnOk', this.attributes={}, this.model={label:"OK", disabled: false});
this.btnOkHandler = this.btnOkHandler.bind(this);
};
HelloWorld.PNG
Next, I'll work on laying out my Stop Watch UI.
|
|
|
Originally Posted by jonwise80
