Generate a constants file by grabbing identifiers from storyboards in a project.
$ gem install sbconstants
For automated use:
- Add a file in Xcode to hold your constants e.g.
PASStoryboardConstants.(h|m)
- Add a build script to build phases e.g.
sbconstants path_to_constant_file
- Enjoy your identifiers being added as constants to your constants file
For manual use (using swift):
- Add a file in Xcode to hold your constants e.g.
StoryboardIdentifiers.swift
- Add a command to your Makefile to run something similar to
sbconstants path/to/StoryboardIdentifiers.swift --source-dir path/to/Storyboards --swift
$ sbconstants -h
Usage: DESTINATION_FILE [options]
-d, --dry-run Output to STDOUT
-p, --prefix=<prefix> Only match identifiers with <prefix>
-i, --ignore=<files_to_ignore> Comma separated list of files to ignore
-s, --source-dir=<source> Directory containing storyboards
-t, --templates-dir=<templates> Directory containing the templates to use for code formatting
-q, --queries=<queries> YAML file containing queries
-v, --verbose Verbose output
-w, --swift Output to a Swift File
An example usage would look like:
sbconstants MyApp/Constants/PASStoryboardConstants.h
NB The argument is the destination file to dump the constants into - this needs to be added manually
Every time sbconstants
is run it will parse the storyboard files and pull out any constants and then dump them into PASStoryboardConstants.(h|m)
. This of course means that PASStoryboardConstants.(h|m)
should not be edited by hand as it will just be clobbered any time we build.
The output of running this tool will look something like this:
PASStoryboardConstants.h
// Auto generated file - any changes will be lost
#import <Foundation/Foundation.h>
#pragma mark - segue.identifier
extern NSString * const PSBMasterToDetail;
extern NSString * const PSBMasterToSettings;
#pragma mark - storyboardNames
extern NSString * const Main;
#pragma mark - tableViewCell.reuseIdentifier
extern NSString * const PSBAwesomeCell;
PASStoryboardConstants.m
// Auto generated file - any changes will be lost
#import "PASStoryboardConstants.h"
#pragma mark - segue.identifier
NSString * const PSBMasterToDetail = @"PSBMasterToDetail";
NSString * const PSBMasterToSettings = @"PSBMasterToSettings";
#pragma mark - storyboardNames
NSString * const Main = @"Main";
#pragma mark - tableViewCell.reuseIdentifier
NSString * const PSBAwesomeCell = @"PSBAwesomeCell";
Using the --swift
flag this would produce
// Auto generated file from SBConstants - any changes may be lost
public enum SegueIdentifier : String {
case PSBMasterToDetail = "PSBMasterToDetail"
case PSBMasterToSettings = "PSBMasterToSettings"
}
public enum StoryboardNames : String {
case Main = "Main"
}
public enum TableViewCellreuseIdentifier : String {
case PSBAwesomeCell = "PSBAwesomeCell"
}
The constants are grouped by where they were found in the storyboard xml e.g. segue.identifier
. This can really help give you some context about where/what/when and why a constant exists.
##Options
Options are fun and there are a few to play with - most of these options are really only any good for debugging.
-p, --prefix=<prefix> Only match identifiers with <prefix>
Using the prefix
option you can specify that you only want to grab identifiers that start with a certain prefix, which is always nice.
-i, --ignore=<files_to_ignore> Comma separated list of files to ignore
Using the ignore
option, you can specify files which will not be added to the generated constants file. If you need to ignore several files, you need to separate it with commas (-i MainStoryboard,HelpStoryboard,CellXIB
).
-s, --source-dir=<source> Directory containing storyboards
If you don't want to run the tool from the root of your app for some reason you can specify the source directory to start searching for storyboard files. The search is recursive using a glob something like <source-dir>/**/*.storyboard
-d, --dry-run Output to STDOUT
If you just want to run the tool and not write the output to a file then this option will spit the result out to $stdout
-v, --verbose Verbose output
Perhaps you want a little more context about where your identifiers are being grabbed from for debugging purposes. Never fear just use the --verbose
switch and get output similar to:
sample output
#pragma mark - viewController.storyboardIdentifier
//
// info: MainStoryboard[line:43](viewController.storyboardIdentifier)
// context: <viewController restorationIdentifier="asd" storyboardIdentifier="FirstViewController" id="EPD-sv-vrF" sceneMemberID="viewController">
//
NSString * const FirstViewController = @"FirstViewController";
-q, --queries=<queries> YAML file containing queries
Chances are I've missed some identifiers to search for in the storyboard. You don't want to wait for the gem
to be updated or have to fork it and fix it. Using this option you can provide a YAML file that contains a description of what identifers to search for. The current one looks something like this (NB this is a great starting point for creating your own yaml):
queries
---
segue: identifier
view: restorationIdentifier
? - tableViewCell
- collectionViewCell
: - reuseIdentifier
? - navigationController
- viewController
- tableViewController
- collectionViewController
: - storyboardIdentifier
- restorationIdentifier
This looks a little funky but it's essentially groups of keys and values (both the key and the value can be an array). This actually gets expanded to the following table:
+--------------------------+-----------------------+
| node | attribute |
+ -------------------------+-----------------------+
| segue | identifier |
| view | restorationIdentifier |
| tableViewCell | reuseIdentifier |
| collectionViewCell | reuseIdentifier |
| navigationController | storyboardIdentifier |
| viewController | storyboardIdentifier |
| tableViewController | storyboardIdentifier |
| collectionViewController | storyboardIdentifier |
| viewController | restorationIdentifier |
| navigationController | restorationIdentifier |
| tableViewController | restorationIdentifier |
| collectionViewController | restorationIdentifier |
+--------------------------+-----------------------+
-w, --swift Output to a Swift File
Outputs Swift code rather than Objective-C
-t, --templates-dir=<templates> Directory containing the templates to use for code formatting
See below
If you are running tools that verify your team is sticking to coding conventions you might find that the default output might not fit your requirements. Not to fear you can provide your own templates to decide the formatting you require by passing the --templates-dir
option with the path to the directory containing the templates to use.
Inside your custom templates you can interpolate the constant_name
and constant_value
like this
NSString * const <%= constant_name %> = @"<%= constant_value %>";
You can override how the Objective-C constants are formatted by creating objc_header.erb
and objc_implementation.erb
files and adding the --templates-dir
flag pointing to their containing directory.
- Fork it
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Add some feature'
) - Push to the branch (
git push origin my-new-feature
) - Create new Pull Request