jquery alternative mobili (e qual è il collo di bottiglia?)

Question

Sono in procinto di rilasciare la mia prima app in JQM. Fondamentalmente, pagine geografiche dinamiche con listview. Niente di eccezionale in termini di design. Quindi mi piace molto il look di base & sensazione di JQM.

Non l'ho ancora eseguito con PhoneGap. Lo sto testando come un'applicazione web su firefox sul mio desktop ed è davvero bello e funziona senza problemi. L'ho provato come webapp su safari sul mio iPhone 3GS ed è completamente inutile: sfarfallio dello schermo, transizioni che mi ricordano Mosaic su un modem 33,6K.

Ho visto su stackoverflow che ci sono molte modifiche che migliorano JQM come non usare le transizioni. Ma qual è il punto?

Qual è il collo di bottiglia? È JQuery stesso e la sua gestione di IE? Spiacente, non posso aspettare per JQuery versione 2.0.

Ho visto che alcune persone consigliano di utilizzare zepto.js come alternativa. Ma zepto.js non supporta il css JQM. C'è una soluzione semplice per usare zepto e non è necessario rifare la progettazione di base che fornisce JQM?

Non voglio ancora diventare nativo dal momento che mi piacerebbe avere la mia app in esecuzione su IOS e Android senza dover imparare Obj-C e tornare a Java.

Ci sono state numerose discussioni su questo, ma l'ultimo che ho visto è stato a giugno.

Ci sono nuove alternative? Se Jquery è il collo di bottiglia, è possibile ottenerne uno che sia vuoto di tutto ciò che non ha come target IOS/Android?

Grazie.

Answer 1

L'idea di JQM è non solo di indirizzare iOS/Android ma tutte le piattaforme, quindi è necessario creare comprosmie che non sono necessari se si sta solo iOS - le transizioni pre JQM 1.1 (che erano molto meglio) sono stati abbandonati a causa di Android credo, perché stavano fallendo così male.

Se stai cercando colli di bottiglia, penso che gli elementi di rendering sul client richiedano tempo. Diciamo che avete un elemento della lista:

<li><a href="some">link</a></li> 

Quale jQm cambierà

<li data-corners="false" data-shadow="false" data-iconshadow="true" data-wrapperels="div" data-icon="arrow-r" data-iconpos="right" data-theme="c" class="ui-btn ui-btn-icon-right ui-li-has-arrow ui-li ui-btn-up-c"> 
    <div class="ui-btn-inner ui-li"> 
     <div class="ui-btn-text"> 
      <a href="index.html" class="ui-link-inherit">Acura</a> 
     </div> 
     <span class="ui-icon ui-icon-arrow-r ui-icon-shadow">&nbsp;</span> 
    </div> 
</li> 

Dal momento che questo è fatto sul client per ogni elemento della lista, roba vuole tempo per il rendering e gli elementi che funzionano perfettamente liscia su il desktop ha bisogno improvvisamente di 2-3 secondi per il rendering su Android scadente.

prima soluzione è quella di inviare enhanced HTML e cercare di non dover chiamare trigger("create") Si può perdere attacchi elemento così facendo, o si dovrà alterare jQm prevedere una modalità di evento-bind-only, che sto facendo quando necessario.

L'altra idea sarebbe quella di archiviare libararies di widget come markup avanzato configurabile. Quindi avresti una listview lib, che ha tutte le varianti di listitems memorizzate come modelli in forma avanzata. Quando esegui il looping di un elenco, devi solo selezionare l'elemento di elenco dalla tua lib, aggiungere dati dinamici e il gioco è fatto.

Entrambi richiedono un sacco di manipolazione, ma è facile da configurare alcuni widget (pulsanti, gruppi di controllo) e risparmiano già un sacco di tempo di rendering.

Spero che questo sia un buon indicatore per iniziare.