This seeks to resolve #81 by only modifying a UIScrollView subview's zPosition if the zPosition is either 0 (meaning the developer has made no zPosition choice or has left it at the default level) or 1 (where the developer has opted to try and get the subview above the default, but the move of the stretchy header view to this zPosition could cause a conflict).
With this change, developers should be able to modify their zPosition of subviews to make them show over or under the stretchy header view however they choose so long as they get out of the range of 0-2. It seemed a bit overkill to add a protocol to ask the subview if it has a preferred zPosition since most devs will just mess with zPosition numbering until they get something that works.
Coverage remained the same at 97.135% when pulling 8400416ab99e443f7f93b46291706ca69b7e6f40 on ChargePoint:subview_zPosition into 16b40a07924fb1203680ed8301ad90befc21afa3 on gskbyte:master.
This seeks to resolve #81 by only modifying a UIScrollView subview's zPosition if the zPosition is either 0 (meaning the developer has made no zPosition choice or has left it at the default level) or 1 (where the developer has opted to try and get the subview above the default, but the move of the stretchy header view to this zPosition could cause a conflict).
With this change, developers should be able to modify their zPosition of subviews to make them show over or under the stretchy header view however they choose so long as they get out of the range of 0-2. It seemed a bit overkill to add a protocol to ask the subview if it has a preferred zPosition since most devs will just mess with zPosition numbering until they get something that works.