Since version 2.0 of the Aeris iOS Weather SDK was completely rewritten from the ground up, there are several architectural changes that you should be aware of when upgrading from 1.0. This guide will help you when migrating from a pre-2.0 version of the SDK within your own projects.
The Aeris iOS Weather SDK officially supports iOS 6+ and Xcode 5. If your project requires support an iOS version earlier than 6.0, then you will not be able to use 2.0.
The SDK has been updated to use modern Objective-C, including ARC (Automatic Reference Counting).
AF namespace prefix used in 1.0 has been changed to
AWF for Aeris Weather Framework. This change also eliminates conflicts with the SDK’s dependency on AFNetworking, which also uses the prefix
In 1.0, you handled request responses from object loaders through the use of delegates, which separated your request code from your response handling code. This method also meant that a single delegate event handler had to handle responses from multiple object loaders when using more than one loader in a single controller. In 2.0, you now handle responses from object loaders by providing a block handler to the request. This block handler will receive an array of objects returned from the request and any error that occurred. Review the object loader usage documentation for more details.
Options you needed to pass to a request were done using a regular NSDictionary object in 1.0, which was usually difficult to work with. Therefore, in 2.0 we have introduced
AWFRequestOptions, an object that manages all of the various request options for a request that is more efficient and easier to work with than an NSDictionary. Review the AWFRequestOptions API documentation for more details.
The default stylesheet used for the built-in weather views has been changed to a lighter style to better align with the overall aesthetic introduced in iOS 7. If your project required the older dark style from 1.0, you can easily revert back to this style by setting the default global style to the
AWFLegacyStyle style that’s included in 2.0. Refer to Setting a Default Style section of the Weather Views usage documentation for more details on setting a global default style in your projects.
Version 2.0 of the SDK now supports using the built-in weather views in your Storyboard and XIB files, allowing you to take advantage of these views if you prefer to work with Interface Builder within Xcode.
In 1.0, the enumerated types used when referencing the different types of overlays supported on the map was
AFOverlayType, which suggested they were all map overlay objects. Therefore, in 2.0 we have changed this enumerated type to
AWFLayerType to better represent the various types instead of actual overlay objects. Refer to the Map Data Layers usage documentation for more details.
To better support greater flexibility in the customization of map data layers and objects, we have updated all point data (annotations), polygons and legends to use a stylesheet-like approach to styling their map representations instead of static images that were used in 1.0. These map objects are rendered dynamically on the map using their assigned style and cached as needed to improve performance. Refer to the Styling Map Objects usage documentation for more details.
Overlay animations in 1.0 were interval-based, meaning you specified how many time intervals you wanted to display for an animation. In 2.0, animation has been vastly improved by switching to a time-based animation. Using a time-based animation allows you to animate multiple data layers on the map at once and having them all synced up to the timeline. So instead of specifying the total number of intervals you want in an animation, you defined the starting and ending dates as well as the maximum number of intervals you want to use within that range to animate. Refer to the Map Timeline usage documentation for more details.
The plist file method for configuring your weather map has been replaced by the
AWFWeatherMapConfig object within the SDK. This new method allows your application to have multiple instances of a weather map, each with its own configuration. You must provide a configuration object when initializing a new
AWFWeatherMap instance. Refer to the Configuring a Weather Map section of the Weather Maps usage documentation.
Nearly all of the public properties and methods for managing and interacting with a weather map instance has been changed in 2.0, such as adding and removing data layers and accessing various views being managed by the weather map. Refer to the AWFWeatherMap API documentation for more details on the new methods and properties.
Many of the event methods for
AWFWeatherMapDelegate have been changed in 2.0, meaning your project will also need to implement these changes when migrating from 1.0. Refer to the AWFWeatherMapDelegate API Documentation for more details.