Migrating from v3 to v4
The iOS SDK for MapsIndoors has received a major update to version 4.0.0, which comes with improved interfaces and flexibility for developing your own map experience. The MapsIndoors SDK now additionally supports Mapbox, alongside some reworked and refactored features that simplify development and SDK behavior. This guide will cover changes to the SDK and how to use it to provide you with a guide on how to upgrade from v3 to v4. If you have any questions concerning this document, or migrating to v4 in general, please contact MapsPeople technical support.
MapsIndoors SDK Map Engine Flavors
With the release of v4, the MapsIndoors SDK is released as multiple separate libraries depending on the Map Provider - Google Maps or Mapbox. You now import the SDK flavor of your choosing with either:
pod 'MapsIndoorsGoogleMaps', '~> 4.9'or
pod 'MapsIndoorsMapbox11', '~> 4.9'(Remember to check the changelog for the latest version)
MapsIndoors Initialization & Usage
MapsIndoors is a shared instance, which can be described as the data layer of the SDK. Below you will find an example that demonstrates how initialization has been simplified between v3 and v4.
Initialization
v3
In v3 you would start the SDK by providing a MapsIndoors API key and a Google API key, in order to start loading a solution.
MPMapsIndoors.provideAPIKey("YOUR_MAPSINDOORS_API_KEY", googleAPIKey: "YOUR_GOOGLE_API_KEY")In order to wait until MapsIndoors had finished loading the solution, you would call synchronizeContent with a completion.
MPMapsIndoors.synchronizeContent { error in
// The SDK has finished loading
}In v3 you had no real way to close the MapsIndoors SDK, releasing system resources when no map is shown.
MapsIndoors Data
In v3, you would access MapsIndoors data via data providers or services, e.g:
v4
In v4, we have improved the interface to initiate the SDK for smaller and safer implementations. In v4 you start loading a solution with a MapsIndoors API by:
Note that this is async/await and therefore requires an asynchronous context, and potentially throws an error if there were problems during loading MapsIndoors data. You can therefore be sure on the next line, that the SDK has either successfully loaded, or failed.
Additionally in v4, you can now close the SDK, releasing system resources when MapsIndoors is no longer actively needed for your application’s state.
The Google API key is no longer set on MapsIndoors - but rather on MPMapConfig when creating MPMapControl.
MapsIndoors Data
In v4, everything data should be accessed via MPMapsIndoors.shared instance
MapControl Initialization
MapControl instantiation and initialization are separate concepts. You create a new instance of MPMapControl and configure it with a map and view.
v3
To create a MPMapControl instance in v3, it was really straight forward.
v4
In v4, in order to support multiple map engines, we have changed how you create a MPMapControl instance. You now have to call a factory function on MapsIndoors, and provide an MPMapConfig.
An MPMapConfig is a configurable wrapper around either a Google Maps or Mapbox view. Depending on which flavor of the SDK you are using, either of the following approaches will derive a MPMapConfig, which you can use to create a MPMapControl:
Google:
Mapbox:
SolutionConfig & AppConfig
AppConfig and SolutionConfig can now be accessed with:
AppConfig is for applications specific information, you may want to store in MapsIndoors data for use in your application. AppConfig can be edited in the CMS. SolutionConfig is for adjusting SDK behavior and settings, e.g. enable or disable clustering of POIs. SolutionConfig can also be edited in the CMS.
Display Rules
Display rules have changed significantly between v3 and v4. The concept remains the same - each location has a rule, describing how it is rendered, and values are inherited from the location’s type’s display rule if not defined in the location’s own display rule.
The following code snippets show how to edit the display rule of a MapsIndoors location, and to undo the change.
v3
Editing a display rule
Resetting display rules
In order to modify a display rule, and later reset it (e.g. if you wanted to highlight the location temporarily), you would have to remember a copy of the display rule prior to modifying it. Then later, you can set the copied display rule onto the location.
Editing built-in SDK display rules
You could access the built-in display rules either directly on your MPMapControl instance, or by name.
v4
Editing a display rule
Resetting display rules
Resetting a display rule will return it to its initial values. Any values you can previously set, will be reverted back to CMS values.
Editing built-in SDK display rules
The SDK has some display rules dedicated for some SDK specific rendering, which cannot be edited in the CMS, e.g. building outline, selection highlight, blue dot. These rules are not bound to any unique location, so instead you can fetch them using MPDisplayRuleType enum.
E.g. change the building outline stroke color and width, optionally used to highlight the current building.
DirectionsService & DirectionsRenderer
The jump from v3 to v4 also introduces small differences in route directions querying and rendering.
v3
v4
App User Roles
App user roles as a feature remains the same, however the interface for getting available user roles and applying user roles has changed.
In v3 you would use a MPSolutionProvider instance to query a list of all available user roles for the loaded MapsIndoors solution. Applying user roles was done by assigning to the userRoles property on MapsIndoors.
v3
In v4 the interface has been moved to the shared MPMapsIndoors instance, where the list of available user roles for a given solution can be found. Applying user roles is similar to v3, just assign to the userRoles property on the shared instance of MPMapsIndoors.
v4
Map & Camera Behavior Configs
In v4, we have introduced MPFilterBehavior and MPSelectionBehavior. These object contains behavioral configuration to describe how and if the camera should behave. The following can be configured:
var moveCamera: Bool { get set }var showInfoWindow: Bool { get set }var allowFloorChange: Bool { get set }var animationDuration: Int { get set }
E.g. say you want to select a location, but not move the camera to the location:
The "Go-To" Function
v3
In v3, there was a convenience method to easily move the camera to a given MPLocation.
v4
In v4 the goTo(...) convenience method has been expanded upon, so it can be used with anything adhering to the MPEntity protocol, which includes MPLocation, MPBuilding, MPVenue, and even your own data types, as long as they adhere to MPEntity.
Map Filtering
You can filter content on the map - say you only wanted to show all meeting rooms on the map.
v3
In v3, you could set searchResults on your MPMapControl instance, to only show a list of locations.
v4
In v4, you can use an MPFilter directly to apply a filter on your MPMapControl instance.
You can also still simply use an array of MPLocation to set a filter on the map.
To clear the map filter, and return to normal displaying, call clearFilter()
Positioning Providers
The interfaces for using position providers with MapsIndoors, was bloated in v3, so you would have to implement a lot more behavior than was strictly necessary. In v4 we have trimmed down the interface, to ease integrations with positioning systems.
v3
In v3, the MPPositionProvider protocol required that you implemented your positioning integration in a particular way.
Even the simplest possible provider would look like:
v4
For v4, we have simplified the position provider protocol for MPPositionProvider and MPPositionProviderDelegate, which now looks like:
MPPositionResult has also been simplified.
Here is a small example of a mock implementation:
You attach it to the MapsIndoors SDK, by setting it on your MPMapControl instance (and enable showUserPosition)
Location Data Sources
Creating custom Location Sources.
v3
To create MPLocationUpdate instances, you would simply call the init:
Then inside viewDidLoad you register your custom sources:
v4
The concept for registering custom location sources is very similar to that of v3. In that you create your own custom Location Sources, however the way to create create MPLocationUpdate is slightly different.
And for registering the sources, after initializing the SDK, you call the register method:
Last updated
Was this helpful?