Fork me on GitHub

Interesting. Why would it be difficult to drive Xamarin.UITest with Clojure CLR? I’ve never used it, but I would assume you could do anything via C# interop just like you can in JVM Clojure?


That’s what I assume too, but looking at this blog post, it seems like the author never managed to get it going (just the plain Xamarin, not the test library Xamarin.UITest): But then this post seems encouraging: Having said that, I see a lot of people have asked about Xamarin usage with ClojureCLR on their google group with not a lot of positive answers. I’m still digging to see if anybody has already done this before trying it out for myself. What I’m hoping is that if Xamarin itself can be used, that Xamarin.UITest is separate enough from the IDE/tooling that it can be used as a standalone library.


Progress. Got it working, but it’s a bit hairy. When you said > I would assume you could do anything via C# interop just like you can in @joshmiller it’s partly true: since there isn’t as many devs using, the workflow is a bit unpolished. But it could also be the fact that I’m completely unfamiliar with it.


:thumbsup: Makes sense. So the idea is that it’s probably technically possible, but nobody’s done it yet so who knows the work load in getting it going.


Oh, it’s fully possible to do it. I just don’t know the CLR workflow to get it going cleanly via leiningen/deps. And by that I mean: load the Xamarin.UITest DLL before requiring it in a ns declaration. I’ve done it at the REPL so I know it works. I can load the app, and it starts in the emulator from Clojure CLR REPL. It’s just “packaging” it in a straightforward way.


Ideally, I’d like to be able to have a single config project.clj which would be the main application (the mobile app) and also contain the tests via Clojure CLR. I think that packaging the test suite as a separate repo is more likely.


Aha, makes sense.


copied from #re-natal, probably more appropriate here: has anyone created a working, batteries included sample project using there are instructions in the README there for setting up a dev environment and targeting iOS; I'm trying to gauge how much work is involved in getting things working similarly on Android and producing production builds. Any insight appreciated.


When I last tried it it didn’t work. The core of the issue is in its dependency on figwheel-repl, which uses this paradigm in a lot of places:


The code block in the :node case still appears in the react native source. Before loading code, react-native tries to traverse the AST and find any statements that look like require("some-lib"). If it finds one, and the string inside doesn’t exactly match a library in node_modules or some other source file, it will fail to bundle


Here’s the react-native issue where they discuss dynamic require statements, and why they restrict them:


That should only be a problem with production builds, right? As long as you exclude figwheel from those, you should be ok.


It’s both, because the bundler is ultimately what gets your code on the simulator. It’s CLJS -> JS -> .bundle -> sim-or-phone in both dev and prod


The babel plugin runs in all environments, as far as I can tell


it works fine in dev with the instructions given in react-native-figwheel-bridge (and it's a great experience)


however to your point @joshmiller it involves calling figwheel code in the JS application bootstrapping file:


var figBridge = require("react-native-figwheel-bridge");

figBridge.start({appName:   "MyAwesomeProject",
                 optionsUrl: ""});


I think the difference between dev and non-dev in metro/babel is that it doesn’t attempt to do any rewriting in dev, so the dynamic requires don’t trip it up.