Démo de marge négative:
Le scénario
Chevauchement de vues en définissant une marge négative sur l'une d'entre elles afin qu'elle envahisse le cadre englobant d'une autre vue.
Pensées
Cela semble fonctionner comme vous vous attendez avec le chevauchement des mises en page si elles le devraient. Mais je ne veux pas me heurter à un problème plus grave pour ne pas faire les choses correctement sans le savoir. Émulateurs, périphériques physiques, nommez-le, lorsque vous utilisez des marges négatives, tout semble fonctionner correctement, une vue envahit la zone de délimitation des vues d'une autre et selon la façon dont elle est déclarée dans la mise en page, elle sera au-dessus ou en dessous de l'autre vue.
Je suis également conscient que depuis l'API 21, nous pouvons définir les attributs translationZ
et elevation
pour faire apparaître la vue au-dessus ou en dessous d'autres vues, mais mon inquiétude vient essentiellement du fait que dans la documentation des layout_margin
attributs, il est clairement spécifié que les valeurs de marge doivent être positives , laissez moi cite:
Extrait:
spécifie un espace supplémentaire sur les côtés gauche, supérieur, droit et inférieur de cette vue. Cet espace est en dehors des limites de cette vue. Les valeurs de marge doivent être positives . Doit être une valeur de dimension, qui est un nombre à virgule flottante ajouté avec une unité telle que "14.5sp". Les unités disponibles sont: px (pixels), dp (pixels indépendants de la densité), sp (pixels mis à l'échelle en fonction de la taille de police préférée), in (pouces), mm (millimètres) ...
Au cours des années à l' origine de cette demande question que je ne l' ai pas eu de problèmes avec des marges négatives, ont essayé d'éviter de les utiliser autant que possible, mais ne pas rencontré de problèmes, de sorte que même si les états de documentation, je ne suis pas trop inquiet à ce sujet.