3 Replies Latest reply on Jan 31, 2015 11:03 AM by Jon Tara

    defining Navbar action as javascript doesn't work

    Vishal Bhatia

      Hi all

       

      I am trying to use a Navbar control and defining one of its actions to call a javascript method. Although, the method doesn't seem to get called. Here is the snippet

       

      function myMethod(){

      alert('clicked');

      }

       

      Rho.Navbar.create({

            left : {

              label  : "Home",

              action : "Example Domain"

            },

            right: {

              label  : "Actions",

              action : "javascript: myMethod();"

            },

            title : "Hello app"

          });

       

      Although, if I just put the alert as an action instead of calling a method, it works', so this works

      Rho.Navbar.create({

            left : {

              label  : "Home",

              action : "Example Domain"

            },

            right: {

              label  : "Actions",

              action : "javascript: alert('called')"

            },

            title : "Hello app"

          });

       

      Any suggestions much appreciated.

       

      Thanks

      Vishal

        • Re: defining Navbar action as javascript doesn't work
          Jon Tara

          Using javascript alert() is a really bad idea. It stops the WebView cold in it's tracks until you close the alert.

           

          I try not to use javascript alert() for debugging, or for anything else. It can break your code that works. And it can miraculously "fix" your code that doesn't work!

           

          If you need to do some Javascript debugging, you can remote-debug with a desktop browser for either iOS (use desktop Safari on OS X) or Android (use desktop Chrome, but only with very new Android versions, I think only 4.4+).

           

          IMO, it is better to learn some Ruby and write code like this (e.g. creating a Rhodes native NavBar)  in a Ruby controller. Some may disagree, but the Javascript support in Rhodes is just a nice crutch in case you don't want to learn Ruby. It has many downsides. This is one. It adds an unnecessary layer of complication

            • Re: defining Navbar action as javascript doesn't work
              Mark Nongkhlaw

              Yep, hope Zebra doesnt go and 'spoil' further what was once (still is, and hopefully will still be) a great framework by adding more JS to it

                • Re: defining Navbar action as javascript doesn't work
                  Jon Tara

                  It's important to understand that Javascript running in a browser, while it allows asynchronous operations (JS itself is a functional language that makes it very easy to write asynchronous code) is implemented in a single thread. This introduces complications! You have to be careful not to block and not to hog the single thread.

                   

                  While there is a similar issue with Rhodes Ruby MVC, it is not as severe. While it is true that Rhodes Ruby controllers are single-threaded, when you use some API that is asynchronous, it actually proceeds in another thread. So, for example, your Network request proceeds in parallel, even though you might hog the controller thread with a bit of computation.

                   

                  That can still happen if you work in JS, IF the asynch API call actually got sent across to the Rhodes core.

                   

                  And, in Ruby, you have the ability (still only on SOME platforms, such as iOS) to actually use Ruby threads and write actual multi-threaded code.

                   

                  When you work only in JS, there are many gotchas to watch out for. It is limiting vs. the Ruby environment. It really just proxies into the core APIs, but you do have to make sure your JS doesn't step on it's own tail and prevent the calls from ever getting proxied in the first place. Then you get a result and it is proxied-back, and you have the same concern. Busy thread is busy thread.

                   

                  I have no quarrel with the existence of the JS APIs - if you don't need them, you don't have to use them. But if you do a large project in Rhodes, do yourself a favor, and learn Ruby.

                   

                  There is a very important use case for the JS APIs, and here you do not have a choice - you have to live with JS and it's limitations. That is when you want to change app behavior by downloading some code from a server. Most App Stores will not permit this with native code. For example, the Apple App Store simply does not provide a mechanism for this. If you want to update native code, you need to go through the entire app approval and update process.

                   

                  But JS code is not subject to this restrictions - at least not a technical one. I do think it is a grey area, and so you shouldn't get carried-away with it. I think that Apple will object if you make major changes to app functionality without going through the approval/update process. They allow you to change JS I think partly because there is no practical way to place a technical limitation on it, and because they really have an expectation that you will only use JS for UI. Even there, though, change your UI completely overnight, without an app update, and Apple notices... hmmmm....

                   

                  Apple is the most restrictive app store, others are more forgiving.

                   

                  I use a lot of JS in my code, but it is for dealing with UI issues that are very close to the user. I use it because it is appropriate for this. I can also see using the Rhodes JS APIs in limited circumstances where some functionality might have to change on-the-fly and so in specific situations on specific pages or parts of your app. You still have to not get crazy with it, to avoid alerting the Apple bloodhounds.

                   

                  I can see some scenarios where updating your JS in an App Store app without going through update/approval could easily create a "banned for life" situation. The most obvious that comes to mind would be to make changes via some downloaded JS that add some "phone home" capability that sends some private information (or any information, without disclosure). Apple will not have discovered that during the approval process, and now all of a sudden the app is sending some data somewhere that it was not doing when the app was approved.

                   

                  Boom! Bu-buy!

                   

                  That said, I would not be surprised to find that there are many PhoneGap/Cordova apps in the App Store that have done this. It is probably the biggest consumer risk on the App Store. I would equally assume that Apple keeps a close watch on PhoneGap/Cordova apps after approval. We are lucky in a way that we probably fly a bit under the radar.