[scala-ide-user] Scala 2.8 + Android 2.1 + Eclipse

[Kevin Wright]

Sorry if cross-posting means that anybody gets this twice...

I was able to put together (over lunchtime) a solution to the problem :)

Write-up is here: http://scala-ide.assembla.com/wiki/show/ae55a-oWSr36hpeJe5avMc/Developing_for_Android

All feedback welcomed!

--
Kevin Wright

mail/google talk: kev.lee...@googlemail.com
wave: kev.lee...@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

[Jeremy Bell]

I tried these instructions and the build failed on step 2a, after typing ant install (before adding scala nature to the project).

My system: 

Windows 7, 32-bit

latest eclipse, android, apache-ant, android-sdk, android eclipse plugin, scala 2.8 RC1 + 2.8 RC1 eclipse plugin.

C:\Users\me\workspace\ScalaTest2>ant install

Buildfile: C:\Users\me\workspace\ScalaTest2\build.xml

    [setup] Project Target: Android 2.1

    [setup] API level: 7

-compile-tested-if-test:

-dirs:

     [echo] Creating output directories if needed...

-resource-src:

     [echo] Generating R.java / Manifest.java from the resources...

-aidl:

     [echo] Compiling aidl files into Java classes...

compile:

    [javac] C:\Users\me\workspace\ScalaTest2\build.xml:304: warning: 'incl

udeantruntime' was not set, defaulting to build.sysclasspath=last; set to false

for repeatable builds

    [javac] Compiling 1 source file to C:\Users\me\workspace\ScalaTest2\bi

n\classes

   [scalac] Compiling 0 scala and 1 java source files to C:\Users\me\works

pace\ScalaTest2\bin\classes

   [scalac] Compiling 0 scala and 1 java source files to C:\Users\me\works

pace\ScalaTest2\bin\classes

proguard:

 [proguard] ProGuard, version 4.4

 [proguard] Reading program jar [C:\Users\me\workspace\ScalaTest2\bin\clas

ses:tools\scala-library.jar] (filtered)

BUILD FAILED

C:\Users\me\workspace\ScalaTest2\build.xml:330: Can't read [proguard.Class

PathEntry@abe654] (No such file or directory)

Total time: 5 seconds

C:\Users\me\workspace\ScalaTest2>

[Kevin Wright]

Not sure how much difference it makes, but I'm using the proguard 4.5 beta

[Kevin Wright]

A bit more information here for anyone who's encountered snippets of information about "3rd-party libraries" in later versions of Android, I've investigated and found this:

    http://groups.google.com/group/android-platform/browse_thread/thread/618971d3f7608f4c/2e15c8be7abca1e4

discussion on how to create a platform library.  Unfortunately the README.txt file in the mention project states that:

"This example is ONLY for people working with the open source platform to
create a system image that will be delivered on a device which will include
a custom library as shown here.  It can not be used to create a third party
shared library, which is not currently supported in Android."

So I'm afraid that we're out of luck if anyone had hoped to take that approach

(unless we roll our own Android distribution, it worked for CyanogenMod)

[Stefan Langer]

If someone has a workable scala library for Android we could send it
to google as a patch for android and get it into the official
distribution maybe?

-Stefan

2010/5/5 Kevin Wright <kev.lee...@googlemail.com>:

[Kevin Wright]

The one big glaring elephant in the room is:

Do we want to do this for a trunk build of a shared library where binary compatibility is fragile, at best

It only makes sense to go with a shared lib if multiple scala apps will be installed, but in this case they would all need to be rebuilt and redeployed every time the Scala lib itself is updated.  This is also a problem with Scala 2.8 vs 2.8.1, etc and not just unique to anyone working on the bleeding edge.

On 10 May 2010 05:25, Ray Racine <ray.r...@gmail.com> wrote:

This has caught my interest this evening after I came back Ironman II and googled for a bit.  I haven't tried any of this yet, but I'll give it a whirl tomorrow after work.

The following may work for messing around.  It would not be a comprehensive solution however for general app development and distribution for android with scala.

1. I think you can add a pure jar, such as the scala-library.jar, by first starting the emulator and then sending over the prepared jar file and the xml permissions file via an adb push.  However you would have to do this every time the emulator was fired up, but not too bad.

2. However, it may be that the jar and xml file may need to be present at startup.  So the trick would be to get it into the system.img.  The following link discuz-android.blogspot.com/2008/01/customize-google-android-systemimg-for.html shows how to create a new system image, from a running emulator image.   Sounds like it goes something like this:

 a) Start up a vanilla emulator image.

 b) adb push the xml, scala lib jar and the mkfs.yaffs2 utility into the running image.  

 c) Use adb shell to log into the emulator image and create a _new_ system.img inside the emulator of the emulator's /system tree.  

 d) adb pull the newly created system.img that now has the scala lib in it back on to your pc.

At this point the idea would be to try to swap out the system.img in the base emulator with this new image.  When you restart it you now have an emulator with a linkable scala-library in it.   Another idea is to clone the add-on tree in the SDK and tweak the xml files ... to create a new add-on which is "scala ready" for android development.

One still faces the problem running the app on a "real" phone/tablet.  If the above works I don't see why one could not do it on a "rooted" android.  Not sure, yet, on a non-rooted.  If /system/framework isn't writable to non-root for example it would be trouble.

Ray

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

[James Moore]

On Mon, May 10, 2010 at 12:03 AM, Kevin Wright
<kev.lee...@googlemail.com> wrote:
> The one big glaring elephant in the room is:
> Do we want to do this for a trunk build of a shared library where binary
> compatibility is fragile, at best

I don't think it's interesting for production, but it might be for
development. If it means you could skip the proguard step every time,
that'd definitely speed up the development cycle.

--
James Moore
ja...@restphone.com
http://jamesmoorecode.blogspot.com/

[Kevin Wright]

Just for running on the emulator you mean?

It's definitely an interesting idea, and shouldn't even be too hard to sort out a variant of scala library without the reflective bits that android can't deal with.  I'm putting this one on my "to be investigated" list for when 2.8 final comes out.

[Jeremy Bell]

I'm not very familiar with the scala library's build setup - does it support profiles? If so we could just add profiles for android, or a more general "scala-light" profile that might apply to other exotic runtime environments besides android. It wouldn't solve the android problem completely, but might make it easier to develop for android, knowing that nothing in the library you're linking to is incompatible with the dalvik runtime. Plus, it's probably easier to maintain than the separate scala-android.jar distribution through sbaz.

[Kevin Wright]

For scala 2.7.x, there was a custom build of the scala library being offered, called "android-library.jar"

The only difference was that it just removed all code from scala.reflect.ScalaBeanInfo - You can still see this in the android-library directory of the current scala source.

Problem is, I don't why it had to be removed, or how much of the underlying issue was down to Scala, or to older versions of Android.  As the current trend is to use proguard nowadays I've not let it worry me too much :)

On 10 May 2010 16:30, Johannes Rudolph <johannes...@googlemail.com> wrote:

On Mon, May 10, 2010 at 4:59 PM, Kevin Wright

<kev.lee...@googlemail.com> wrote:

> Just for running on the emulator you mean?
> It's definitely an interesting idea, and shouldn't even be too hard to sort
> out a variant of scala library without the reflective bits that android
> can't deal with.  I'm putting this one on my "to be investigated" list for
> when 2.8 final comes out.

As an aside: What are those 'reflective bits that android can't deal
with'? I never came across those as long as I didn't try to generate
code (obviously).

And yes, I think for debugging purposes using a shared library would
in fact be interesting.
--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[sorenbs]

Using ant 1.8.1 and scala 2.8R2 on win 7 64 I got the following error.
raplacing the colon(:) on line 327 with a semicolon(;) made i t work.
I am no ant pro, so this might be nuts.

BUILD FAILED
C:\Users\sorenbs\android\airCommander\build.xml:327: Ca
s\android\airCommander\bin\classes:tools\scala-library.
T.MF,!library.properties)] (No such file or directory)

On 5 Maj, 16:15, Kevin Wright <kev.lee.wri...@googlemail.com> wrote:
> Sorry if cross-posting means that anybody gets this twice...
>
> I was able to put together (over lunchtime) a solution to the problem :)
>

> Write-up is here:http://scala-ide.assembla.com/wiki/show/ae55a-oWSr36hpeJe5avMc/Develo...

>
> All feedback welcomed!
>
> --
> Kevin Wright
>

> mail/google talk: kev.lee.wri...@googlemail.com
> wave: kev.lee.wri...@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda

[Kevin Wright]

Ahh. The old classpath separator!

Yes, you are quite right to spot that this is different on Windows systems than on Mac/*nix

Shame on Microsoft for their crazy drive letters and path conventions...