2014-05-06 3 views
0

Bit d'un problème étrange ... J'ai travaillé avec succès sur Android + Processing (voir: processing.org) dans Eclipse sur mon ordinateur. boîte de linux. Le processus de configuration est simple (http://blog.onthewings.net/2013/04/25/setting-up-a-processing-android-project-in-eclipse/). Sur OSX, j'ai un problème concernant le chargement des ressources (dans Eclipse et Android Studio), en utilisant un projet simple comme exemple. Quelques informations rapides:Objets Android introuvables dans Eclipse/Android Studio (à l'aide de bibliothèques de traitement) sous OSX

Linux: Ubuntu 12.04, version ADT v22.0.5-757759, OpenJDK Java 6 - traitement 32 bits/Eclipse.

OSX: Mavericks, construction ADT v22.6.2-1085508, traitement 32 bits Lib. Java SE 6 [1.6.0_65-b14-462]

Voici le 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); 
} 


} 

Cela fonctionne parfaitement bien quand je lance sur mon appareil Android de ma machine Linux. Lorsque je lance le projet à partir d'OSX, l'application se bloque aux appels loadFont et loadImage. Si je commente ces appels, l'application fonctionne très bien (c'est-à-dire que les autres appels de traitement comme le fond, le texte, etc. ne posent aucun problème).

L'appel LoadFont produit:

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

L'appel loadImage produit une exception de pointeur NULL.

Pour référence, voici le code source de loadFont: https://github.com/processing/processing/blob/master/core/src/processing/core/PApplet.java (ligne: 6582). À part cela, tout ce que je sais, c'est que ces actifs apparaissent dans le dossier des ressources de l'APK généré.

+0

Vous pouvez déballer les apk créés dans chaque cas et comparer des choses comme la taille de n'importe quel fichier qui contient les actifs empaquetés. –

Répondre

0

Je l'ai compris. Réponse courte: les actifs avec lesquels je testais étaient des fichiers corrompus en raison des projets de synchronisation entre une machine fonctionnant sous Linux et le Mac.

réponse plus longue:

Ce fut non évidente, parce que l'éclipse ne présente pas la taille des fichiers. Traiter les appels pour loadFont/loadImage cracher simplement un message d'erreur que le fichier n'a pas pu être trouvé en premier lieu, mettant ainsi hors de la poursuite-goose. Les tests sur ma machine Linux fonctionnaient car les fichiers n'étaient pas corrompus.

Creuser dans loadFont, il renvoie un objet PFont construit à partir d'un objet InputStream. Bizarre (à l'époque) cela a bien fonctionné quand j'ai créé un InputStream avec le fichier corrompu. L'exception qui l'a déclenchée s'est produite plus tard lors de l'appel de la méthode readInt à partir d'un objet DataInputStream, ce qui a donné l'indice final - la génération d'une exception EOFException.

Questions connexes