Change visible property sometimes change the center position of the view (possible bug?)

79 views Asked by At

I've 3 (loader, locker and debug view) hidden views (touchEnabled and visible set to false, and zIndex to 1) above the main view (zIndex = 2).

Each 'over' view has this method:

$.debugView.show = function() {

    $.debugView.touchEnabled = $.debugView.visible = true;

    $.debugView.zIndex = 3;
};

$.debugView.hide = function() {

    $.debugView.touchEnabled = $.debugView.visible = false;

    $.debugView.zIndex = 1;
};

This screen has the 3 'over' views hidden:

enter image description here

Now, I'm opening the 'debug view', but, SOMETIMES it seems like it changes the positions (as if the center it's on the top left corner instead of the center of the device).

enter image description here

Instead of the required result:

enter image description here

If I use the opacity instead of the visible property, it works properly.

This might be an SDK bug right?

<Alloy>
    <Window>
        <View id="content"/>
        <View id="locker"/>
        <View id="loader"/>
        <View id="debugView"/>
    </Window>
</Alloy>

All of these 4 views don't have width or height (so it uses the Ti.UI.FILL as default)

1

There are 1 answers

3
Rene Pot On BEST ANSWER

I have noticed this too with a completely different implementation. I had just one view that I included in a window.

Apparently the left and top calculations were not done properly if the elements is hidden.

What I did to solve the issue is to hardcode the left/top position by calculating the left position using this:

$.content.left = (Ti.Platform.displayCaps.platformWidth - 75) / 2;

Where in my case 75 is the width the element has, so that'll be bigger in your case. You can do the same for height.

Now, this is an iOS only solution. On Android you will need to take DPI into consideration calculating it.

I do think it is a bug, though this solution works perfectly for me. I recommend looking at JIRA and see if it is a known issue, and if not, raise it with a very specific explanation of the problem, preferably with a reproducible case delivered as an app. Classic would help most. And if it is not reproducible in classic it might be an alloy issue.