MSFMassifInterop

Adopts an object built with the object API, so it can be addressed by id and handle.

The TYPE picks what is being adopted, not the kind string - kind is only the id namespace, and the same Options is legitimately adopted as “map” by one app and “options” by another. One overload per adoptable base class, and that set is closed: SWIG emits one thunk per signature, and the SDK’s bases share no common root to declare a single parameter as.

Not named register: that is a C++ keyword, and a C one, so it is not a legal Objective-C selector piece either.

The same for a layer or a source built with the object API.

This is what lets an app adopt the facade a piece at a time: everything it already built keeps working, and gains an id, properties, methods and events. The CONCRETE class is recovered at runtime, so an adopted VectorTileLayer answers to a vector tile layer’s properties rather than only to Layer’s.

Registers the map’s layer list, so a layer built from a spec can be PUT on the map.

A spec builds an object, it does not place it - the same reason LocalVectorDataSource needs add(). This is the one for layers; call add/remove on the handle it returns.

The same for a vector data source, which is what an EXTENSION adopts.

Both data source bases are SWIG directors, so a source the SDK has no factory for - GDAL/OGR, a proprietary format, anything with its own native library - is subclassed in Java, Objective-C or TypeScript and adopted here. That is the whole extension mechanism: the SDK ships no dependency, and the source is a facade object like any other.

TileDataSource has had this since the facade landed; this is its vector counterpart.

The parameter is vectorSource, not source: Objective-C has no overloading and builds its selector from the parameter names, so two source overloads are one duplicate adopt:objectId:source:.

The same for an asset package, which is the one a binding cannot express as a spec.

An app that reads its styles from somewhere the SDK has no factory for - a NativeScript app folder, an app’s own decryption - subclasses AssetPackage in Java, Objective-C or TypeScript and adopts the instance here. Every spec that takes an assets key resolves a string as an id of this kind, so {"type":"cartocss","css":…,"assets":"shared"} then reaches it.

The map view, which is what carries the CAMERA.

Adopt it and moveTo, flyTo, fitBounds, screenToMap, mapToScreen and stopFlight become ordinary facade calls, with focusPos, zoom, rotation, tilt and flightActive as read-only properties beside them. Until that existed the typed sugar on each platform called the map view directly, so the camera was the one part of the surface a binding could not reach through the C ABI - see #159.

Returns a source built or adopted earlier, so it can be handed to the object API. This is the escape hatch: anything the facade cannot express yet is still reachable.

The same by HANDLE, for an object that was never given an id - a child read off a property, a call result. An app handing the base map’s tiles to its own native code has one of those and no id to name it by.

Returns a layer built earlier, so it can be added to a map with the object API. Layers are not attached by create - that needs the map verbs.

Builds the listener that turns a map’s callbacks into facade events on a target.

The app installs it with the map view’s own setMapEventListener, which is also why it takes the listener that was already there: a single slot means adopting the facade would otherwise disconnect the app’s existing handlers.

int handle = MassifInterop.adopt(“map”, “main”, mapView.getOptions()); mapView.setMapEventListener( MassifInterop.createEventBridge(handle, mapView.getMapEventListener()));

The same for a vector tile layer’s clicks, which is where a feature payload comes from. Install it with the layer’s setVectorTileEventListener.

The click is claimed if either the chained listener or a consuming subscriber claims it.

The same for a vector layer’s element clicks.

Undocumented