Antonio BarbaCon ben 305 MB di file APK (di cui 299MB di immagini in alta risoluzione, 5MB di filmato introduttivo, e soli 25KB di codice), sviluppare e debuggare questa applicazione sta diventando rapidamente un'impresa. 5 minuti solo per uploadare l'APK su telefono :-PS: ... e devo ancora aggiungere altri 145MB di contenuti audio!PPS: ... maratona di coding non stop fino al rilascio sul marketplacePPPS: ... tempi di sviluppo risicatissimi => I do little to no testing at all!Utente XScusa l'ignoranza, ma non c'è il limite di 50 mb per un'app? (teoricamente...) Antonio BarbaSi, infatti il prossimo step consiste nello scorporare la cartella "asset" in un Expansion Pack esterno e lasciare l'APK di base a "soli" 7MB cfr. http://developer.android.com/guide/mark ... files.htmlUtente XQuesta feature è stata inserita da poco o sbaglio? Forse per far fronte alle nuove necessità... molto comoda come cosa, sopratutto perché è gestita sempre tramite il market! Antonio Barbaè stata inserita meno di 24 ore fa... questa sarà probabilmente la primissima applicazione ad usare tale framework (more difficult!!) Utente XCavolo, complimenti!!! Antonio BarbaComunque questo stratagemma degli Expansion Packs per arrivare a 4GB è un casino, ho dovuto fixare un paio di bug nella libreria di supporto ufficiale:1. apre lo stesso file N volte, dove N è il numero dei file zippati in esso contenuti. Dal momento che ho caricato un file zip con centinaia di files, crashava più o meno verso la metà perchè sfondavo il limite dei file aperti simultaneamente (bastava mettere un banalissimo File.close() in fondo ad un ciclo for)2. Riesegue la verifica del CRC32 ad ogni avvio. Per fixarlo ho inserito un "verification file" che serve a skippare velocemente la fase di CRC dal secondo avvio in poi. Viene generato tale file, e memorizzato nella cache, se la passata di CRC32 e la decompressione dell'archivio avviene con successo. Dal secondo avvio, l'applicazione controlla solo tale file e poi tira dritto. Se l'utente cancella la cache, allora la decompressione avverrà nuovamente (ho usato Context.getExternalCacheDir() per memorizzare i dati decompressi).Inoltre tale sistema è scomodo perchè:- puoi scaricare max 2 file (quindi ricorrere allo ZIP è quasi obbligatorio)- se decomprimi il file zip, poi NON puoi cancellare il file temporaneo scaricato dal market, altrimenti la libreria ufficiale tenterà di scaricarlo nuovamente, quindi sprechi molto spazio sulla SD dell'utente (questo bug non ho avuto il tempo di fixarlo)- Il codice deve conoscere a priori la dimensione del pacchetto da scaricare, questo implica che: a) ti serve un servizio web da consultare per verificare la nuova dimensione di un eventuale aggiornamento; oppure b) ricompilare anche il codice e uppare un nuovo APK per ogni aggiornamento dell'Expansion Pack- La libreria di Google controlla il CRC32 dei file zippati, ma tali pacchetti non hanno alcuna firma digitale (diversamente dall'APK), per cui è relativamente facile iniettare dati estranei (eventuali sistemi crittografici sono delegati allo sviluppatore).Insomma, come al solito Google fa delle porcate assurde e invece di semplificarci la vita, ci rifila (a noi developers) enormi pali nel culo ad ogni update.[...]Antonio BarbaDiciamo che uno dei pochi vantaggi degli Expansion Packs è quello di poter uppare i pacchetti sul Market, quindi elimina i costi di fileserving (che possono essere molto elevati per applicazioni popolari).
La prima che hai detto: ti diverti di più. :mrgreen:
Autore
Topic: [Android] Expansion File (a.k.a. pain in the butt) (Letto 2432 volte)
