Ci sono delle "migliori pratiche" sullo sviluppo cross-device?

Ciò di cui stai parlando è essenzialmente la creazione di una famiglia di prodotti che utilizzano una base di codice comune. Non sono d'accordo con la premessa che dovresti riscrivere gran parte della base di codice per piattaforme diverse. Certo, ci saranno aree specifiche della piattaforma, ma in generale ciò non dovrebbe influenzare la base di codice comune.

La premessa o la pratica di base che fornisce le informazioni più utili sullo sviluppo multipiattaforma è il concetto di design per il cambiamento. Ad un livello più fondamentale, è necessario identificare quali aree sono suscettibili di cambiare e / o le aree che si sa che cambieranno. Nel tuo caso, posso identificare quattro aree che rientrano in questa categoria.

• Interfaccia utente
• Interfaccia hardware
• Interfaccia del sistema operativo
• Set di funzionalità diverse

I primi tre sono decisamente dipendenti dalla piattaforma. Il quarto a mio parere è più una cosa di configurazione, ma è ancora importante dal punto di vista del design.

I primi tre sono abbastanza facilmente isolati estraendo ogni interfaccia dietro un'interfaccia comune. Ad esempio, si dovrebbe avere un livello di astrazione per i servizi del sistema operativo come il controllo semaforo. L'interfaccia dovrebbe essere la stessa dal punto di vista dei codici comuni indipendentemente dal sistema operativo che si sta utilizzando. In sostanza, l'idea è creare interfacce virtuali. Onestamente, questo praticamente definisce il modello di progettazione dell'adattatore. Mi rendo conto che non stai cercando modelli di design specifici, ma spesso i tempi di progettazione risolvono molte delle sfide implicate nella progettazione di un prodotto per più piattaforme perché supportano specificamente la nozione di design per il cambiamento.

Per affrontare il concetto di set di funzionalità variabili, sono importanti le caratteristiche del progetto che hanno un basso accoppiamento con altri elementi nel sistema. Ad esempio, in un documento word, l'opzione di salvataggio non dovrebbe dipendere dal fatto che la funzione di file aperti è abilitata. Dovresti mirare a rendere le funzioni di disabilitazione facili come estinguere l'interfaccia. A questo punto, la creazione di una serie specifica di funzionalità dovrebbe essere in gran parte parte della configurazione della build. In base al prodotto che stai creando, puoi decidere se includere o meno una determinata funzione o un'interfaccia stub. Questa solo una possibile soluzione. Sono sicuro che ci sono altri modi per farlo, ma il concetto è lo stesso.

Direi che la cosa più importante per me è adottare Model-View-Controller . Prendendo Windows / .NET vs Windows Phone / Silverlight, * / JavaSE vs Android / Java o Mac / Cocoa vs iPhone / Cocoa Touch, una buona applicazione MVC può utilizzare gli stessi oggetti del modello e la stessa logica di dominio su più piattaforme. Le viste e il codice per interagire con loro devono essere specifici per ogni situazione, ma quando quel codice è ben contenuto è più facile mantenere più versioni.

Secondariamente, verifica funzionalità, non per piattaforme . Quello che voglio dire è, non farlo:

if (device == phone) {
  // small screen resolution
  // touchscreen UI
}
else {
  // desktop screen resolution
  // WIMP UI
}

... perché a un certo punto, questo inizierà a fallire. Apparirà un telefono con una risoluzione elevata (ad esempio l'iPhone 4) o un dispositivo più grande con un'interfaccia utente touchscreen (ad esempio l'iPad).