Implement Console tab about stetho

[jasta]

@potyl I noticed your fork working on this. Any chance you're interested in collaborating? We started a crude version of this based on bsh (http://www.beanshell.org/) but are not married to it.

So far we're considering this an optional dependency so folks may be able to select their preferred runtime (or none at all if they want a small APK). Stetho would detect this dynamically and use it if available or provide a help message in the console if not.

[potyl]

I didn't noticed that there was a ticket about this. I started trying to add a REPL to stetho, my idea is to have this generic enough so that any interpreter language could be added to stetho.

As a proof of concept I started with adding a groovy REPL but this turned out to be quite difficult because groovy generates highly optimized JVM bytecode and Dalvik (or ART) require DEX bytecode. I got it to work by using grooid but this is too slow. I will need to contact the groovy team to see if it is possible to run in full interpreted mode.

I then switched to Mozilla's Rhino, a JavaScript REPL. That one does work better as we can run in full interpreted mode.

What's left provide a better way to hook into the Runtime module so that we can plug in any runtime. My way is kind of hackish and extending Runtime seems to be quite difficult. Whatever I did to try to plug in my own runtime always ended up breaking stetho. At the end I opted for adding a 'REPL' instead to the runtime module.

I also need to find out how to return proper data structures (objects / arrays) to chrome's console. I can return simple types just fine, complex types are another thing. I haven't found the full spec for the return types.

I will be glad to join, specially that I will be needing help as how to integrate a plugable REPL to steho.

[jasta]

I took a look at your code and I like your idea of generalizing only the REPL not Runtime (Runtime has some non-REPL stuff in it that we should keep as-is). We've tested internally with bsh and know that it works and is relatively small (by comparison to, for instance, Groovy). It does work though the syntax is not exactly greatly. We don't have a PR for this up yet though as it's still highly experimental on our side as well.

Note that we added recent support for complex object visualizations in 1.1.0 to support the Properties sub-tab in the Elements main tab. This requires generic object visualization and that code can be found in the Runtime module, specifically Session#objectForRemote. This takes care of all the strong referencing and all that as well which is nice.

We haven't done much work in this area lately so your stuff looks to be advancing ahead of our approach. I'd love to latch onto what you're got cooking so far and get things baked enough to land in master.

[jasta]

Oh, one final note, we've been working on an extensibility API improvement that allows you to configure some details about each module in the DevTools. This would be a nice opportunity to declare the REPL you want to use. For now, your approach of accepting it via the constructor will do fine though.

[potyl]

I had a bit of time to spend over the weekend. I rebased my branch with the current master.
Return types are now working without I having to do any marshalling by hand. Binding works but is now limited only to the application context.

I would like to know what's the suggested way for adding REPL factory the runtime? For now I have to walk through defaultInspectorModulesProvider's modules find the runtime and substitute it with a new runtime that will have the desired REPL. Finally I need to create my own InspectorModulesProvider with the new list of modules.

Would it be ok to add a enableRepl(RuntimeReplFactory) method to the InitializerBuilder?

[potyl]

My first implementation of a JavaScript REPL is done. What i wanted to achieve is now done:

• javascript expression
• evaluation of statements preserved between calls
• variable, class, package and function binding
• console integration

There's still more to do like to integrate with the views (perhaps having a $() like in jquery). Better console object, more goodies.

I have made a pull request (#188) it fails to pass the Travis CI build but the first error is related to stetho-okhttp which I haven't touched.

[jasta]

@potyl thanks so much for doing this work. Really excited for the next release :)