Fix sample project #79

wants to merge 2 commits into


None yet
2 participants

The sample project created by "lein droid new" had problems that took me about 5 hours to track down and resolve.

These commits now allow the sample project to compile and run.

And closes clojure-android/neko#4

This is strange, Ken, because I can build projects without this line. My java version is 1.7.0_45, Android SDK Tools 22.3 and Build-tools 19. I removed this line because at some point it actually broke the build for me and other people. So I have to investigate it a little more. Can you make sure that your Clojure setup and Android tools use the same version of JVM? Someone had the similar problem, when he had two different JVMs installed and accidentally used both of them.

As for the second patch: this :def thing is confusing, yes, but your commit just removes its usage altogether. I'll try to explain again: as for now, :def only works in debug mode to help you write. It binds the activity instance to the symbol provided to :def (in this case - a). In release mode, :def doesn't work at all, so before releasing you should replace all usages of a with activity instances passed properly. Here's short example.

Debug mode:

(defactivity .......
 :def a
  (fn [this bundle]
    (.someActivityMethod a)

(defn do-something []
  (.doSomethingOnActivity a))

Release mode:

(defactivity .......
 :def a    ; You can leave this, but it is just ignored in release
  (fn [this bundle]
    (.someActivityMethod this)
    (do-something this)))

(defn do-something [activity-instance]
  (.doSomethingOnActivity activity-instance))

Does it make more sense now?

Thanks, I ended up figuring out the :dev versus this. But I'm sure it will bite others. I solved it by not putting the a var anywhere in the source code, just using this instead, and only relying on the a var when playing around in the repl. I'd suggest changing the source of the sample project to use this, but perhaps leave the :def there, for use in the repl, so that anyone compiling for release won't get thrashed by it. Or, perhaps, a more informative error message might help, not sure.

As for the 1.7/1.6 issue, yes I have several JVM's installed. But I'm using debian update-alternatives so that any invocation of "java" will hit the correct version. Still, it's possible that the Android tools are hard-coded somehow to a particular version of java that is different from the /usr/bin/java[c] that leiningen is using. Thanks, I'll look into this.

I've just beta'ed a simple Android app written in clojure. It was far more pleasant to do than any other Android projects I've done in java. So thanks again for neko and lein-droid!

I guess, you are right. I should modify the sample or make the error more informative. I will try to figure out how this should be done.

For the JVM version part, it appears that you are not alone with the same problem: #81. It have to run another set of compatibility tests, but seems like the :javac-options line really belongs to project.clj again.

And I'm glad you like developing with Clojure! I'll do my best to keep the experience positive.

OK, I think both questions in this issues were solved. :javac-options is now back in default project.clj; and I've added a paragraph to the wiki describing why and how one should give up using globally bound Activity instance in release builds: . There is also a link to it in the Tutorial. Do you think this is enough to prevent people from tripping over it?

Fair enough. I'd still suggest not using "a" in the sample project, but using "this" instead, and letting your note in the wiki cover letting people know they can use "a" for playing around in the repl in dev mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment