JuzaPhoto utilizza cookies tecnici e cookies di terze parti per ottimizzare la navigazione e per rendere possibile il funzionamento della maggior parte delle pagine; ad
esempio, è necessario l'utilizzo dei cookie per registarsi e fare il login (maggiori informazioni).
Proseguendo nella navigazione confermi di aver letto e accettato i
Termini di utilizzo e Privacy e preso visione delle opzioni per la gestione dei cookie.
Puoi gestire in qualsiasi momento le tue preferenze cookie dalla pagina Preferenze Cookie,
raggiugibile da qualsiasi pagina del sito tramite il link a fondo pagina, o direttamente tramite da qui:
“ ...i negozi fisici italiani sembrano negozi del Butan.... „
Eru si scrive Bhutan , non Butan. Sicuramente non ci sei mai stato, ma non credo ti piacerebbe. Scopriresti un luogo dove il capo supremo dello stato propone una politica tesa al raggiungimento della più alta 'Gross National Happiness (felicità interna lorda)', dove lo sforzo di tutti è teso al miglioramento degli standard di vita e al benessere spirituale della popolazione, la preservazione dell'ambiente naturale e dei valori culturali. Esattamente l'opposto della cultura occidentale disseminata dagli Yankee, tesa a massimizzare il prodotto interno lordo a discapito del benessere sociale e spirituale dei cittadini, ottenuta anche inducendo negli stessi compulsivi bisogni di possesso dell'ultimo gioiello tecnologico che é sicuramente il meglio del pianeta
preso in mano ieri in un centro commerciale, c'era lo stand samsung.. usato 5 minuti, l'ho trovato molto leggibile, veloce...la dimensione è notevole, ma non da creare problemi per portarlo ingiro ammmèmepiace
Oh finalmente un commento sensato! Ma ci vuol tanto a dire un semplice e sincero "a me piace", lasciando da parte tutte quelle boutades celoduristiche verso altri prodotti?!
“ Mi capisci quindi che la problematica legata ai memory-leaks è ahimè tristemente ben presente anche su piattaforma Android. „
“ Il problema è semmai verso i memory leaks causati da chi scrive apps in modo non ottimale che ad oggi rimangono irrisolti (non esiste al momento una sorta di "garbage collector" simil-java). „
tu parlavi di programmatori che sbagliano a gestire la memoria o la gestiscono in modo "non ottimale". e questo non è possibile. quindi se c'è un problema è nel layer sotto non nelle app. anche se puoi fare crashare una app java in android se fai delle chiamate sbagliate o usi male i thread.
se il layer di android è fatto bene funziona se no no ma questo si può dire anche di un normale garbage collector su una qualsiasi jvm. il meccanismo della Java Native Interface ce l'hai tanto quanto anche su pc: la virtual machine fa le sue chiamate a basso livello usando le funzioni native del SO. mica comunica con sistema operativo in java ovviamente. non vedo la differenza concettualmente. un layer da qualche parte scritto in c++ o in C ce l'hai per forza e allora dai per scontato che questo porti a dei leaks o comunque a degli errori? non capisco.
o mi stai dicendo che la JNI e il garbage collector - che addirittura è chiamabile da codice - di android fanno schifo e quelli per pc sono fatti meglio oppure non trovo una differenza concettuale che faccia dire che java su android determina leaks e su altri sistemi operativi no.
“ Le applicazioni Android inoltre NON sono scritte in Java così come mi par di capire che tu ne intenda lo sviluppo. Bensì sono basate sulla JNI che - facendola breve/semplice e comprensibile a tutti - consente da un paradigma di sviluppo high-level come può essere quello Java-oriented di effettuare delle syscall nativamente scritte in C/C++. Questo significa che tu sviluppi utilizzando la lib SDL avvalendoti del framework JNI per tutte le syscall, wrappando alla fine il tutto in un classico Java-project (il pacchetto APK). „
dalla tua definizione allora NIENTE è scritto in java visto che a meno di processori che funzionano con il bytecode di java ( non ne conosco ), tutto il sw in java traduce le syscall nelle chiamate native.
Son sicuro che non è intenzione di Eru (e di chi è sin'ora intervenuto nel topic) di far slittare la tematica del suo topic su dei concetti legati allo sviluppo Java. E francamente, non me ne volere, non è neppure la mia volontà. In rete puoi facilmente trovare tutte le informazioni che ti servono per colmare i tuoi dubbi/curiosità e lacune. Scrivimi in pvt eventualmente per la bibliografia di riferimento, che ti consiglierò più che volentieri.
Ad ogni modo è giusto dar risposta a quanto mi hai scritto, invitandoti pro-futuro a passare o su un topic dedicato o direttamente via pvt.
“ tu parlavi di programmatori che sbagliano a gestire la memoria o la gestiscono in modo "non ottimale". e questo non è possibile. quindi se c'è un problema è nel layer sotto non nelle app. anche se puoi fare crashare una app java in android se fai delle chiamate sbagliate o usi male i thread. „
No. Immagina una semplice visita in ampiezza su un grafo sparso. Hai presente la ricerca del cammino minimo impiegata da Maps? Ecco, una BFS con a supporto una coda FIFO. Ad ogni esplorazione di un nodo, la sua progenie viene allocata in memoria nella coda (la cui implementazione può spaziare dal vettore rilocato alla lista dinamica linkata) lasciando tuttavia al programmatore l'onere di fare una "free()" (o se ti piace di più una delete[] ) sui nodi esaminati.
Questo un esempio che dovrebbe darti qualche elemento in più.
“ se il layer di android è fatto bene funziona se no no ma questo si può dire anche di un normale garbage collector su una qualsiasi jvm. il meccanismo della Java Native Interface ce l'hai tanto quanto anche su pc: la virtual machine fa le sue chiamate a basso livello usando le funzioni native del SO. mica comunica con sistema operativo in java ovviamente. non vedo la differenza concettualmente. un layer da qualche parte scritto in c++ o in C ce l'hai per forza e allora dai per scontato che questo porti a dei leaks o comunque a degli errori? non capisco. „
No. Nello sviluppo standard J2EE/J2SE l'implementazione della JNI è chiaramente lato JRE. Non arriva all'high-end di sviluppo. Qui invece, nel caso di applicazioni mobile per Android, abbiamo una situazione discretamente differente. Utilizzando la SDL hai la possibilità di fare delle syscall verso l'API esposta da Android, wrappando il tutto in un comodo e semplice Java-Project (l'APK di cui ti parlavo prima, ricordi?).
“ o mi stai dicendo che la JNI e il garbage collector - che addirittura è chiamabile da codice - di android fanno schifo e quelli per pc sono fatti meglio oppure non trovo una differenza concettuale che faccia dire che java su android determina leaks e su altri sistemi operativi no. „
No. Il Garbage collector gira un algoritmo non-deterministico. Questo significa che non esiste una chiamata asincrona che possa forzarne l'esecuzione. Se ti riferisci alla System.gc() .. spiacente ma questo metodo informa semplicemente la Runtime che potrebbe esser necessario "un giro di GC".
Inoltre, se hai mai provato ad allocare un ResultSet di cardinalità prossima al 1M di elementi avrai notato come chiudendogli lo Statement non viene rilasciata la memoria allocata. Eppure questa è libera, ma concettualmente ancora assegnata al processo in esecuzione.. così, data la quantità onerosa di elementi allocati e non rilasciati questo implica un bel memory leak. Mi è capitata una situazione del genere su dei dati relativi a dei crediti problematici per un istituto bancario di riferimento nel nostro paese. Bene, si girava su oltre 6M di record tirati su a query... e chiaramente seppur paginando gli statements la memoria continuava a restar allocata sul processo in corso. Ti lascio immaginare la problematica..
“ dalla tua definizione allora NIENTE è scritto in java visto che a meno di processori che funzionano con il bytecode di java ( non ne conosco ), tutto il sw in java traduce le syscall nelle chiamate native. „
“ Son sicuro che non è intenzione di Eru (e di chi è sin'ora intervenuto nel topic) di far slittare la tematica del suo topic su dei concetti legati allo sviluppo Java „
Quoto, questo è un inno, non è un cantico aramaico
Aggiungo altra cosa pratica che questo Note 2 mi permette di fare. Con una comoda e gratuita app, Shplashtop mi connetto in remoto al mio desktop di ufficio, ieri mi serviva un tabulato che dovevo stampare col mio software gestionale nel PC di ufficio a 300 KM , in linea teorica un qualunque smarphone lo fa, in pratica ti voglio su uno schermino a pilotare un software gestionale con la microfreccetta del mouse che si inciampa in lunghi elenchi e manco c'è posto per la tastiera, sul Note 2 non dico che l'operazione sia la cosa più comoda del mondo, ma fattibilissima, mi sono stampato i tabulati che mi servivano salvandoli su dropbox e mi sono comparsi sul mio note 2. Quindi una funzione molto pratica che il note 2 permette è appunto pilotare il Desktop remoto in maniera decisamente + agevole che non un 4 o meno pollici.
Comunque per gli interessati , nel Q2 2013 esce lo smarphone del 2013 che è il Galaxy 4, con un qcore a 2 giga, 3 giggi di ram, schermo da 5 con nuova tecnologia e android 5. Non mi andava di aspettare 6 o + mesi ma per chi non ha fretta di cambiare consiglio di attendere il nuovo fine di mondo smarphone perchè le specifiche fanno impallidire parecchi notebook
Eru scarica Sun Surveyor. È un'app fantastica che ti da la posizione del sole lungo l'arco della giornata sulla base di cosa stai inquadrando col cell! Pazzesca, l'ho vista girare sull'HTC del mio amico Botty ed è davvero notevole ;)
Maurizio, per non impestare il topic di argomentazioni da programmatori: riassumendo, capisco la tua esperienza e capisco il problema che hai incontrato, ho anche letto in giro alcuni suggerimenti su possibili leaks e perché succedono. nel complesso ritengo personalmente un po' contradditorio quello che hai detto nei più post e mi limito a dire a chi è interessato a questi devices che la mia opinione è che NON c'è un reale grave problema di leaks tipico di android, soprattutto in relazione a iOS. poi visto che dopo un post kilometrico di argomentazioni mi si chiede di non rispondere e controbattere.. .ok non controbatto. ti dico che sostanzialmente non sono d'accordo con l'affermazione di fondo: cioè 1.android ha problemi di leaks se i programmatori non ottimizzano - è per lo più una questione di avere capito come funziona il meccanismo delle activities e del gc - 2. non c'è un vero garbage collector - qui sei stato contradditorio e anche su tutti i documenti che ti spiegano perché possono avvenire i leaks si fa proprio riferimento a come funziona il gc che c'è in android.
poi ognuno pensi quello che vuole e decida quando comprerà un mobile devices se informarsi in merito e quanto è importante questo aspetto
Questa discussione ha raggiunto il limite di 15 pagine: non è possibile inviare nuove risposte.
La discussione
NON deve essere riaperta A MENO CHE non ci sia ancora modo di discutere STRETTAMENTE sul tema originale.
Lo scopo della chiusura automatica è rendere il forum più leggibile, soprattutto ai nuovi utenti, evitando i "topic serpentone": un topic oltre
le 15 pagine risulta spesso caotico e le informazioni utili vengono "diluite" dal grande numero di messaggi.
In ogni caso, i topic non devono diventare un "forum nel forum": se avete un messaggio che non è strettamente legato col tema della discussione,
aprite una nuova discussione!
JuzaPhoto contiene link affiliati Amazon ed Ebay e riceve una commissione in caso di acquisto attraverso link affiliati.
