Qualcuno ha aggiornato i file sorgenti e non c'è più la cartella bin
Visualizzazione stampabile
Qualcuno ha aggiornato i file sorgenti e non c'è più la cartella bin
ragazzi, mi piacerebbe provare a installarlo ma aprendo il link sul sito apre una pagina con messaggio di errore
E cosa usi per la compilazione (sperando che tu lavori in ambiente linux.....)?
Non funziona... Ma provo a pulire i sorgenti e riscaricarli
EDIT: @SuppressWarnings() è una info per il compilatore in quanto mi dava un warning su quel metodo
Magari ho creato io il problema con il push
@mm7: Ho fatto altre modifiche e le ho commentate interamente, vedi tu se ti garbano
Non si aggiorna automaticamente, è il risultato della compilazione, a ogni update ho compilato i sorgenti quindi si "aggiorna" anche l'apk
Be io uso linux da quando avevo 11 anni (non è uno scherzo..), comunque uso ant.
Dopo l'ultimo pull ci sono degli errori nel list iterator vedo di correggere..
Si, ho eliminato io la bin e la gen, ma volevo mettere gli apk in apk, purtroppo ieri sera devo aver sbagliato qualcosa e quindi devo aver caricato un apk sbagliato
Come detto sopra creano problemi ma vedo di correggere.
Per quanto riguarda le modifiche ecco cosa ne penso:
-l'eliminazione della variabile count non la vedo necessaria perchè (apparte il fatto che anche se mettessi 1000 variabili non uccuperebbero niente comunque) i cellulari di fascia medio-bassa hanno sia una cpu lenta sia poca ram, anzi ti dico di più molti usano la swap (con sd o memoria interna) ovviando in parte la mancanza di ram, invece l'overclock non fa quasi niente (apparte distruggere la cpu). Comunque per me è indifferente; io di solito per funzioni chiamate più di una volta creo variabili poi non so (comunque c'è anche il garbage collector)
-ok per mApplications = new ArrayList<AppInfo>; e anche per portare fuori dall' if il clear
-i list iterator non li uso mai.. comunque se i tuoi prof dicono che è meglio cosi teniamo (mi adatterò...)
Cerco di correggere i problemi e di ricaricare il codice
EDIT:
Ho notato inoltre che tu ogni volta che ho messo { e } me le levi ogni volta; ma perchè ? non si capisce più dove inizia l'if e dove finisce ..!
Se non operi overvolt e stai all'interno delle frequenze di progetto della CPU non la danneggi.
Comunque se hai notato mi sono contraddetto da solo in quanto ho levato il count, ma ho dichiarato un ListIterator :p
Io ho compilato un kernel con il supporto ZRAM e con 10MB recuperati dalla RAM occupata dal kernel stesso comunque... Non sono esattamente estraneo a quei meccanismi di funzionamento ;) in più ho alle spalle 3 anni di ingegneria, non vuol dire niente, ma non credo che mi insegnino cazzate... Se è così rivedo un po' i miei progetti
In ogni caso tutte le variabili allocate vanno ad occupare RAM: int=32/64 bit(2), char=16 bit, double=32/64 bit(2), long int= 2*int, String= length*char per gli oggetti, le collections, eccetera dipende dal contenuto... Non ti aspettare che un programma sia già bello allocato in RAM una volta caricato, ma si alloca le sue variabili real-time quando tu le dichiari(1)... (1. Mai programmato in C puro? 2.le indicazioni 32/64 bit si riferiscono al tipo di architettura della piattaforma su cui devi lavorare)
Sono già implementati e gestiscono la memoria per conto loro, i miei prof dicono che usando gli iterator eviti di dover stare tu a pensare ai limiti dell' "array", gestendotelo loro eviti di incappare in errori tipo core dump... Tutto lì...
Allora... Se noti ho tolto le graffe solo dove c'è una sola istruzione nell'if... Almeno... Io sono abituato così:
- se l'if deve eseguire una sola istruzione, indento l'istruzione sotto l' if o addirittura la metto di fianco senza andare a capo (tanto il compilatore capisce)
- se l'if comprende più istruzioni, allora devo far capire al compilatore che sono tutte all'interno del blocco, quindi le racchiudo tutte tra le graffe
E' come sempre una scelta puramente stilistica, io trovo il codice più pulito così, ma se ti crea casino, mi adatterò io ;)
Le frequenze di proggetto sono quelle usate dalla cpu che senso ha usare meno di quello collaudato
"Niente" era nel senso poco, so perfettamente quello che dici, (si ho lavorato in C e conosco a grandi linee l'assembler x86) ma le cifre sono troppo esigue per creare dei problemi!
Sinceramente non soffro i limiti degli array (non so nemmeno a cosa ti riferisci), poi se è meglio cosi mi adatto..
Be in python dove non ci sono le {} si ha un sistema perfetto, in java si ha altrettanto secondo me con le {} se in java non si usano le {} per me si crea casino (sopratutto mettere if e conseguenza in una riga..)
Fixato il problema! Apk disponibile!
Boh... Ad esempio il processore del GT-S7500 è garantito lavorare con frequenze massime prossime agli 1,3GHz (caratteristiche di progetto), se poi è stato impostato a 1008MHz sono scelte del produttore per non forzare troppo la CPU, ma di per sé l'overclock, non accompagnato da overvolt (sia chiaro), finché sta nelle caratteristiche di progetto non è un danno così grosso. Certo magari il processore si scalda un po' di più e al posto di durare 4 anni ne dura 3 e mezzo, ma è comunque la parte del cellulare che si rompe per ultima vista la durata degli oggetti tecnologici al giorno d'oggi (che muoiono subito dopo la scadenza della garanzia, manco avessero un timer all'interno :p)
Altro discorso è dire che l'overclock a livello di uso quotidiano su un telefono è inutile, in quanto la maggior potenza si fa sentire solo sui Benchmark ;)
Non ho mai usato il python, ergo non so a che ti riferisci con sistema perfetto (forse che in python la priorità è data dall'indentazione e non dalle graffe?), ma ti assicuro che se non usi le graffe sugli if - else o sui for (a patto che il costrutto contenga una e una sola istruzione) il compilatore capisce perfettamente, in quanto il Java è derivato dal C e eredita questa "utile" (per me) caratteristica