|For attaching actions to objects. |
|For manipulating UIButton objects. |
|For common system metrics. |
|For classic computer science data structures. |
|For inspecting code and writing to logs in debug builds. |
|For dealing with device orientations. |
|For defining various error types used throughout the Nimbus framework. |
|For filling in gaps in Apple's Foundation framework. |
|For manipulating UIImage objects. |
|For storing and accessing objects in memory. |
|For showing network activity in the device's status bar. |
|Non-Empty Collection Testing|
|For testing whether a collection is of a certain type and is non-empty. |
|For collections that don't retain their objects. |
|For writing code that runs concurrently. |
|For creating standard system paths. |
|Preprocessor macros are added to Nimbus with care. |
|Runtime Class Modifications|
|For modifying class implementations at runtime. |
|For checking SDK feature availibility. |
|An object designed to easily implement snapshot rotation. |
|For modifying Nimbus state information. |
|For recycling views in scroll views. |
|The NINavigationAppearance provides support for saving and restoring the navigation appearance state. More...|
Nimbus' Core defines the foundation upon which all other Nimbus features are built. Within the core you will find common elements used to build iOS applications including in-memory caches, path manipulation, and SDK availability. These features form the foundation upon which all other Nimbus libraries are built.
As a general rule of thumb, if something is used between multiple independent libraries or applications with little variation, it likely qualifies to be added to the Core.
Standalone user interface components are rarely acceptable features to add to the Core. For example: photo viewers, pull to refresh, launchers, attributed labels.
Nimbus is not UIKit: we don't have the privilege of being an assumed cost on every iOS device. Developers must carefully weigh whether it is worth adding a Nimbus feature - along with its dependencies - over building the feature themselves or using another library. This means that an incredible amount of care must be placed into deciding what gets added to the Core.
It is inevitable that certain aspects of the Core will grow and develop over time. If a feature gets to the point where the value of being a separate library is greater than the overhead of managing such a library, then the feature should be considered for removal from the Core.
Great care must be taken to ensure that Nimbus doesn't become a framework composed of hundreds of miniscule libraries.
Nimbus provides the following macros: UIViewAutoresizingFlexibleMargins, UIViewAutoresizingFlexibleDimensions, UIViewAutoresizingNavigationBar, and UIViewAutoresizingToolbarBar.
Using the existing UIViewAutoresizing flags can be tedious for common flags.
For example, to make a view have flexible margins you would need to write four flags: