Java Live Error: How do I make Android projects work ?

[jporkkahtc]

What needs to be set to make Slick edit recognize the Android classes?

Slick automatically found and built a tag file for the JDK.
It did not do this for the Android SDK, so I manually created a tag file for *.JAVA in android-sdk\sources\android-15\...

This seemed to work, for a day.
But now, I'm back to having zillions of "Java Live errors" because none of the Android classes are recognized by java Live.  They are correctly tagged however, as I can hit "ctrl-." on an android class and Slick finds it right away.

In javaOptions, "Android" tab, I have the SDK path set to C:\\PROGRA~2\\Android\\ANDROI~1\. (Actually, I've set it to C:\Program Files (x86)\Android\android-sdk\ a couple of times but Slick seems to always revert to using the 8.3 equivalent path.

[Ryan]

Live Errors finds classes from the classpath for the project...so what you want to do is go to Build > Java Options > Classpath, click Add Jar File, browse to ...\android-sdk\sources\android-15\ and select android.jar.  Let me know if this fixes your issue.

Actually, I've set it to C:\Program Files (x86)\Android\android-sdk\ a couple of times but Slick seems to always revert to using the 8.3 equivalent path.

It's actually the Android tools which are converting the path...but it should still be accurate.

Hope this helps,

Ryan

[jporkkahtc]

Yes, that helps.
But then, what is the "Android" tab in the  JavaBuild options for ?

And why does it reformat the path so badly?
On my machine it always reformats to: C:\\PROGRA~2\\Android\\ANDROI~1\

[Ryan]

But then, what is the "Android" tab in the  JavaBuild options for ?

That is the Android SDK location where SlickEdit will look to find Android tools (android.bat, ddms, etc.) and also where it will look to find the platforms you have installed for your Android builds.  This location is stored in your project as the sdk.dir property in the local.properties file.  If you change this location in SlickEdit, SlickEdit will update that property for you.

And why does it reformat the path so badly?

After looking into this for a while...I'm not sure .  When you change this property, SlickEdit will update your project so that it is properly configured for the new SDK directory.  I remember seeing that when we would update the project it would reformat paths with spaces (if the SDK was in a path with spaces) to the 8.3 equivalent directory...but I previously thought it was the android.bat tool which was doing this.  I've been testing this though, and it doesn't appear to be the case.  For some reason when we are executing the command from SlickEdit, it is reformatting the path string...and when I run the same exact command from the command line it is not reformatting the path string.

I've fixed one bug where we might have thought the SDK directory had changed even if you didn't change it...but I am still looking into why when updating the SDK directory to a path with spaces the path is being reformatted as you are seeing.  I'll keep you posted.

- Ryan

[Ryan]

Ok...if you load the attached javaopts.e this should fix the problem of an SDK path with spaces being reformatted to the 8.3 equivalent path.  Try it out, let me know.  I'll make sure this is in the next hotfix.

- Ryan

[jporkkahtc]

Thanks -- that works, mostly.
It doubles up the "\" characters though:

C:\\Program Files (x86)\\Android\\android-sdk\

[jporkkahtc]

OK, this is no good.
When I try to run my android project I get this in the output window:
     Usage: vsandroidrun: Coming soon...

slick\win\vsandroidrun.exe seems to always print "Coming soon..." when it doesn't like its arguments.

[Ryan]

No...not good.  vsandroidrun is just the standalone utility that SlickEdit uses to launch Android apps on emulators or hardware devices.  The "Usage: coming soon..." message is just a placeholder indicating that we don't have a verbose usage message printing out for when the arguments passed to vsandroidrun are inappropriate.  We will get that in there for 17.0.1 for sure.

So the real problem is that the arguments passed to vsandroidrun are not correct.  Fortunately (or unfortunately, depending how you look at it) I have been able to reproduce this issue when I have the Android SDK location set to a path with spaces .  Sorry for the trouble here...this was definitely tested and somewhere along the line vsandroidrun must have gotten modified and the parsing of arguments is probably messing up when being passed a path with spaces.

If you like, as a test, you can create an Android SDK install in a path without spaces, and use that as your location...to see if this solves the issue.  I will figure out what the issue is and will see if we can hotfix either the SlickC code which is at fault or vsandroidrun itself, if it needs to be modified.

Thanks for the report and I'll keep you posted.

- Ryan

[Ryan]

I've gone ahead and made the appropriate changes to fix this bug.  We are going to be releasing 17.0.1 in the near future (which will have the fix), so I'm not sure if this is going to be added to the 17.0.0 hotfix or not...but I'm attaching the fix to this post so that you can go ahead and download it so that it isn't holding you up anymore.

The .zip file contains a new vsandroidrun.exe...and you can just back up your existing vsandroidrun.exe at PATH_TO_SE/win/ and copy the new one into this directory.  The .zip file also contains a new android.e which you can just load via Macro > Load Module.  Then you should be good to go.

Let me know if this works for you or if you have any additional problems.  Thanks for your patience.

- Ryan