Runtime styling API for iOS/macOS #5727
Conversation
frederoni
added
iOS
|
@frederoni, thanks for your PR! By analyzing the annotation information on this pull request, we identified @1ec5, @friedbunny, @boundsj and @incanus to be potential reviewers |
frederoni
force-pushed
the
5626-runtime-styling
branch
from
b0843ca to
2ab2ab2
Compare
| - (void)testRuntimeStyling | ||
| { | ||
| MGLFillStyleLayer *waterLayer = (MGLFillStyleLayer *)[self.mapView.style layerWithIdentifier:@"water"]; | ||
| waterLayer.fillColor = [UIColor redColor]; |
There was a problem hiding this comment.
Would be nice to make this a toggle.
|
Is the convention that we’ll run /cc @jfirebaugh |
|
@friedbunny Android is generating style code for each build #5734-184. It's convenient but easier for bugs to slip through. Eventually, we could generate tests from the style spec and when we have that in place, I wouldn't mind to hook it up in a similar way. ios and macos style layers is currently generated by |
|
We should place generated files in their own directory. Instead of (or in addition to) a make rule for generating the source files, how about a target and scheme in the iOS and macOS workspaces? |
| return true; | ||
| case 'array': | ||
| return true; | ||
| case 'enum': // (enum will be converted to NSString hence isObject(enum) == true) |
There was a problem hiding this comment.
If we’re going with the strongly typed design proposed in #5626, each enumeration type in the style specification would ideally be mapped to a C enum (NS_ENUM) rather than NSString.
|
Most if not all of the paint properties are defined in the style specification as being “optional”. This presents a problem for our Cocoa translation, because the most natural types for the specification’s For We’ll also need to audit the headers for nullability and mark the optional properties as being nullable. |
| @interface MGL<%- camelize(type) %>StyleLayer : MGLStyleLayer | ||
|
|
||
| <% if (layoutProperties.length) { -%> | ||
| // Layout properties |
There was a problem hiding this comment.
Nit: Use #pragma mark Layout Properties so jazzy can create a new section for the symbols below.
There was a problem hiding this comment.
Better yet, “Accessing the Layout Attributes”, since we follow the Apple documentation convention of labeling each section in the documentation with a task. Since “property” has a more generic meaning in Objective-C and Swift, “attribute” is usually used to describe the kind of property that affects presentation etc. We use “attribute” in MGLFeature, for example.
| // This file is generated. | ||
| // Edit platform/darwin/scripts/generate-style-code.js, then run `make style-code-darwin`. | ||
|
|
||
| #import <Mapbox/Mapbox.h> |
There was a problem hiding this comment.
Importing Mapbox.h isn’t necessary and it breaks jazzy doc generation.
mapbox-gl-native/platform/darwin/src/MGLLineStyleLayer.h:4:9: fatal error: 'Mapbox/Mapbox.h' file not found
|
|
| @@ -0,0 +1,10 @@ | |||
| #import <Mapbox/Mapbox.h> | |||
There was a problem hiding this comment.
This header should import MGLSource.h, not Mapbox.h.
There was a problem hiding this comment.
Looks like removing Mapbox.h also requires either UIKit or CoreGraphics to be added. Because this is in /darwin, we can’t rely on UIKit being available here.
#import "MGLSource.h"
#import <CoreGraphics/CoreGraphics.h>
frederoni
force-pushed
the
5626-runtime-styling
branch
from
874cc14 to
4a9157c
Compare
WIP #5626
Runtime styling for iOS and macOS is taking shape. Here's an overview if what's done, what's left to do and what's TBD.