Tutorials webOS Porting Older App - Revision history

Rsanchez1: /* Get the app working in a browser. */

2010-11-02T23:18:32Z

Get the app working in a browser.

Web0spl: /* Get the app working in a browser. */

2009-09-26T12:43:51Z

Get the app working in a browser.

Web0spl: /* Get the app working in a browser. */

2009-09-26T12:40:46Z

Get the app working in a browser.

Rboatright: walkthrough

2009-08-11T00:12:19Z

walkthrough

Rboatright: start example

2009-08-10T15:10:51Z

start example

Rboatright: /* Source Code Styling */ and one more time

2009-08-10T12:39:25Z

Source Code Styling: and one more time

Rboatright: more hand waving

2009-08-10T03:00:24Z

more hand waving

Rboatright: house style handwaving

2009-08-10T00:35:23Z

house style handwaving

Rboatright: /* [http://www.jslint.com/lint.html JSLINT will make you cry.] */ reword braces on if's to make it clear that it's not rboatright's opinion.

2009-08-09T04:17:05Z

[http://www.jslint.com/lint.html JSLINT will make you cry.]: reword braces on if's to make it clear that it's not rboatright's opinion.

Rboatright: /* Get the app working in a browser. */ Pre-pare

2009-08-09T03:30:47Z

Get the app working in a browser.: Pre-pare

@@ Line 19: / Line 19: @@
 * '''CSS Considerations''' --  Take this opportunity to move styling OUT of your html and INTO the css file.
 * '''Fonts''' -- The pre just doesn't have the web standard fonts.  All font calls on the Pre will be converted to Prelude.  So, just strip them out.  They're pointless.
 * '''Move JS into a separate file''' --  if scripts are embedded in the page holding your app, move them out to a "myapp.js" file.  When you move to the pre, you will include myapp.js in the sources.json file.  You '''can not''' include js in the scene.html file.  Or rather, you can,  but it won't actually RUN.
 * '''Eliminate document.write''' -- Document.write is deprecated in any html app. If the app your porting uses it, replace all the document.write commands with calls to do some sort of ''$('mydiv').innerHTML = something'' instead.  Document.write will screw up the whole pushing and popping scenes thing.  You just should not ever use it any more.

@@ Line 13: / Line 13: @@
 * '''Graphic size''' -- the Pre screen is 320px wide by 480 tall, but remember notifications will shrink YOUR part of the screen vertically.  Resize graphics to fit in 320px.   Be aware that the bottom of the screen is "fluid."
 * '''Control size''' -- targets (especially buttons) smaller than 25px square are all but impossible to hit with a finger.  45px is the suggested size.  35px works.  25px doesn't really work unless there is 10px or so of space between them, so why not use the 35px size as your minimum target.  Re-jigger your controls and graphics to allow that.
-* '''Control Interactions''' -- While you CAN hover over a control in mojo by holding your finger on the screen, you '''can not see what's under your finger''' so hover's are kind of useless.  Re think how to arrange hinting to eliminate hovers.
+* '''Control Interactions''' -- While you CAN hover over a control in mojo by holding your finger on the screen, you '''can not see what's under your finger''' so hovers are kind of useless.  Re think how to arrange hinting to eliminate hovers.
 * '''Graphic format''' -- the Pre wants graphics to be png.  Change all images to png.  ( Yes, gif's and jpg's will work.  No they are not the suggested graphic format for the Pre.  Take this opportunity to move to a format with real alpha transparency.
-* '''Graphic location''' -- Mojo wants you to put the images for you app in the images folder for the app.  When porting, run the web page off the local drive, create an images folder, and change source calls for your images to images/filename.png.
+* '''Graphic location''' -- Mojo wants you to put the images for your app in the images folder for the app.  When porting, run the web page off the local drive, create an images folder, and change source calls for your images to images/filename.png.
 * '''Page Layout''' -- many web apps put controls to the right or left of the application itself.  For a first pass, consider moving controls BELOW the app.  Eventually you may want to move all controls into menus, but for a first pass this works.
 * '''CSS Considerations''' --  Take this opportunity to move styling OUT of your html and INTO the css file.
 * '''Fonts''' -- The pre just doesn't have the web standard fonts.  All font calls on the Pre will be converted to Prelude.  So, just strip them out.  They're pointless.
-* '''Move JS into a seperate file''' --  if scripts are embedded in the page holding your app, move them out to a "myapp.js" file.  When you move to the pre, you will include myapp.js in the sources.json file.  You '''can not''' include js in the scene.html file.  Or rather, you can,  but it won't actually RUN.
+* '''Move JS into a separate file''' --  if scripts are embedded in the page holding your app, move them out to a "myapp.js" file.  When you move to the pre, you will include myapp.js in the sources.json file.  You '''can not''' include js in the scene.html file.  Or rather, you can,  but it won't actually RUN.
 * '''Eliminate document.write''' -- Document.write is deprecated in any html app. If the app your porting uses it, replace all the document.write commands with calls to do some sort of ''$('mydiv').innerHTML = something'' instead.  Document.write will screw up the whole pushing and popping scenes thing.  You just should not ever use it any more.
 * '''Worry about JS libraries''' -- unless you are a jQuery master, remember that the Pre automatically comes with the Prototype library.  This may conflict with calls to other libraries.  Be aware of that, and consider if that's what you really want to do.

@@ Line 12: / Line 12: @@
 * '''Graphic size''' -- the Pre screen is 320px wide by 480 tall, but remember notifications will shrink YOUR part of the screen vertically.  Resize graphics to fit in 320px.   Be aware that the bottom of the screen is "fluid."
-* '''Control size''' -- targets (especially buttons) smaller than 25px square are all but impossible to hit with a finger.  45px is the suggested size.  35px works.  25px doesn't really work unless there is 10px or so of space between them, so why not use the 35px size as your minimum target.  Re-jigger your controls to and graphics to allow that.
+* '''Control size''' -- targets (especially buttons) smaller than 25px square are all but impossible to hit with a finger.  45px is the suggested size.  35px works.  25px doesn't really work unless there is 10px or so of space between them, so why not use the 35px size as your minimum target.  Re-jigger your controls and graphics to allow that.
 * '''Control Interactions''' -- While you CAN hover over a control in mojo by holding your finger on the screen, you '''can not see what's under your finger''' so hover's are kind of useless.  Re think how to arrange hinting to eliminate hovers.
 * '''Graphic format''' -- the Pre wants graphics to be png.  Change all images to png.  ( Yes, gif's and jpg's will work.  No they are not the suggested graphic format for the Pre.  Take this opportunity to move to a format with real alpha transparency.

@@ Line 1: / Line 1: @@
 There is no shortage of open source license (mostly variations on mit) older javascript apps out there.  Games, calculators, sketchpads, whatever.
-A walkthrough example of this process can be seen at [[Tutorials_webOS_Porting_Older_App/example|the example page]].
+==A walkthrough example of this process can be seen at [[Tutorials_webOS_Porting_Older_App/example|the example page]].==
 == Before you start porting ==

@@ Line 1: / Line 1: @@
 There is no shortage of open source license (mostly variations on mit) older javascript apps out there.  Games, calculators, sketchpads, whatever.
-I have completed porting 4, and am working on an entirely new app (see the homebrew apps forum, prechess, scicalc and reversi at Precentral) and I have a few points to share.
+A walkthrough example of this process can be seen at [[Tutorials_webOS_Porting_Older_App/example|the example page]].
 == Before you start porting ==

@@ Line 28: / Line 28: @@
 : Together, they define a "house style" for the construction of Javascript programs.  It is entirely possible to construct well formed JS programs which do not use this house style, but by complying with it, your code will be very readable and easy to maintain.
 : Specifically, this style calls for K&R style braces ( { at the end of a line ), four space indents, braces around all conditional statements, no trailing ++ or -- ending lines, and no "optional" semicolons.
 : Feel free to ignore this advice, but don't come complaining to us.

@@ Line 26: / Line 26: @@
 : '''The next two sections describe using a combination of JSBeautifier and JSLINT to clean up and format your application.'''
 : Together, they define a "house style" for the construction of Javascript programs.  It is entirely possible to construct well formed JS programs which do not use this house style, but by complying with it, your code will be very readable and easy to maintain.
 : Specifically, this style calls for K&R style braces ( { at the end of a line ), four space indents, braces around all conditional statements, no trailing ++ or -- ending lines, and no "optional" semicolons. Feel free to ignore this advice,
 === Clean the app up. ===

@@ Line 22: / Line 22: @@
 * '''Eliminate document.write''' -- Document.write is deprecated in any html app. If the app your porting uses it, replace all the document.write commands with calls to do some sort of ''$('mydiv').innerHTML = something'' instead.  Document.write will screw up the whole pushing and popping scenes thing.  You just should not ever use it any more.
 * '''Worry about JS libraries''' -- unless you are a jQuery master, remember that the Pre automatically comes with the Prototype library.  This may conflict with calls to other libraries.  Be aware of that, and consider if that's what you really want to do.
 === Clean the app up. ===
@@ Line 37: / Line 43: @@
 ==== '''Why?''' ====
-Javascript has a lot of "bad things".  Some of these are also good things.  For example:  Javascript uses dynamically typed variables.  This is good.  You never have to cast.  On the other hand,  this is bad, since no one is checking if your variables are undefined.   JSLINT will produce a list of all your variables and functions at the bottom of its report, then, in future runs, if you paste that list into your script, JSLINT will look for mis-spelled variables and functions.  Of course, this happens only if it gets that far.  But you're going to have to clean code for "a while" before you get that far.
+Because javascript is not a compiled language, your code never gets the scrutiny that a compiler gives C or Java or even P-Code languages like Pascal and Foxpro.  You just submit it and try to run.  JSLINT provides the kind of code checking services that a compiler provides to a programmer.  In addition, JSLINT embodies Douglas Crockford's programming source code styling suggestions.
 ==== [http://www.jslint.com/lint.html JSLINT will make you cry.] ====

@@ Line 46: / Line 46: @@
 * Unless declared with a var command inside a function, variables in javascript are global.  Global variables are evil.  Let JSLINT find them and then you fix them.
 * Javascript is not fussy about where you put the {braces} around a code block. This is fine until the javascript interpretor inserts a semi colon for you between a function name and the brace.   JSLINT enforces K&R style formatting where { always comes at the end of a line, never at the beginning.  ('''Javascript is not Java.''')
-* Javascript is not fussy about braces.  The following is legal:
+* JSLint expects that if, while, do and for statements will be made with blocks {that is, with statements enclosed in braces}.
+*: JavaScript allows an if to be written like this:
-<code>
+<pre>
- if  (condition)
+   if (condition)
-    statement;
+       statement;
-</code>
+</pre>
-* Don't do it.  The problem occurs if you next try something like
+: Douglas Crockford, and the JSLINT community's position is that this form is known to contribute to mistakes in projects where many programmers are working on the same code. That is why JSLint expects the use of a block:
-<code>
+<pre>
- if  (condition)
+    if (condition) {
-    statement;
+        statements;
-    statement2;
-</code>
+</pre>
-which '''LOOKS''' like the two lines are part of the same if, but they aren't.  Always use braces with ifs.
+: Experience shows that this form is more resilient.
 * Javascript has two different equality operators == and ===.  Never use the former.  Always use the latter. The former does automatic casting in an attempt to help the novice programmer to get code that works,  but it follows weird rules that you will never be able to remember.  For example:
-<code>
+<pre>    0 == ""  '' true </pre>
-== ""  '' true
+: but
- but
+<pre>    "" == 0  '' false </pre>
 There is much more, please review http:''www.jslint.com/lint.html
@@ Line 77: / Line 69: @@
 If you need help debugging your app, doing as much as possible before moving to the Pre is useful.  The debugger for the Pre is currently broken.  So, do all the debugging you can on a browser.  Specifically, use firebug.  If you haven't used firebug in the past, and you've been writing javascript, you've been wasting a '''lot''' of time.  [http://getfirebug.com/ go get it now.]
-Everything worthwhile I know about javascript I learned from [http:''www.crockford.com/ Douglas Crawford].  .  If you do not own his book: [http:''www.amazon.com/exec/obidos/ASIN/0596517742/wrrrldwideweb Javascript: the good parts], run do not walk to get it.   If you are a programmer of some ''other'' language and need a quick, free overview ''right now''  take the time to read through [http://javascript.crockford.com/remedial.html Remedial Javascript].
+Everything worthwhile I know about javascript I learned from [http://www.crockford.com/ Douglas Crockford]. If you do not own his book: [http://www.amazon.com/exec/obidos/ASIN/0596517742/wrrrldwideweb Javascript: the good parts], run do not walk to get it.   If you are a programmer of some ''other'' language and need a quick, free overview ''right now''  take the time to read through [http://javascript.crockford.com/remedial.html Remedial Javascript].
 == Enough about javascript, I want to port this app.  ==

← Older revision		Revision as of 03:30, 9 August 2009
Line 6:		Line 6:

	=== Get the app working in a browser. ===		=== Get the app working in a browser. ===
		+
		+	'''But my app works in the browser already!''' Ok, then Pre-pare the app by Pre-fitting it to the new mojo environment it will be running in.

	Chances are, your app will need layout and css changes. Do them in a browser '''before''' you bring the code into the Pre. The following are things to consider:		Chances are, your app will need layout and css changes. Do them in a browser '''before''' you bring the code into the Pre. The following are things to consider: