wow, ke figata!
Inviato dai miei Google Glass con CyanogenMod 11 Key Lime Pie
Visualizzazione stampabile
io sto lavorando a quelle di WApp, Viber e Skype, WhatsApp e Viber sono pressoché identici, solo una verde ed una viola
Inviato dai miei Google Glass con CyanogenMod 11 Key Lime Pie
Implementarlo tipo fragment, mi rimetto alla tua esperienza che sicuramente ne sai più di me... fare ad esempio una chiamata del genere: Main Activity --> swipe su --> animazione entrata drawer (magari senza icone gestire un'anteprima mi pare più ostico, ma si può aggiungere in seguito) --> drawer implementato come (extends) fragment (ovvero un activity indipendente all'interno della main) Tutto questo in modo da poter gestire il drawer come un oggetto (forse già lo gestisci così, ma in modo diverso), che forse risulta più semplice anche dal punto di vista dello sviluppo...
Ma come ti ho detto mi rimetto alla tua esperienza, sto tirando ipotesi in base a quel poco di teoria che so e di documentazione che ho letto, soprattutto senza avere del codice sotto mano è ostico.
Comunque ti rinnovo l'invito a commentare ogni riga se necessario, soprattutto in vista della messa online per quando anche noi altri sviluppatori potremo dare un occhio la tuo lavoro fatto finora ;) Più che altro perché ho visto che anche tu ti sei lamentato delle poche indicazioni presenti sul launcher AOSP
Io sto seguendo un altra strada cioè abbiamo la barra sotto (quella da tirare su per aprire il drawer), sotto di essa c'è il drawer (ancorato, con il parametro below del relative layout). Il drawer è un include del layout drawer (che fantasia :P), questo è composto dalla barra sopra con i tab (application e favourites se non erro), un scroll view verticale che contiene un grid layout. Il grid layout non ha figli infatti dal codice gli viene assegnato un adapter custom (gestito da una classe esterna). E' un pò complicato a dirsi ma facile a capirsi xD
Per quanto riguarda i commenti sto commentando un pò tutto (sia italiano che inglese).
EDIT:
Ecco una preversione
http://i42.tinypic.com/2s7c7s7.png
Naturalmente manca il touch ma non credo di metterci molto a implementarlo
Ma sarà poi possibile cambiare lo sfondo sotto le funzioni del launcher??
Comunque ottimo lavoro fin ora!!
Lo trovi nella prima pagina (non è un vero e proprio screen ma l'ho fatto io al pc ed è più o meno così che dovrebbe venire)
guardate un po qua se può interessarvi:
[ICONS]Metro Icons *Metrosphere* - xda-developers
non so se sono vettoriali, ma sono già qualcosa, no?
Io ho conoscenze basilari di Java (sto studiando all'uni). Se posso essere utile ne sarei lieto
Ho provato il launcher , e anche se inutilizzabile è molto bellino , ma vorrei vederlo adattato a tablet
Sorgenti aggiornati:
- Drawer disponible
- Icone drawer auto-resaizanti (nel caso qualche app abbia icone anomale vengono automaticamente aggiustate)
- Avvio app da drawer disponibile
- Alcune parti di codice commentate
Problemi:
- Nel drawer il testo dell'icona sopra spesso sbatte con l'icona sotto
- C'è uno strano problema nella barra drop down (ogni tanto si blocca nella parte bassa dello scermo e non si riesce a schiodarla da li :P)
- Devo finire di commentare il codice (scusa loxdegio non sono riuscito)
Vi prego di segnalarmi altri eventuali problemi :)
è il file NowLauncher-debug-unaligned.apk
o NowLauncher-debug.apk?
Ho installato NowLauncher-debug.apk, tutto ok... ho notato una cosa strana.... Il 4 collegamento sulla sinistra quello in basso si vede solo in parte U.u
http://img.tapatalk.com/d/13/05/26/a9ureju3.jpg
C'è qualche problema nell'interfacciamento con eclipse :p
Ho visto i sorgenti, spero non ti dispiaccia se ti ho ritoccato un po' il codice... Nulla di sostanziale, solo modifiche formali. In particolare ho sostituito quegli orribili if - else indentati con dei più estetici if - else if - else, so che è una pura scelta stilistica, ma per me è più pulito così :p
Errori vari in res/layout/dock.xml (per eclipse almeno) e manca res/values/ids.xml
Se ho altri dettagli te li aggiungo in seguito con calma ;)
Non uso e odio eclipse quindi non so dirti..., non ci sono errori di compilazione quindi non so perchè ti da problemi in dock.xml (?)
Hai provato a vedere se funziona dopo le tue modifiche ?
EDIT:
Riaggiornati i sorgenti con alcuni miglioramenti di identazione e aggiunte di commenti
Stavo cercando di testare il launcher (ho installato il file 26-05-2013-21-44-20_NowLauncher.apk ) su un galaxy nexus 4.2.2 ma appena lo faccio partire mi dice che l'applicazione si è bloccata in modo anomalo.
Allegato 63726
E dove lo trovo?
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
Sicuramente hai ragione tu, comunque lo stesso mantenere la cpu alla frequenza con cui è pubblicato il cell è una garanzia inoltre come dici te fa durare di più la baracca ! :)
No no non intendo che il compilatore non capisce ;) lui capisce perfettamente, sono io invece che mi trovo male con questa sottilissima distinzione tra condizione e conseguenza.
Sono appena riuscito a mettere il repo a posto, però ho usato delle source precedenti ai list iterator, se riesci tu adesso se no io più tardi li ripristino
Sì... Infatti ho sottolineato che è una scelta stilistica e che mi sarei adeguato alla tua scelta in caso ti facesse qualche problema, io ci ho messo un anno intero ad abituarmi alla scrittura senza graffe, quindi capisco che ti trovi spaesato, ma una volta che ci fai l'abitudine ti sembra che il codice sia molto più pulito senza graffe inutili che devi ricordare di chiudere ogni volta (è anche per quello che le uso solo quando necessario)
Ho notato... Il fatto è che nella definizione del ListIterator mi ero dimenticato di mettere il <Tipo> :p per forza dava errore XD, Sorry ora faccio un pull e aggiorno
EDIT: Aggiornato... Prova a compilare... Ora dovrebbe andare ;)
Per evitare di pestarci i piedi non conviene dividersi gli ambiti ?? Per esempio gui, client meteo, client face, servizi in background...
2 errori di compilazione.
ecco il secondo errorecodice:MainActivity.java:159: cannot find symbol
[javac] symbol : variable count
[javac] location: class com.nowlauncher.nowlauncher.MainActivity
[javac] mApplications = new ArrayList<AppInfo>(count);
[javac] ^
Io adesso non posso se non riesci tu pià tardi ci do un occhio iocodice:MainActivity.java:165: incompatible types
[javac] found : java.util.Iterator<android.content.pm.ResolveInfo>
[javac] required: java.util.ListIterator<android.content.pm.ResolveInfo>
[javac] ListIterator<ResolveInfo> i=apps.iterator();
[javac] ^
Risolto... Avevo solo dimenticato le basi fondamentali delle List... Poca cosa direi :s Comunque pushato e ora dovrebbe essere corretto... Per la divisione dei compiti mi sta bene... Ma devi sopportare almeno fino a luglio che io faccia solo qualche ritocco al codice, non per distruggere il tuo lavoro, sia chiaro, solo per ingegnerizzare e ottimizzare l'app che ne verrà fuori, anche perché ora con gli esami ormai a distanza di un mese non ho tempo né testa di colmare le lacune che mi mancano nel passare dal Java puro alla programmazione Android, ma sto preparando l'esame proprio di Java per darlo a luglio prima possibile, quindi dal punto di vista del linguaggio posso darti una mano visto che ho freschissima (o quasi, visti gli errori stupidi che ho fatto) la documentazione in mente, ma dal punto di vista creativo rimarrò stagnante ancora un po'... Mi dispiace :'(
Nessun problema, per ora lavorerò io da solo, comunque due occhi sono meglio di uno; per carita ognuno ha le sue preferenze stilistiche ( vedi {, }) ma due occhi vedono sempre meglio la soluzione migliore :)
Compilazione avvenuta con successo, app caricata su git!
Provando cosi a stilare una lista verrebbero questi lavori da fare:
- GUI (main_activity.java, appinfo.java e adapter)
- Facebook client (facebook.java)
- Google+ client (google+.java) <-- Si può usare il + nel nome di una classe ??
- Servizio (service.java)
- Meteo (weather.java)
- Musica (music.java)
- Messaggi (messagging.java)
- Twitter (twitter.java)
- News republic - Ansa - corrirere - borsa .... client (news.java)
In particolare io ho messo un servizio nel senso di mettere anche un servizio in background che si occupa di sincronizzare ogni tot tutto (meteo, face..). Ora è corretto usarlo o è meglio che si sincronizza a ogni avvio ( o resume) ?, teoricamente dovrebbe rendere più fluido il resume dell'app (nessuna perdita di tempo al lancio) però oltre a rompere le scatole ogni tanto per aggiornarsi (possibili lag durante l'uso del cell) consuma anche ram. D'altro canto però il consumo di ram può non essere cosi rilevante dato che il grosso dei dati sono testuali (ll eventuali immagini dei social risulterebbero poi ridimensionate ). Tu cosa ne pensi ?
Non è tanto un problema di consumo di RAM (da quel che ho capito non è un launcher con target ldpi) quanto quello della batteria... Si avrebbe un battery drain incredibile, bisognerebbe trovare il modo di far impostare, tramite opzione nei settings, il sync manuale o automatico e l'intervallo di aggiornamento... Anche se continuo ad essere dell'idea che aggiungere queste funzioni in stile "widgets" ovvero "se le voglio le attivo sennò ci metto qualcos'altro" dia più libertà all'utente, anche perché io personalmente non installerei mai nulla che mi impone cosa usare (sono passato stabilmente a linux, tenendo windows solo per giocare (anche se ancora per poco) proprio per l'alto grado di personalizzazione del pinguino: cambio GUI come cambio maglia XD)... In somma... Non dico che l'idea dell'integrazione social non sia un'ottima idea, ma l' "imposizione" di queste features sarebbe meglio fermarla alla fase beta, per poi passare al supporto widgets (che poi mi studierò ;))
Ora... Per l'interfacciamento con i vari servizi, bisognerebbe sapere intanto quali API usare (Social Network, News [RSS??]), e a quale tipo di servizio appoggiarsi (Meteo). Per il Media Player non ci dovrebbero essere grossi problemi visto che ci sono delle librerie di supporto offerte da Google nel SDK
vi sto seguendo da quando avete cominciato il progetto... Mi sono letto tutto... xD E ho provato tutte le varie versioni che state creando del launcher...
Prima di inserire cose tipo: social network, meteo, musica... quelle sono cose secondarie per ora secondo me... Perchè non provate a modificare il drawer in modo che non resti aperto a metà ma sia come la tendina cioè che sta o chiusa o aperta U.U
Eh inoltre in poche parole prima di inserire le cose diciamo secondarie, renderlo utilizzabile... in modo che si comincia a provare ;)
Il battery drain dici.. uhm perchè mai ? Se ogni tot avviene il sync mentre è in attesa non dovrebbe consumare batteria
Approvo, nella fase iniaziale di sviluppo solo modo widget predefiniti poi anche il supporto a widget terzi. Infine potremmo creare anche un interfaccia ibrida.
Be le api credo siano il minimo di difficoltà a naso eccone alcune
Facebook --> Facebook SDK for Android - Facebook-Entwickler
Twitter --> Twitter4J - A Java library for the Twitter API
....
Per il servizio meteo propongo ilmeteo.it, credo sia il più semplice da implementare come api.
Si hai ragione vedremo di provvedere
Comunque devo dire che avete fatto un ottimo lavoro!
No... Certo... Ma minimo il sync dovrebbe avvenire ogni 10 minuti di default, non ho ancora visto un servizio con sync meno frequente, (c'è anche chi lo vorrebbe in tempo reale, ma vabbè) il fatto è che è troppo frequente per la batteria, conta che ogni 10 minuti c'è anche il sync telefonico con l'operatore e altre balle così, che coincidano o no il consumo di batteria è notevole... Il telefono non arriverebbe a fine giornata, tanto meno se abbiamo sync google + facebook + twitter + quello di default dell'operatore
Beh se ci sono API disponibili per tutto va benissimo :p
Come stai dicendo tu: effettivamente queste sono cromature, abbellimenti... Concordo, non ho nulla da ribattere, ma per sviluppare nel modo migliore un progetto non si può considerare una cosa alla volta... Bisogna avere ben chiaro nella mente il prodotto finito... E' come costruire un palazzo: ancora prima di costruire le fondamenta devi avere a mente le camere e gli spazi vuoti interni in modo da poter piazzare pilastri nei punti giusti, se non consideri tutto a priori rischi che a prodotto finito il palazzo crolli, o nel caso di un'app come questa che il tutto non si integri nel modo giusto e si ha un lavoro di mer*a da riprendere tutto da capo