Problemy z odczytem bajtów z bufora w aplikacji Android napisanej w Javie

Wed Feb 09, 2011 11:24 pm   

On 9 Lut, 21:33, "Lelek@" <n...@nndn.pl> wrote:

Na pewno są jakieś debuggery, ale wyjątek powinien polecieć na
konsolę, po odpaleniu. Nie znam się na Androidzie, w Javie pisałem
sporo, ale parę lat temu. Podobało mi się, więc nawet myślę o tym żeby
się zapoznać z Androidem.


Ja Ci radzę myśleć o Javie jak o czymś trochę mniej poważnym od C/C++
- pomaga:)
Ale wracając - możesz dorzucić
if(buf == NULL) poskarżsięnaekranieiwyjdź();
tuż za getBytes?

Wed Feb 09, 2011 11:50 pm   

"Adam Dybkowski" <adybkows12@45wp.pl> wrote in message
news:iiv3lq$tqt$1@news.onet.pl...


Mam dokładnie tak jak ty masz.
Moja metoda nazywa sie

public void Button1Click(View view) {

}
I w niej to samo.co ty

W XML-u layoutu jest
android:onClick="Button1Click"
I to wszystko.
Z tym sprawdzeniem zera działa jak tego obaj oczekujemy. Wszystko gra.
Sorki ale całości ciężko by było pokazać Wiesz jak jest

Thu Feb 10, 2011 2:08 am   

On 02/09/2011 01:59 PM, Lelek@ wrote:

No to chyba się wyjasniło




FromEditText.getBytes(). Wskazanie do tablicy, która zaalokowałeś
zostało stracone i przydzieloną pamięcią zajmie się przy najbliższej
okazji garbage collector.
Powyższy kod jest równoważny takiej linijce:

byte buf[] = FromEditText.getBytes("UTF-8");

Ja bym twój kod przepisał do takiej postaci:

byte buf[] = FromEditText.getBytes("UTF-8");
int bfx[] = nil;
if(buf.length>0)
{
bfx[] = new int[buf.length];
for (i = 0; i < buf.length; i++)
{
//elementy buf mają po 8 bitów, więc maskowanie 0xff
//jest trochę bez sensu
bfx[i] = ((int)buf[i] & 0xFF);
}
}

if(bfx!=nil)
{
//robimy cos z bfx
}

Bardzo ważne jest alokowanie pamięci na bfx po odczytaniu zawartości
buf. Przy alokowaniu bfx o stałej długości, dopóki FromEditText.getBytes
zwróci tablicę mniej niż 256 bajtów, program będzie działał poprawnie.
Ale jeśli buf będzie dłuższe niż długość bfx, program wywali się z
błędem dostępu do pamięci przy próbie zapisu pierwszego elementu, który
się nie mieści w bfx.


BTW. próbowałeś przechwytywać wyjątki?

pzdr.
j.

Thu Feb 10, 2011 3:13 am   

"Jacek Radzikowski" <jacek@spamer.die.die.die.piranet.org> wrote in message
news:iivdpv$o2u$1@inews.gazeta.pl...


if(buf.length>0) <----------- on tego nie rozumie

dla niego ten buf nie istnieje. Trzeba go zadeklarować globalnie w funkcji


To nie jest aż tak bez sensu, bo casting signed byte to sign integer kopiuje
8-my bit do 31-go a właściwie rozszerza np (int)0x80 -> FFFFFF80 bo signed a
nie 0x80

Thu Feb 10, 2011 4:40 am   

On 02/09/2011 09:13 PM, Lelek@ wrote:

do niego. Z kodu, który zacytowałeś wynikało że buf jest deklarowany na
tym samym poziomie zagłębienia co odwołanie do FromEditText.getBytes().
A ifie brakuje jeszcze jednego warunku:
if((buf != nil ) && (buf.length>0))




pzdr.
j.

Thu Feb 10, 2011 7:59 am   

"Jacek Radzikowski" <jacek@spamer.die.die.die.piranet.org> wrote in message
news:iivmnj$f55$1@inews.gazeta.pl...


Ta Java to jeden wielki shit Jak się operuje na strumieniach danych
binarnych to w kółko trzeba konwerować to co zwracają funkcje w byte signed
do signed int ale wymaskowywać je. Idiotyzm.

Nie wiem, na razie działa z tym testem czy len jest 0 czy nie, twoich rad
nie umiem zastosować. Nie rozumiem jak mam deklarować ten sam bufor wiele
razy Przeglądam od 10 dni już to co ludzie piszący w javie wyprawiają.
Dokładnie robia to jakby zaczynali progframować w bascomie i nie rozumieją
co czynią
Z tego co się dowiedziałem to Java powstała bo ludzie nie rozumieli
wskaźników i zapominali o zwalnianiu zaalokowanych zasobów

Thu Feb 10, 2011 8:45 am   

On 02/10/2011 01:59 AM, Lelek@ wrote:

Shit bo nie umiesz się nią posłużyć. Napisałem w javie dobrych
kilkadziesiąt tysięcy linii i uważam że jest to całkiem przyjemny język.
Inne języki też znam, więc mam porównanie.


Nie bardzo wiem o co chodzi, ale mam wrażenie że usiłujesz zrobić coś na
około.


widzę że walczysz z samą ideą obiektów.
Bufora nie deklarujesz kilka razy. Samą zmienna buf deklarujesz raz, w
takim miejscu żeby była widoczna ze wszystkich miejsc w których musisz
się do niej odwoływać (ale bez przesady. Najprawdopodobniej wystarczy ze
zadeklarujesz ją lokalnie w funkcji).
Buf w twoim przypadku przechowuje nie sam obiekt, a referencję do niego
(referencja działa troszkę podobnie jak wskaźniki w C, choć to nie do
końca jest to samo). Funkcja FromEditText.getBytes() sama alokuje pamięć
na tablicę zawierającą wynik i zwraca Ci wskazanie na nią. Ta referencja
jest wpisywane do zmiennej buf. Jeśli przed wywołaniem funkcji było w
niej coś innego, poprzednia wartość jest tracona, a w jej miejsce jest
wpisywana wartość zwracana przez przez getBytes. Nie następuje tam żadne
przepisywanie tablic (dlatego nie trzeba wcześniej alokować pamięci).

Wszelkie operacje jakie wykonasz na zmiennej buf po wpisaniu do niej
wartości zwróconej przez getBytes będą wykonywane nie na twojej tablicy,
a na tablicy zaalokowanej wewnątrz funkcji.
Sprawdzanie warunku buf.length jest potrzebne po to, żeby nie tworzyć
tablicy o zerowej długości (przypisanej do bfx).


dużo śmieci, ale też bardzo dużo kodu bardzo dobrej jakości.


zamiast babrać się z gospodarką pamięcią. Operując na wskaźnikach bardzo
łatwo z prostego programu stworzyć koszmarek - java stara się do tego
nie dopuścić (a przynajmniej nie przez jeżdżenie po pamięci). Mając do
dyspozycji dużo wolnego ramu, nie trzeba się martwić żeby jak
najszybciej zwolnić przydzielony a nieużywany obszar. Ręczna gospodarka
przydzielaną pamięcią w bardziej skomplikowanych projektach może
przypominać chodzenie po polu minowym. Nic dziwnego że nawet najlepszym
i najbardziej uważnym programistom zdarza się popełnić głupie błędy,
typu nie zwalnianie czegoś czy wielokrotne zwalnianie.
Mechanizm odzyskiwania nieużywaniej pamięci jest implementowany w wielu
językach wysokiego poziomu. Java jest tylko jednym z nich.

pzdr.
j.

Thu Feb 10, 2011 2:41 pm   

"Lelek@" <nn@nndn.pl> wrote in message news:ij02dc$crn$1@opal.futuro.pl...

Sam się śmiejesz że Java to takie C ale nie rozumiesz, że robisz
w tej Javie coś w stylu:

char data[100]="abcedefghijklmnoprstuwz";
char * buf = (char*)malloc(100);

a potem robisz coś na kształt:

buf = data;

zamiast

strcpy(buf, data);

I dziwisz się, że nie masz tam tego, co zwróciło malloc(). Pomyśl chwilkę...

Fri Feb 11, 2011 2:01 pm   

Dnia 07-02-2011 o 12:39:30 Lelek@ <nn@nndn.pl> napisał(a):


Wszystko jest totalną porażką jeśli się nie ma odpowiedniej wiedzy
Jedyne do czego można się przyczepić to, że kompilator Cie nie ostrzegł
przed użyciem niezainicjowanej zmiennej. No chyba, że ostrzegł, tylko
należysz do tych co instrukcje obsługi czytają dopiero jak wszystkie inne
sposoby zawiodą :)

--
PZDR
Shaman

Fri Feb 11, 2011 2:06 pm   

On Fri, 11 Feb 2011 14:01:29 +0100, Shaman wrote:

Alez byla zainicjowana i to nawet dwa razy.

Co najwyzej Javie brakuje definicji funkcji ktora moze zwrocic NULL
zamiast referencji i ostrzegania jesli programista nie sprawdza tego
warunku przed odwolaniem :-)



J.

Fri Feb 11, 2011 2:27 pm   

Dnia 11-02-2011 o 14:06:52 J.F. <jfox_xnospamx@poczta.onet.pl> napisał(a):


hmm.. jeszcze raz przejrzałem posty Lelka i nie widzę, żeby gdzieś ją
inicjował.

Zwykła Java z tego co kojarzę inicjuje takie pola jedynie w wypadku gdy są
to prywatne pola klasy. Pól deklarowanych w metodach Java nie inicjuje - w
sensie "zeruje obszaru pamięci zajmowanej przez to pole". Tak jest w
"zwykłej" javie.. nie wiem natomiast jakie cuda z tym kodem źródłowym
czynią narzędzia dla AVR. Możemy się wymądrzać a okaże się, że całe to
zamieszanie jest efektem niezamierzonym :)

--
PZDR
Shaman

Fri Feb 11, 2011 2:39 pm   

On Fri, 11 Feb 2011 14:27:13 +0100, Shaman wrote:

byte buf[] = new byte[256];
buf = FromEditText.getBytes("UTF-8");


AVR ?
No dobra - buf zainicjowal dwa razy, zawartosc tablicy tylko raz.

Akurat niezainicjowana zawartosc tablicy nie powinna tu bruzdzic ..
chyba ze jakas kontrola przed nieuprawnionym czytaniem pamieci.

J.

Fri Feb 11, 2011 3:04 pm   

Dnia 11-02-2011 o 14:39:08 J.F. <jfox_xnospamx@poczta.onet.pl> napisał(a):


haha.. ostatnio dużo czytam o AVR i zamiast Android zobaczyłem Arduino :)



Sięgnąłem po książkę "Thinking in Java" - a nie robiłem tego od wielu
miesięcy
Kurcze sprawa wydaje się jeszcze dziwniejsza, bo faktycznie wywołanie
byte buf[] = new byte[256]; powinno zainicjować i wyzerować tablicę.
No ale książka traktuje o referencyjnej Javie Sun'a. Widać Google dla
swojej maszyny wirtualnej po swojemu optymalizuje bajtkod. To jest dla
mnie jedyne wytłumaczenie.

--
PZDR
Shaman

Fri Feb 11, 2011 3:22 pm   

Shaman denied rebel lies:


Czekaj bo się już zgubiłem w tym wątku. Wydaewało mi się że tutaj:
<iiup2o$em2$1@opal.futuro.pl> Lelek sobie sam odpowiedział na swoje
pytanie dlaczego mu się wywala?

--
<:> Roger, MoonWolf Out <:>|Don't you leave me Father Time
(: (:|
( JID:moonwolf@jabberpl.org(| http://karakkhaz.prv.pl

Fri Feb 11, 2011 3:32 pm   

On Fri, 11 Feb 2011 15:04:03 +0100, Shaman wrote:

Nie widziales tlumaczenia ?
Druga linia wywala pierwsza inicjacje, a wstawia do obiektu
zaalokowanego i zwroconego przez metode.
W tym przypadku pewnie zwrocilo null i stad caly jest ambaras.

A tak swoja droga - to co potem zwraca .length od null ?
zero czy juz wyjatek ?

J.