fix #6379: beef up runtime styling manual tests

[incanus]

Work in progress to test filtered fills & lines.

[mention-bot]

@incanus, thanks for your PR! By analyzing this pull request, we identified @1ec5, @friedbunny and @boundsj to be potential reviewers.

[incanus]

Got some examples bolted in for styling fills & lines using filters. Both feature Studio-created layers that are well under the normal map layers, showing off some of our runtime styling flexibility.

Map with states fill layer: fill in Texas

Map with counties line layer: restyle all Washington counties

Other than some minor flickering upon styling, things look good.

Next up is adding a numeric-type filter test to flex #6040 and the Android side.

[1ec5]

A hard-coded timeout would be unfortunate. We don't have a completion block–based way to set the style; in the meantime, you can do this in -mapViewDidFinishLoading: or the forthcoming -mapView:didFinishLoadingStyle: (#6412) perhaps.

[incanus]

It splits functionality up fairly crappily, but I see your point.

[1ec5]

#6386 (comment) would mitigate this pain considerably, but it’s aways off.

[incanus]

Looked into this with a patch such as the following:

https://gist.github.com/1ab15bce31631f5ba032a731bd0bed38

However, it happens too quickly, essentially immediately after the style finishing tiling in, causing continual flashing between that happening and then the filter style changes. I want to eliminate the possibility that anything is done as part of the initial style fill, hence the delay so that the user can clearly see things in one state, then the other, to confirm that the filtered styling is applied without any external tile refreshing happening.

[1ec5]

OK, in that case, can you document the reasoning here? Now that we’re getting the style from a local resource, I’m not as concerned about the time it’ll take to load it, but someone using iosapp as a learning resource shouldn’t be misled into thinking this is how you use the runtime styling API normally.

[incanus]

89bfeaa88eec7840ecee64c15f22e34d7f6bcbdf

[1ec5]

This will only work with your access token, not the access token that the user enters. Instead, check in the style JSON as part of this project and refer to the bundled JSON file with a file URL or relative path.

[incanus]

63cdd45580602e9a7206dd6d39a76fd2a40887e4

[1ec5]

This can be expressed as a single predicate format string using the AND operator.

[incanus]

c3c9ca40aece3b08b9e63c2a13030e469452a845

[boundsj]

Thanks for doing this. While you are at it, I think it'd be great to add cases for the soon to land #6316 to exercise tile template URLs and also something to cover styling 3rd party vector (and raster) source layers. Support for the later was added in the fix for #6251. A single example can cover this (see #6316 (comment))

[incanus]

Got this pretty well set on the Android side too.

@boundsj On the ones you mention, is it more useful to visually test the functionality or to just confirm that something happens? i.e. I'm wondering how much we can push that to automated tests. The things I'm doing here are specifically things that won't ever throw or error, but might not look right if a bug crept in.

[incanus]

[boundsj]

@incanus might not look right if a bug crept in

I think that definition covers a lot of runtime styling cases including what I suggested. For example the MGLTileSet class that will be introduced in #6316 has its own set of options that affect how the map looks. Feel free to ignore my suggestion though if you don't see value in adding that case at this time.

[incanus]

Squashed and force pushed. This 🚢 will be ready to ⛵ once tests pass.

[incanus]

Ugh, fixing Android local style JSON also first.