Results 1 to 6 of 6
  1. Genek's Avatar
    Posts
    4 Posts
    Global Posts
    16 Global Posts
       #1  
    Hi I have some dev related questions I'm hoping someone can help me out with.

    1) Is it really necessary to have includes for anything other then mojo.jsjsjs $in$ $the$ $index$ $file$? $I$ $have$ $noticed$ $many$ $apps$ $don$'$t$ $have$ $this$ $and$ $in$ $my$ $testing$ $it$ $seems$ $that$ $they$ $built$ $in$ $a$ $call$ $for$ $the$ $assistant$ $files$ $anyway$. $Even$ $if$ $I$ $don$'$t$ $have$ $these$ $includes$, $my$ $stage$ $loads$ $with$ $the$ $first$ $scene$.

    2) I started writing an app before I got my hands on the SDK and needless to say, a large chunk of my .jsjsjs $doesn$'$t$ $work$ $when$ $inside$ $the$ $Mojo$ $framework$. $Specifically$, $I$ $have$ $a$ $pop$-$up$ $with$ $an$ $input$ $field$ $that$ $comes$ $up$ $when$ $you$ $click$ $a$ $certain$ $area$ $of$ $the$ $screen$. $The$ $input$ $in$ $this$ $pop$-$up$ $is$ $directed$ $into$ $the$ $clicked$ $field$. $WebOS$ $doesn$'$t$ $support$ $the$ $traditional$ $pop$-$up$ $in$ $an$ $app$. $My$ $question$ $is$ $this$...$can$ $I$ $just$ $throw$ $my$ $functions$ $for$ $this$ $into$ $a$ $Mojo$ $notification$ $pop$-$up$ $as$ $a$ $wrapper$, $and$ $just$ $onFocus$ $call$ $that$ $wrapper$?

    3) Kind of a continuation of 2. In general, if I take existing code and try to convert it to work with the Mojo framework, what is the best practice? Can I in fact place wrappers around my existing functions then pass my arguments and calls via the wrappers? Or, is the best practice to simply go through the code line by line and rewrite as needed to best fit the Mojo framework?

    Thank you in advance for any help and direction anyone can offer. And a huge thanks to PreCentral for having this amazing community!!!
  2. #2  
    re 1) -- the only incldue required in index is to mojo. Everyting else happens from sources.json.

    UNLESS you're depending on a second jsjsjs $library$ $like$ $jquery$ $or$ $yui$.

    Re 2) you can use mojo wrappers for some things, but can not use them for others.

    Obviously alerts need to be replaced with mojo.dialog.alert and errors with mojo.dialog.error.

    That's a conversion, not a wrapper, since the mojo elements require some setup in the assistants.

    Best practice is convert to mojo, since otherwise you're adding a mis-direction layer.
  3. Genek's Avatar
    Posts
    4 Posts
    Global Posts
    16 Global Posts
       #3  
    Thanks! With regards to sources.json. I've seen it formatted with an indicator which jsjsjs $is$ $for$ $which$ $scene$, $and$ $I$'$ve$ $also$ $seen$ $it$ $with$ $only$ $a$ $reference$ $to$ $the$ $assistants$ $and$ $no$ $scene$ $reference$. $Does$ $mojo$ $limit$ $the$ $scope$ $to$ $a$ $specific$ $scene$ $when$ $that$ $is$ $mentioned$? $I$ $imagine$ $unless$ $you$ $know$ $you$ $will$ $only$ $use$ $a$ $certain$ $js$ $for$ $only$ $that$ $scene$, $it$ $probably$ $makes$ $sense$ $to$ $just$ $leave$ $that$ $line$ $out$ $so$ $you$ $can$ $access$ $your$ $js$ $within$ $the$ $scope$ $of$ $the$ $entire$ $app$ $and$ $not$ $just$ $a$ $single$ $scene$.
  4. #4  
    That's probably best. I have some classes that need to be accessed from various scenes, so I just leave out any scene designation for the jsjsjs $files$ $containing$ $those$ $classes$.
  5. #5  
    a slight variation from what you and blubble said.

    1) you need a jsjsjs $for$ $EACH$ $SCENE$ $you$ $have$. $Every$ $scene$ $needs$ $a$ $js$.

    2) you can ALSO have jsjsjs'$s$ $which$ $are$ $not$ $linked$ $to$ $a$ $scene$. $You$ $may$ $ALSO$ $include$ $them$ $in$ $the$ $sources$.$json$.

    k?
  6. Genek's Avatar
    Posts
    4 Posts
    Global Posts
    16 Global Posts
       #6  
    Quote Originally Posted by rboatright View Post
    a slight variation from what you and blubble said.

    1) you need a jsjsjs $for$ $EACH$ $SCENE$ $you$ $have$. $Every$ $scene$ $needs$ $a$ $js$.

    2) you can ALSO have jsjsjs'$s$ $which$ $are$ $not$ $linked$ $to$ $a$ $scene$. $You$ $may$ $ALSO$ $include$ $them$ $in$ $the$ $sources$.$json$.

    k?
    Yep this makes sense. Each scene name has to have a .jsjsjs $with$ $the$ $same$ $name$ $that$ $is$ $an$ $assistant$. $I$ $was$ $referring$ $to$ $the$ $not$ $always$ $used$ $2nd$ $line$ $of$ $each$ $assistant$ $reference$ &$quot$;&$quot$;$scenes$&$quot$;: &$quot$;$first$&$quot$;&$quot$;. $This$ $looks$ $like$ $it$ $specifically$ $tells$ $mojo$ $that$ $this$ $script$ $should$ $have$ $it$'$s$ $scope$ $limited$ $to$ $only$ $the$ &$quot$;$first$&$quot$; $scene$. $What$ $we$ $are$ $saying$ $is$ $you$ $can$ $leave$ $this$ $out$ $and$ $your$ .$js$ $will$ $be$ $available$ $anywhere$ $in$ $your$ $app$. $Interesting$ $thing$ $is$ $that$ $it$ $looks$ $like$ $every$ $sample$ $app$ $that$ $Palm$ $has$ $in$ $the$ $SDK$ $does$ $not$ $use$ $this$ $reference$, $so$ $it$ $would$ $be$ $interesting$ $to$ $find$ $out$ $in$ $what$ $cases$ $you$ $would$ $want$ $to$ $use$ $it$.

Posting Permissions