Question

Bit of an odd problem... I've been working with Android + Processing (see: processing.org) successfully in Eclipse on my linux box. The process for setting it up is simple (http://blog.onthewings.net/2013/04/25/setting-up-a-processing-android-project-in-eclipse/). On OSX, I'm having an issue popping up regarding asset loading (in both Eclipse and Android Studio), using a simple project as an example. Some quick background:

Linux: Ubuntu 12.04, ADT Build v22.0.5-757759, OpenJDK Java 6 - 32bit Processing/Eclipse.

OSX: Mavericks, ADT Build v22.6.2-1085508, 32bit Processing Lib. Java SE 6 [1.6.0_65-b14-462]

Here is the code:

package com.example.processing_test1;

import processing.core.PApplet;
import processing.core.PFont;
import processing.core.PImage;

public class MainActivity extends PApplet {
    PFont f;
    PImage p;

public void setup(){
    f = loadFont("test.vlw");
    p = loadImage("nav_down.png");
}

public void draw(){
    background(255);
    fill(0);
    textAlign(CENTER,CENTER);
    text("TESTING", width/2, height/2);
}


}

This runs perfectly fine when I launch on my Android device from my linux machine. When I launch the project from OSX, the app crashes at the loadFont and loadImage calls. If I comment out these calls, the app runs just fine (i.e. other processing calls like background, text, etc. work no problem).

The loadFont call produces:

Could not load font test.vlw. Make sure that the font has been copied to the data folder of your sketch.

The loadImage call produces a null pointer exception.

For reference, here's the source code for loadFont: https://github.com/processing/processing/blob/master/core/src/processing/core/PApplet.java (line: 6582).

Other than this, all I know is that these assets do appear in the generated APK's asset folder.

Was it helpful?

Solution

I figured it out.

Short answer: the assets I was testing with were corrupted files in the first place due to sync-ing projects between the one machine running linux and the Mac.

Longer answer:

This was non-obvious, because eclipse doesn't display file sizes. Processing calls for loadFont/loadImage simply spit out an error message that the file couldn't be found in the first place, thus setting off the goose-chase. Testing on my linux machine worked because the files weren't corrupted.

Digging into loadFont, it returns a PFont object constructed from an InputStream object. Odd (at the time) this worked fine when I made an InputStream with the corrupted file. The exception that triggered it happened later when calling readInt method from a DataInputStream object was what gave the final hint - generating an EOFException.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top