mam pytanie w zwiazku z mozliwosciami J2ME, poniewaz potrzebuje zczytac odopowiednio sformatowany plik pod J2ME jednak w netbeans linie zwiazne z JFC sa podkresalne tak jakby nie bylo takiej obslugi plikow w J2ME. Poza tym w tym kodzie chyba gdzies pominienem podawac nazwe pliku tylko nie wiem gdzie.. z gory dzieki za pomoc
/*
aktualny kod nizej
W J2ME nie ma takiej klasy jak JFileChooser ( to nie Swing! ).
Poczytaj dokumentacje.
ok poczytalem, mam teraz pytanie jak zrobic zeby w Form byla taka lista gdzie elementem jest linia danych w pliku
FileConnection sc = (FileConnection)Connector.open("file:///c/pliktekstowy.txt");
InputStream is = sc.openInputStream();
helloForm = new Form( null, new Item[] {
// ???
} );
sc.close();
tzn co zmienic zeby pliktekstowy.txt o tresci
ala ma kota 1
ala ma kota 2
ala ma kota 3
byl wypisany na wyswietlaczu telefonu...
Ja wczytuje to mniej wiecej tak:
Metoda ktora zwraca po linijce z pliku:
static String getLine(InputStream is)
{
String linijka="";
try {
byte b[] = new byte[1];
int koniec;
koniec = is.read(b);
if( koniec != -1 ) {
while((new String(b).equals("\r")==false) && koniec!=-1)//wczytuje cala linijke
{
linijka+=new String(b);
koniec = is.read(b);
}
}
else if(koniec==-1)
{
return "EOF";
}
} catch (IOException ex) {
ex.printStackTrace();
}
return linijka;
}
Jest ona statyczna, zebym mogl z niej kozystac w dowolnym miejscu.
potem aby z niej kozystac:
InputStream is = c.getResourceAsStream("plik.txt");
boolean flaga = true;
String[] linijki= new String(3);
int a=0;
while(flaga)
{
linijka = utils.getLine(is);
if(linijka.equals("EOF"))//jezeli jest koniec pliku wychodzimy z pętli
{
System.out.println("koniec pliku");
flagaPliku=false;
break;
}
else{
linijki[a] = linijka;
a++;
}
}
No i wyswietlenie to np:
import java.io.IOException;
import javax.microedition.lcdui.*;
public class EkranMenu extends Canvas{
public EkranMenu(Display awyswietlacz,MidletStart zms) {
public void paint(Graphics g) {
g.setColor(0xffffff);
g.drawString("" + inijki[0],0,10,0);
g.drawString("" + linijki[1],0,30,0);
g.drawString("" + linijki[2],0,60,0);
}
}
Pisałem czesciowo z głowy(wklejałem lekko zmodyfikowany moj kod, wiec moze nie dzialac ale mniej wiecej tak to ja robie i mi sie elegancko sprawdza
obecnie po uruchomieniu emulatora netbeansa to przy operacji na plikach systemowych pyta czy wykonac odczyt na pliku systemowym (tak/nie) jak klikne 'tak' to program wraca do menu midletow... czyli tak jakby program przedwczesnie konczyl dzialania.. nie mam pojecia dlaczego? moze jest jakas linijka kodu ktora go konczy przedterminowo? to samo tyczy sie plikow w internecie tak jak w kodzie ponizej.. pyta czy polaczyc z witryna w celu odczytu pliku, po wyborze 'tak' program znow wraca do menu midletow i nie wyswietla zawartosci pliku na wyswietlaczu emulatora komorki..
na podstawie Twojego kodu napisałem tak:
aktualny kod nizej
hmm to moze ktos z Forumowiczow wie jak sie JSR 75 konfiguruje? czyli to co dotyczy plikow
Witam,
program generuje wyjatek ClassCastException w tej linijce:
FileConnection sc = (FileConnection)Connector.open("http://kolos.math.uni.lodz.pl/~bart/tekstowy.txt");
Klasa Connector jest fabrykatorem, ktory przy pomocy metody open(String name, ...) tworzy odpowiednie obiekt reprezentujacy polaczenie. To, jakie polaczenie ma byc stworzone okresla prefiks argumentu name i tak np.:
[ prefix ] [ klasa connectora ] [ specyfikacja ]
http:// HttpConnection MIDP1.0
https:// HttpsConnection MIDP2.0
socket:// SocketConnection MIDP2.0 (low-level networking)
datagram:// UDPDatagramConnection MIDP2.0 (low-level networking)
file:// FileConnection FC API (JSR 75)
... oraz inne (odsylam do specyfikacji).
W Twoim przypadku prefiksem jest http://, wiec powinienes rzutowac na HttpConnection.
Jak juz sie z tym uporasz, to jest jeszcze jeden blad: probujesz uzyc zmiennej helloTextBox, ktora wczesniej nie byla zainicjalizowana (dostaniesz wyjatek NullPointerException w metodzie get_helloForm).
BTW: FileConnection API jest pakietem opcjonalnym i nie kazdy producent moze go implementowac w swoich urzadzeniach. Niemniej jednak, dostepnosc pakietu mozna sprawdzic w ten sposob:
System.getproperty(microedition.io.file.FileConnection.version);
Metoda zwraca numer wersji FC API, lub null, jesli pakiet nie jest dostepny.
Pozdr.
niestety pomimo ze poprawilem blad ktory podales z 'http', oraz sprawdzeniu ze jednak zmienna helloTextBox istnieje jako prywatna.. to i tak program pyta o to czy ma odczytac plik po czym przedwczesnie konczy dzialanie..
obecny kod
aktualny kod ponizej
Witam,
jak wspomnialem wczesniej problem dotyczy wyjatku NullPointerException, ktory generowany jest w momencie, gdy NIE spelniony jest warunek:
if(linijka.equals("EOF")) //...
a dokladnie chodzi o uzycie:
helloTextBox.insert(linijka,helloTextBox.size());
Oczywiscie zmienna helloTextBox jest deklarowana na poczatku (jako prywatny atrybut klasy MIDletu), ale nie inicjujesz jej przed uzyciem (zgodnie ze specyfikacja Java, domyslna wartosc niezainicjowanych atrybutow klasy to null, stad NullPointerException).
Dodatkowo warto troche posprzatac kod:
import com.sun.midp.io.j2me.storage.File;
import com.sun.perseus.platform.BufferedInputStream;
import javax.microedition.io.file.*;
mozna pominac domyslny konstruktor, jesli jest on pusty. Kod stanie sie czytelniejszy (IMO), a sam kompilator i tak sobie to uzupelni.
wyjatki w jezyku Java sa malo efektywne, dlatego przekazywanie ich do metod nadrzednych nie jest dobra praktyka. W Twoim przypadku nic nie stoi na przeszkodzie (a nawet jest wskazane), aby wyjatek IOException w metodzie get_helloForm() obsluzyc od razu.
nie uzywasz lokalnej zmiennej a, podobnie jak atrybutu MIDletu o nazwie helloStringItem.
dostep do metod statycznych powinien odbywac sie poprzez jawne wskazanie klasy, w ktorej dana metoda lub atrybut sie znajduje, np.:
live.getLine(is);
Tutaj mozna tez wspomniec, ze zgodnie z przyjeta konwencja nazwy klas dobrze jest rozpoczynac duza litera.
linijka+=new String(b);
lepiej jest uzyc klasy StringBuffer, ktora na pewno bedzie o wiele wydajniejsza.
is.close();
sc.close();
Pewne rzeczy mozna by zrobic troche inaczej, ale zostawiam juz do wlasnych przemyslen.
Pozdr.
dzieki za wyczerpujace wyjasnienia, szkoda ze Ci nie moge przyznac +
poprawilem co pisales i działa!
jedyne co to jeszcze pominalem uwage o wydajnosci i o wyjatkach,,, wydajnosc poki co na razie zostaiwe natomiast z pospiechu piszac ten program nie zastanawialem sie specjalnie gdzie wpisac a gdzie nie to try i catch bo netbeans podpowiadal co spowodowalo ze teraz gdzie nie usune to jest zle... i troche sie w tym pogubilem z racji ze zaczynam moja przygode z Java
mam jeszcze jedno pytanie, prdopodobnie dziecinnie glupie, czy da sie jakos ten program uruchomic z emulatorem telefounu ale nie w netbeans? tzn jaki plik za to odpowiadaj, podejrzewam ze .jar ale jego sie nie da odplaic bo wyskakuje blad.. oczekuje na taki emulator wygenerowany przez JVM http://torus.uck.pk.edu.pl/~danusia/wyklad-mobilne/mobilne/obrazki/mekran1.6.jpg
obecny kod programu to:
/*
* live.java
*
* Created on 12 styczeń 2008, 02:18
*/
package futbol24;
import java.io.IOException;
import javax.microedition.lcdui.*;
import javax.microedition.io.*; // do laczenia sie z serwerem
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
import java.io.*;
/**
*
* @author bart
* @version
*/
public class live extends MIDlet implements CommandListener {
private Form helloForm;
private TextBox helloTextBox;
private StringItem helloStringItem;
private Command exitCommand;
private void initialize() throws IOException {
getDisplay().setCurrent(get_helloForm());
}
public void commandAction(Command command, Displayable displayable) {
if (displayable == helloForm) {
if (command == exitCommand) {
exitMIDlet();
}
}
}
public Display getDisplay() {
return Display.getDisplay(this);
}
public void exitMIDlet() {
getDisplay().setCurrent(null);
destroyApp(true);
notifyDestroyed();
}
String getLine(InputStream is) {
String linijka = "";
try {
byte b[] = new byte[1];
int koniec;
koniec = is.read(b);
if( koniec != -1 ) {
while((new String(b).equals("\r")==false) && koniec!=-1) //wczytuje cala linijke
{
linijka+=new String(b);
koniec = is.read(b);
}
} else if(koniec==-1) {
return "EOF";
}
} catch (IOException ex) {
ex.printStackTrace();
}
return linijka;
}
public TextBox get_helloForm() throws IOException {
if (helloForm == null) {
this.helloTextBox = new TextBox("", "", 400,TextField.ANY);
HttpConnection sc = (HttpConnection)Connector.open("http://kolos.math.uni.lodz.pl/~bart/tekstowy.txt");
InputStream is = sc.openInputStream();
boolean flaga = true;
String linijka;
int a=0;
while(flaga) {
linijka = this.getLine(is);
if(linijka.equals("EOF")) {
System.out.println("koniec pliku");
flaga = false;
break;
} else {
helloTextBox.insert(linijka,helloTextBox.size());
}
}
is.close();
sc.close();
}
return helloTextBox;
}
public Command get_exitCommand() {
if (exitCommand == null) {
exitCommand = new Command("Exit", Command.EXIT, 1);
}
return exitCommand;
}
public void startApp() {
try {
initialize();
} catch (IOException ex) {
ex.printStackTrace();
}
}
public void pauseApp() {
}
public void destroyApp(boolean unconditional) {
}
}
Rozważ też zmianę popisu na taki:
szczególnie pomogli mi: johny_bravo, chodnik, J2ME
świetny pomysł, a teraz do tematu :]
Na poczatku dziekuje za dobre checi. Mysle, ze nie bylo potrzeby modyfikacji statusu.
Przyklad optymalizacji (a wlasciwie dobrej praktyki) poprzez uzycie StringBuffer byl juz przytaczany wiele razy na tym forum, podobnie jak byl uzyty kilka watkow wczesniej. Chodzi o to, aby zamiast konstrukcji:
String s = "";
char c = 0;
while(...) {
c = input.read();
s += new String(c);
}
uzyc bufor lancuchow znakow StringBuffer
StringBuffer sb = new StringBuffer();
char c = 0;
while(...) {
c = input.read();
sb.append();
}
String s = sb.toString();
Jesli chodzi o wyjatki, to nagle zakonczenie wykonywania metody (spowodowane wygenerowaniem wyjatku) jest bardziej kosztowne od normalnego powrotu z funkcji (return). Dzieje sie tak dlatego, ze w momencie wystapienia wyjatku, exception-handler wirtualnej maszyny Java sprawdza, czy w danej metodzie jest sekcja catch, ktora dotyczy danego wyjatku. Jesli nie, ze stosu zdejmowany jest blok powiazany z ta metoda, a nastepnie ponowne poszukiwanie sekcji catch w metodzie nadrzednej. I tak do momentu, kiedy wyjatek zostanie przechwycony lub exception-handler dotrze do metody glownej. Wtedy to juz pojdzie printStackTrace() na konsole.
W Twoim przypadku przenioslbym pobieranie etykiet do osobnej klasy. Pozwoli to na podzielenie aplikacji na logiczne bloki (zapewne znana strategia "dziel i zwyciezaj"), a dodatkowo bedziesz mogl utworzyc sobie obiekt tylko wtedy, kiedy bedzie to potrzebne (w chwili obecnej metoda get_helloForm(), od momentu utworzenia MIDletu, caly czas zajmuje zasoby).
Przechwytywanie wyjatku (blok try...catch...finally) oczywiscie musi dotyczyc zestawiania polaczenia oraz otwierania i zamykania strumienia.
Pozdr.</i>
Na poczatku dziekuje za dobre checi. Mysle, ze nie bylo potrzeby modyfikacji statusu.
Przyklad optymalizacji (a wlasciwie dobrej praktyki) poprzez uzycie StringBuffer byl juz przytaczany wiele razy na tym forum, podobnie jak byl uzyty kilka watkow wczesniej. Chodzi o to, aby zamiast konstrukcji:
String s = "";
char c = 0;
while(...) {
c = input.read();
s += new String(c);
}
uzyc bufor lancuchow znakow StringBuffer
StringBuffer sb = new StringBuffer();
char c = 0;
while(...) {
c = input.read();
sb.append();
}
String s = sb.toString();
Jesli chodzi o wyjatki, to nagle zakonczenie wykonywania metody (spowodowane wygenerowaniem wyjatku) jest bardziej kosztowne od normalnego powrotu z funkcji (return). Dzieje sie tak dlatego, ze w momencie wystapienia wyjatku, exception-handler wirtualnej maszyny Java sprawdza, czy w danej metodzie jest sekcja catch, ktora dotyczy danego wyjatku. Jesli nie, ze stosu zdejmowany jest blok powiazany z ta metoda, a nastepnie ponowne poszukiwanie sekcji catch w metodzie nadrzednej. I tak do momentu, kiedy wyjatek zostanie przechwycony lub exception-handler dotrze do metody glownej. Wtedy to juz pojdzie printStackTrace() na konsole.
W Twoim przypadku przenioslbym pobieranie etykiet do osobnej klasy. Pozwoli to na podzielenie aplikacji na logiczne bloki (zapewne znana strategia "dziel i zwyciezaj"), a dodatkowo bedziesz mogl utworzyc sobie obiekt tylko wtedy, kiedy bedzie to potrzebne (w chwili obecnej metoda get_helloForm(), od momentu utworzenia MIDletu, caly czas zajmuje zasoby).
Przechwytywanie wyjatku (blok try...catch...finally) oczywiscie musi dotyczyc zestawiania polaczenia oraz otwierania i zamykania strumienia.
Pozdr.</i>
Odpowiedź znajdziecie tu: http://coffee4man.cba.pl/index.php/java-me-czesc-3-odczyt-pliku-tekstowego/
Pozdrawiam, mam nadzieję, że to pomoże.