Colpite il limite superiore per le funzionalità API di Cross Platform

3

Sono un programmatore junior che lavora come stagista (8 mesi nel tirocinio) in una squadra di 1 (solo me stesso) che crea app per telefoni cellulari e amp; siti web.

Ho creato un'app che funziona esattamente come dovrebbe & ha alcune funzionalità interessanti ma l'App non funziona su Android (la piattaforma di destinazione principale per noi, funziona sull'emulatore desktop ma non su Android) a causa dei problemi di memoria con le app di grandi dimensioni nell'API Mosync (vedi i link per maggiori informazioni informazioni sul problema della memoria). L'aspetto più demoralizzante del problema è che (come spiegato nei link sottostanti) l'app si blocca casualmente & non costantemente, quindi fai un cambiamento eseguilo sulla piattaforma un paio di volte e amp; dove qualcosa ha funzionato prima che si blocchi ora causa l'arresto anomalo dell'app (il sistema operativo Android uccide la mia app).

link link

Ho investito 4 settimane nello sviluppo dell'app (un calendario interattivo) & 5 mesi per l'apprendimento dell'API Mosync per le app che non funzionano sulla piattaforma.

Il mio problema: devo decidere tra scaricare l'app & riavviare l'app in Java nativo Android (conosco Java) o ridurre drasticamente il numero di risorse (.pngs) e amp; caratteristiche dell'app (effetto polaroid che produce) per farlo funzionare nella piattaforma Android. Il risultato finale sarà funzionale ma di bassa qualità (in termini di grafica) & semplice.

Cosa gli sviluppatori più esperti decidono di fare e amp; come spiegheresti questa decisione / raccomandazione al tuo capo non tecnico?

    
posta Mack 19.08.2011 - 09:40
fonte

2 risposte

2

Farei una traduzione in Java. Salva il più possibile l'architettura dell'applicazione. Con le app mobili in particolare, la presentazione è davvero importante e le immagini nitide aiutano molto su un piccolo schermo. Prendi tutte le idee che funzionano e re-craft piuttosto che abbattere il codice base.

L'ho fatto con un'app per iOS e non ho terminato la seconda build prima che la classe su cui stavo lavorando fosse finita. Mi sono ritrovato con un film di simulazione fatto manipolando manualmente l'interfaccia utente in GIMP e poi unendo ogni fotogramma. Non consiglio questo metodo per il codice di produzione reale. Potrei aver ottenuto un A per sforzo e una buona relazione ma non credo che otterresti la stessa accoglienza.

Quindi, se conosci Java, eseguilo in Java nel miglior modo possibile. Scalare verso il basso sarebbe probabilmente meno efficace a lungo termine rispetto a una versione iniziale un po 'buggy ma stabile che sembra carina e funziona in modo stabile con alcuni intoppi rispetto a un'app che sembra orribile e che funziona senza intoppi. I bug possono essere risolti, il design pessimo è più difficile da correggere. Spogliatelo fino all'osso se necessario, ma cerca di non buttarlo via completamente.

Per quanto riguarda il capo, fai una domanda simile a questa domanda: preferiresti pubblicare presto un prodotto di bassa qualità che potrebbe farci sembrare scadente o un'applicazione più originale che ci fa sembrare grandiosi?

    
risposta data 19.08.2011 - 10:06
fonte
1

Non so su Android, ma spesso puoi fare ricorso a PNG basati su palette (si avvicinano a GIF piuttosto che a JPG), compressione e cose del genere. Vedi dove puoi riutilizzare le cose. Non è necessario un intero pulsante se è possibile combinarlo da PNG ultra-piccoli. Alcune cose possono essere generate dinamicamente, gradienti ecc ...

Quanta memoria utilizza la roba? Qual è l'importo obiettivo? Quanto pesa il codice / risorse?

    
risposta data 19.08.2011 - 11:37
fonte

Leggi altre domande sui tag