Mark Bauer wrote:
In rhosimulator, every time a file is required, I believe it is reloaded.
Why do you think that? I would think that would break almost any application. Is there some documentation that states this?
require is supposed to run the code in the required file only if it has not been previously required. Doing something else would fundamentally break just about every library.
I can't comment on rhosimulator, since I don't use it. (I only use official platform simulators, not Rhosimulator. I find it too far from a realistic environment.)
My thoughts are based on testing I have been performing, here are screen shots of a sample app that I built to demonstrate what I am seeing.
Simple test class
Given the above code, I am expecting to see 'test' for @test_var the first time, and 'Test round 2' upon refresh. This however is not the case in rhosimulator. The value for @test_var is 'test' every time. When performed outside of rhosimulator I receive the results I expect.
The work around we have been using is to require anything with a class variable in application.rb, which eliminates the issue, but it would be nice if we could require in the files that are going to utilize the classes.
Thanks for the response,
That certainly seems broken! Did you file an Issue on Github?
For iOS and Android you can even do remote JS/HTML/CSS inspection and debug, using a USB cable and a desktop browser. (For iOS, use Safari on OS X, for Android use Chrome.) I often use this for iOS apps.
I did not file an issue, as I understood this to be a feature, not a bug (see original post for my reasoning). How would I proceed on finding out if this was intentional? Is Github the correct outlet?
Yes, GitHub is the correct outlet.
Can you point us to the docs that talk about this "feature"?
There is a separate project on GitHub for the docs, if there is some issue with the docs.
This is the doc that led me to believe this behavior was intended, although I definitely did make a logic leap to get there.
I have submitted an issue on the rhomobile/rhodes GitHub
1 of 1 people found this helpful
I would not make that assumption from reading that documentation. I am certain it is a bug, and not something done to support RhoSimulator.
I think you are referring-to this:
The Web Inspector lets you modify your page and styles live. This provides a quick way to try out HTML and CSS changes to see how they look without having to go back to RhoStudio (or other IDE), providing you with very fast feedback and avoiding the tedious edit-save-refresh cycle.
This has nothing to do with Ruby code at all. In fact, the Web Inspector isn't even a part of RhoStudio! From the documentation (realize I don't use RhoStudio...) I see it is just Safari Web Inspector.
You can do everything shown in the RhoSimulator docs directly in Safari. You can even do it with a real device.
The "live" editing is all within the UIWebView itself. It modifies the CSS, HTML, and JS loaded into the DOM of the browser control.
Unless you need the Ruby debugging capability, I would avoid RhoSimulator. Do a command-line build, and use the iOS Simulator, which is a much more accurate device simulation than RhoSimulator. It does take some more time to build, but it is quite reasonable on a fast Mac. (I build a HUGE projects of ~1000 files in 30 seconds on a high-end Mac Mini.) then, you can use desktop Safari to inspect/debug either the iOS Simulator or a real device connected by USB.
If you are creating an app for Android, Chrome has similar remote-debug capabilities. Minimum OS requirement for remote debug with iOS is 6.0, for Android is 4.0. You use the latest corresponding desktop browser and may have to enable a developer menu.
I don't believe that RhoSimulator supports "live" changes to Ruby code:
RhoStudio will, by default, switch to the ‘Debug’ perspective, and it will establish a connection with RhoSimulator so that you can:
- Set breakpoints.
- Step through code.
- Inspect variables when the application is stopped at a breakpoint in the Variables window.
- View log messages in the Console window.
BTW, you may be interested that I do something similar to your pre-loading, but for different reasons. I pre-load all commonly-used modules, all models, and all controllers. (I do not pre-load templates, but that might also be a useful option.) It is a combination of a list of modules to load (in a YML file), and finding models and controllers dynamically.
I like the idea of just getting everything loaded up front and getting it out of the way. It's a bit of a "pre-flight check" in that you will find out if any module does not load (it logs that and displays an error page, and so the app should not get past even the most simple testing if there is some problem) or if some module throws an exception during loading. It also means that I don't have to sprinkle the app with require statements.
What is given up, though, is incremental loading of code. It immediately loads all of the code and so will immediately use the memory needed to hold that code. It would not be a good approach for, for example, a graphical editor, which might have dozens of effects that a user might never use. It is good for the case I am using it for, which is a very large form-fill app, where the user will hop around a bunch of forms and most likely visit most or all of them.
The part that made me think it was a feature was
"Once your application is running under RhoSimulator, you can make changes to your source files and just press ‘Refresh’ to see your changes live, i.e. generally no RhoSimulator restart is required. The restart of RhoSimulator is required only if a model was added/modified or some code was changed in the
I understand that web inspector is not part of RhoStudio. I also do not use RhoStudio, I run rhosimulator from the command line in a script I wrote.
On the topic of your preloading idea, I like the concept of getting all of the loading "over with".
Our apps run on rugged terminals running winxpe in a plant environment. It's a jump from the average rhomobile use case, but has worked out quite well for us, and in the future we like the flexibility of having the option to go to an android terminal.
Thanks again for all of your input,
P.S. I am envious of your development environment. Developing on a modern unix-like OS is something I don't have the opportunity to do at work =).