di Apple iOS linee guida per gli sviluppatori di stato:AppStore/App iOS e codice interpretato: dove tracciano la linea?
3.3.2 - Una domanda non può in sé installare o lanciare altro codice eseguibile con qualsiasi mezzo, compreso senza limitazione attraverso l'uso di un'architettura plug-in, chiamando altri framework, altre API o altro. Nessun codice interpretato può essere scaricato o utilizzato in un'applicazione, ad eccezione del codice interpretato ed eseguito dalle API documentate di Apple e dagli interpreti incorporati.
Supponendo che il download dati - XML come e immagini, o di una descrizione livello di gioco, per esempio - (? Come è la mia impressione) in fase di esecuzione è permesso, mi chiedo dove tracciare la linea tra "dati" e "codice". Immagina lo scenario di un'app che offre "presentazioni" interattive agli utenti (ad esempio un sondaggio, ad esempio). Le presentazioni vengono aggiunte continuamente al server e diverse presentazioni sono rese disponibili a diversi utenti, quindi non possono essere parte del download iniziale dell'app (che sarebbe l'intero punto). Essi sono descritti in formato XML, ma essendo interattivo, potrebbero contenere branching condizionale di questo tipo (mostrato in forma pseudo per esemplificare):
<options id="Gender">
<option value="1">Male</option>
<option value="2">Female</option>
</options>
<branches id="Gender">
<branch value="1">
<image src="Man" />
</branch>
<branch value="2">
<image src="Woman" />
</branch>
</branches>
Quando questo XML viene interpretato e "suonato" all'interno dell'applicazione, il sopra sarebbe presentato in due fasi. Prima viene visualizzata una schermata di selezione, in cui l'utente può fare clic su una delle due scelte ("Maschio" o "Femmina"). Successivamente, un'immagine sarà [scaricata dinamicamente] e visualizzata in base alla scelta effettuata nel passaggio precedente.
Ora, da questo, è facile immaginare tag aggiuntivi, che descrivono ulteriormente la logica. Ad esempio, potrebbe essere aggiunto un tag contenente:
<loop count="3">
<options... />
<branches... />
</loop>
Il risultato qui è che la coppia di schermi schermo/immagine di selezione sarà presentata sequenzialmente tre volte, naturalmente.
Oppure immagina un formato che descrive un livello in un gioco. È forse naturale considerarlo come "dati" passivi, ma se include, ad esempio, diverse porte che l'utente può attraversare e con vari trigger, trappole e punti ad esso collegati ecc., Non è lo stesso che usare un script (o, in effetti, codice interpretato) - per descrivere sequenze di esecuzione, opzioni e le loro risposte condizionali?
Supponendo che il motore di interpretazione per i dati sia già presente nell'app e che tali "presentazioni" possano essere solo consumate (non create o modificate) nell'app, come farebbero queste tariffe rispetto alle linee guida iOS di Apple? XML non costituisce fondamentalmente un linguaggio di scripting in questo senso (non si può descrivere alcun programma in un linguaggio interpretato in XML)?
Va bene se il linguaggio di scripting proprietario (ref XML utilizzato in precedenza) era strettamente in modalità sandbox (come si può dire?) E non ha dato l'accesso al sistema operativo in alcun modo (ma in grado di scaricare contenuti - come un sondaggio o livello di gioco - dinamicamente così come risultati di upload - risposte o punteggi - al server di sviluppo)?
Dove va la linea?
Non si può sapere esattamente. Solo Apple lo sa. Vedi, Codea che usa un interprete Lua incorporato e lascia che il codice di scrittura dell'utente abbia ottenuto con successo il filtro. –
Interessante. Anche se sono più interessato alla possibilità di scaricare nuove "presentazioni" ("script", se lo farete) di quanto l'utente sia in grado di scrivere/modificare codice * localmente *. – d7samurai
Credo che l'utente sia in grado di eseguire liberamente qualsiasi codice è ben oltre ciò che si desidera :) Quindi direi che la tua app è accettata ha maggiori possibilità di non essere accettata, ma, chissà, ancora una volta. –