Comprendre la structure de l'alliage

Question

Je développe une application avec un alliage de titane. J'ai plusieurs fichiers XML. Chaque fichier xml a la même vue et chaque ID de vue et fonction est identique. cette approche est correcte ou dois-je assigner un identifiant différent et une fonction nommée différente pour tous les objets afin d'éviter les fuites de mémoire. Je veux dire que chaque proxy de xml est identique ou différent sur la mémoire?

home.xml

<Alloy> 
    <Window id="home"> 
<View id="Container" onTouchend="fooFunction"> </View> 
</Window> 
</Alloy> 

detail.xml

<Alloy> 
    <Window id="detail"> 
<View id="Container" onTouchend="fooFunction"> </View> 
</Window> 
</Alloy> 

other.xml

<Alloy> 
    <Window id="other"> 
<View id="Container" onTouchend="fooFunction"> </View> 
</Window> 
</Alloy> 

Et comment nettoyer l'objet de mémoire lorsque je ferme la fenêtre pour éviter les fuites de mémoire?

Édité pour l'événement de fermeture de fenêtre afin d'empêcher une fuite de mémoire;

$.detail.addEventListener("close", function() { 

     // this listerner creates when window open for paused app event 
     Ti.App.removeEventListener("app:RefreshJson", fncRefreshJson); 

     $.Container.removeAllChildren(); 
     $.detail.removeAllChildren(); 

     $.removeListener(); 
     $.destroy(); 

    // listview creates on the fly when new window opens 
    // then I am adding it into $.Container 
     listView = null; 
     $.detail = null; 

    }); 

Answer 1

Des docs: ID doit être unique par vue, mais ne sont pas globales, si plusieurs vues peuvent avoir des composants avec le même ID.

Votre approche est correcte. Quelques notes

• Si l'ID est omis de la composante de haut niveau dans la vue, puis alliage adoptera le nom de fichier comme identifiant. Donc, si vous avez omis id="home", alors dans home.js, vous feriez toujours référence à l'objet de la fenêtre comme ... $.home puisque c'est le nom du fichier. CamelCasing est le format commun à utiliser dans Alloy, donc View id="container" pourrait être le chemin à parcourir.
• Des fuites de mémoire spécifiques à l'alliage peuvent se produire avec la liaison de données. Les liaisons doivent donc être properly destroyed. Autre que cela, les mêmes conseils Memory Management devraient s'appliquer. Le plus important est de ne pas utiliser d'écouteurs d'événements globaux. Si nécessaire, vous pouvez utiliser Backbone Events à la place.

Personnellement, je l'ai trouvé plus facile d'utiliser le même identifiant pour toutes mes fenêtres, comme <Window id="win"> (et $.win dans le contrôleur) donc lors du passage autour entre contrôleurs de vue, je ne dois pas regarder ou rappelez-vous ce que le nom ou le nom de fichier est pour cette fenêtre particulière.

Answer 2

Mon article sur ce sujet a trois ans. Mais, dans un balayage rapide, je pense que tout s'applique encore aujourd'hui. http://www.tidev.io/2014/03/27/memory-management/

Et comment nettoyer l'objet de la mémoire lorsque je ferme la fenêtre pour éviter les fuites de mémoire?

Cela dépend:

Si la fenêtre fait partie d'un groupe d'onglets, il restera en mémoire tant que l'application est en cours d'exécution.

Si c'est une fenêtre qui est ouverte dans un groupe de navigation ou dans une pile de fenêtres sur Android, cela dépend de la façon dont vous avez instancié la fenêtre.

// if you do this: 
var win = Alloy.createController('detail').getView(); 
win.open(); 

// then to clean up, after 
win.close() 
// you need to 
win = undefined; 

// which is why it's better to do this if you can 
Alloy.createController('detail').getView().open(); 

// then, inside of detail, you'd call its Window.close() 
// method which would close the window and remove the 
// last reference in memory and the object would be GC'd 

En aparté, si vous créez vraiment plusieurs fenêtres avec le code aussi similaire que vous montrer ci-dessus, vous devriez peut-être créer un widget. Vous passeriez en définissant des caractéristiques (options, noms, vues enfants, etc.) lors de l'instanciation du widget. Cette technique ne sera pas nécessairement utile avec la gestion de la mémoire ou la performance. Mais, cela aidera à éliminer le code en double.