The Nimbus launcher currently lacks the ability to edit the ordering of the launcher items. This is a pretty integral feature of Three20's launcher and differentiates it from other launcher libraries out there. It's pretty important that this be ported over.

That being said, it wasn't absolutely critical for 0.2 to get editing support working, which is why it was deferred as a bonus goal for a future version.

Nimbus Navigation Design Document

Version 1.0 - Last updated September 1st, 2011 at 10:29PM EST.

The goal with Nimbus navigation is to provide a powerful navigation feature that complements UIKit's existing navigation functionality. This includes iOS 5's Storyboards as well as pre-iOS 5 standard UINavigationController and modal controller presentation.

Design Considerations

This feature will complement the existing UIKit functionality by providing a thin, optional layer on top of UIKit. The goal is to allow a developer to use the navigator when they want to, and to use their own navigation logic when they don't. This means that we do not want deep integration with UIKit components. For example, we won't provide any UIViewController subclasses that implement navigation functionality like Three20 does. A developer should be completely able to slowly integrate the navigator into an existing project if they so desire. Imagine defining a single route and using it within an app that is otherwise completely custom navigation.

The Routing Interfaces

Nimbus Navigation will model directly off of Three20's navigation system by using URLs to map to view controllers and mapping objects to URLs. The routing functionality itself will be implemented using SOCKit.

The routing interface will look roughly like the following:

/**
 * A routing map maintains a mapping of routes from paths to view controllers and objects to paths.
 *
 * All routes are processed using SOCKit to gather parameter information from the paths. Each
 * navigator object (TODO: Name of the object here) instance has an instance of a NIRoutingMap.
 */
@interface NIRoutingMap : NSObject

#pragma mark Controller Routing

/**
 * Add a route from the given path to the given view controller.
 *
 * ## What happens when the navigator opens a path mapped with this method:
 *
 * A view controller will be created and initialized with the initWithNibName:bundle: method.
 * If willNavigateWithPatternParameters:queryParameters: is implemented on the controller then
 * it will be called.
 *
 * Any parameters matched in the path pattern will be passed to
 * willNavigateWithPatternParameters:queryParameters: on the view controller.
 *
 * If you require more explicit access to parameters then you may wish to consider using
 * fromPath:toViewController:withWillNavigateSelector: instead. Using an explicit selector is a
 * recommended means of using the compiler to enforce parameter types and type safety.
 *
 *      @param path  A path that may specify certain parameters that will be matched and sent to
 *                   willNavigateWithPatternParameters:queryParameters:. See the routing parameters
 *                   section of the navigation documentation (TODO: Add link here).
 *      @param viewController  The view controller that will be instantiated and presented when the
 *                             path is opened in the navigator.
 */
- (void)fromPath:(NSString *)path toViewController:(Class)viewController;

/**
 * Add a route from the given path to the given view controller.
 *
 * ## What happens when the navigator opens a path mapped with this method:
 *
 * A view controller will be created and initialized with the initWithNibName:bundle: method.
 * If willNavigateWithPatternParameters:queryParameters: is implemented on the controller then
 * it will be called. The willNavigateSelector will then be called.
 *
 * Any parameters matched in the path pattern will be passed to
 * willNavigateWithPatternParameters:queryParameters: on the view controller.
 *
 *      @param path  A path that may specify certain parameters that will be matched and sent to
 *                   willNavigateWithPatternParameters:queryParameters:. See the routing parameters
 *                   section of the navigation documentation (TODO: Add link here).
 *      @param viewController  The view controller that will be instantiated and presented when the
 *                             path is opened in the navigator.
 *      @param willNavigateSelector  A selector that should have at least as many arguments as
 *                                   there are parameters in the path pattern. One additional
 *                                   argument may provided which accepts an NSDictionary of
 *                                   NSArrays of query parameter values.
 */
- (void)fromPath:(NSString *)path toViewController:(Class)viewController withWillNavigateSelector:(SEL)willNavigateSelector;

/**
 * Returns a newly allocated controller that has been prepared for navigation using the
 * NIRoutingDestination protocol and willNavigateSelector, if such a selector was provided, with
 * the given path to provide the parameters.
 *
 *      @param path  A path that is used to 1. determine which controller class to instantiate and
 *                   2. provide the parameters to the NIRoutingDestination protocol and
 *                   willNavigateSelector, if such a selector is provided.
 *      @returns A newly allocated controller that has been prepared for navigation using the
 *               NIRoutingDestination protocol and willNavigateSelector, if such a selector
 *               was provided, with the given path to provide the parameters.
 */
- (id)controllerForPath:(NSString *)path;

#pragma mark Object Routing

/**
 * Add a route from an object class to a pattern string.
 *
 * This route is used by pathForObject: to generate a path for consumption by the navigator.
 *
 *      @param objectClass  The class of object that can be used to generate the given pattern
 *                          string.
 *      @param patternString  A pattern string that contains parameters that match property names
 *                            on the given object.
 */
- (void)fromObjectClass:(Class)objectClass toPatternString:(NSString *)patternString;

/**
 * Returns a path generated using the object's properties if a route exists for the given object's
 * class, nil otherwise.
 *
 *      @param object  The object whose values will be used by the pattern to generate the path.
 *      @returns A path generated using the object's properties if a route exists for the
 *               given object's class, nil otherwise.
 */
- (NSString *)pathForObject:(id)object;

@end

/**
 * A set of methods that can optionally be implemented by a routing destination.
 */
@protocol NIRoutingDestination <NSObject>

@optional

/**
 * Called immediately after the view controller is initialized by the navigator and before it
 * is presented.
 *
 * If a selector is provided with the routing map then this method will be called first and the
 * routing map's selector second.
 *
 * The parameters for this method are dictionaries of arrays of values. Even parameters that
 * only exist once in the pattern or query will be arrays of values. This is so that if any
 * parameter names are duplicated we provide a consistent means of accessing these values. The
 * parameter values will stored in the array in the order that they were defined in the path.
 *
 * jverkoey implementation note: Do not prepare these parameter dictionaries unless we need to.
 *      If it turns out that this is the only method that will use such a representation of
 *      parameters then we should only create them if the destination implements this method.
 *
 * jverkoey design consideration: Three20's url mapping technology forced you to define the
 *      selector for a mapped url in the url path and encouraged the use of initializers to
 *      initialize the view controller. For example, one might define a path in Three20 like so:
 *          @"fb://profile/(initWithUserId:)" => [FBProfileController class].
 *      Nimbus will not be going this route. Instead, Nimbus will encourage the use of auxiliary
 *      methods to receive the path parameters. This will allow devs to use standard controller
 *      initializers. This will have the net effect of not making it feel like Nimbus is taking
 *      over your app, instead allowing devs to graciously add functionality to existing
 *      controllers as they see fit.
 *      In Nimbus the Three20 example used above would look more like this:
 *          @"fb://profile/:userid" => [FBProfileController class] @selector(setUserId:)
 *      A multi-parameter url could look like this:
 *          @"fb://profile/:userid/:initialTab" => [FBProfileController class]
 *                                                 @selector(setUserId:initialTab:)
 *
 *      @param patternParameters  { "pattern parameter name" => NSArray of parameter values }
 *      @param queryParameters    { "query parameter name" => NSArray of query values }
 */
- (void)willNavigateWithPatternParameters:(NSDictionary *)patternParameters queryParameters:(NSDictionary *)queryParameters;

@end

I want a better way to build views by code. Now is necessary do math for the subViews, and I hate more recalculate it for the orientation changes. Using IB is not enough, still work bad in orientation changes for something barely complex.

A Layout control will help a lot in build dynamic views, and abstract the differences between iPad/iPhone.

Something like:

- (void)loadView
{
    UIView *section = [self.view addSection:RESIZE_ALL columns:2];

    [section addTopLeft:subView1 inColumn:1];
    [section addTopRigth:subView2 inColumn:2];
}

Or something better.

NIImageView just don't load links that are redirected. For example: http:/api.tumblr.com/v2/blog/larcus.tumblr.com/avatar. Using UIImage works.

You will see that the -(void)shutdown is never called. It will probably call the -(void)shutdown in the subclass. So just change the name of the method to something else, and it will work fine.

Three20's debugging tools need to be migrated.

Important files:

TTDebug

Core Data is a very powerful system. But his operation is too verbose and offers too much boilerplate to perform basic operatons as Query Data and Delete or Create new data objects.

A DB Manager is one possible solution to abstract this operations and preserve the Core Data power. I do have a this Component developed and tested under JUMP Common Library, and I think that is a great addition to Nimbus.

Found more info here:
http://seqoy.github.com/jump/Docs/JUMPDatabase/html/index.html

Let me known what you guys think.

Hi,

I got undefined symbol _NIDASSERT, when compiling after adding Core + Launcher to my project. I solved it with including those two headers not in my .m file, but in the -prefix.pch file.

Could you please update the Quickstart guide.

Thanks.

If we want to take advantage of NINetworkImageView in place of a UIImageView in a UITableViewCell, right now there do not seem to be any options.
Is it possible to return a UIImage object from the NINetworkImageView ?

The only action we currently support in the web controller is "Open in Safari". It would be awesome to also provide the ability to copy the current page's URL to the clipboard.

This feature will:

• Show the current web page's URL in the action sheet's title.
• Add a new "Copy" option in the action menu.
• Tapping this copy option will copy the current web page's URL to the clipboard.
• The user should then be able to leave the app and paste the URL in any other app that supports pasting.

Relevant Documentation:

http://developer.apple.com/library/ios/#documentation/uikit/reference/UIPasteboard_Class/Reference.html

Three20's message controller is fairly useful, even in the presence of the native mail interface because it allows you to customize every aspect of the controller.

Some points of note in transitioning this controller:

• We are no longer going to have any base view controller bullshit going on like Three20 has. TTMessageController should inherit from UIViewController, plain and simple.
• The controller is already fairly well documented, but the docs need to be updated with the new doxygen style in order for the docs to be consistent with the rest of Nimbus. This means adding a brief sentence describing each method and property, grouping similar methods, and writing concise, explanatory documentation about when to use the controller and how it should be used.
• I'm not entirely convinced that all of the controller's public methods need to be public, so some auditing here would be helpful.
• The TTMessageField objects are scantily documented. I'm not even entirely sure how these objects work together myself. It would be great to document how each of these fields are used together and how to build custom fields. That being said, it's possible that there is a simpler solution for this as well.

How difficult will this be?

This should be a fairly straightforward port from Three20. Most of the work will be in cleaning up the documentation and providing examples and sample applications.

There are some significant design problems with Three20's launcher that will need to be addressed.

Namely:

• All of the launcher data is contained within the launcher view. If a memory warning is received we should release all views on each non-visible view controller but because all of the launcher view's data is contained within the view itself, releasing the view would cause us to lose state. A better implementation would use a data source to fetch the data on demand from the controller.
• The interface is fairly confusing right now. Some thought needs to be put into developing an intuitive interface and only exposing members that need to be exposed.

A general-purpose grid view controller can be used to present information in grid form. A good example of such a controller would be a photo album thumbnail viewer that shows a grid of photos that can be tapped to view the larger photo.

Some thought should be given as to whether a grid view controller should be an implementation of a table view controller or a completely new implementation. There are benefits to implementing a table view controller such as: section headers, the index scrubber, and a well-tested implementation. The benefit of writing a new grid view controller is mostly in simplicity, as there are some features of a table view controller which don't apply very well to a grid view controller (accessory indicators, editing).

I wondered if you've considered the potential for Nimbus integration with RestKit? I know @blakewatters and the folks at TwoToasters have put a great deal of Three20-powered magic into the RestKit project, and I thought that since Nimbus is in the redesign/reimplementation phase, it might behoove both projects to at least explore some options of early integration. From the looks of it, you're both putting a high priority on documentation and testing, too.

So I'm here just planting some seeds. Any thoughts on this?

Nimbus uses a custom build of Doxygen to generate the docs in the Appledocs-esque style. You can find the modified source here:

https://github.com/nimbusios/Doxygen

Making it possible for new people to build the documentation currently involves downloading the original Doxygen package, cloning the Nimbus Doxygen directory, building the source, and then copying the binaries over the original Doxygen binaries.

Ideally we'd simply provide a pre-packaged .dmg of the Nimbus Doxygen build.

Three20's new network image object is pretty sweet and it would be great if it could be migrated to Nimbus fairly quickly. This will give Nimbus two solid features for people to play with while I work on migrating the navigator to Nimbus.

There is a current bug in Nimbus Doxygen: when adding one line documentation to a method it does not render in the output HTML hoever as soon as you add two lines it does, for example:

This does not work:

/**
* This documentation text will not show up, it will only show the method.
*/
-(void)someMethod:(NSString*)str docs:(NSString*)docStr;

However this does work:

/**
* This documentation text will show up,
* because it is over two lines.
*/
-(void)someMethod:(NSString*)str docs:(NSString*)docStr;

Oddly, this only seems to effect methods, and properties seem fine.

A live example:

http://jverkoey.github.com/nimbus/protocol_n_i_launcher_data_source-p.html

Notice that -(CGSize)buttonDimensionsInLauncherView: (NILauncherView*) launcherView is the only method that has documentation.

iOS 3.2 introduced the powerful NSAttributedString object but Apple has yet to provide an
easy means of using these strings in UILabels. An NIAttributedLabel would allow us to build
labels using all of the stylistic properties that came with TTStyledTextView and none of the
overhead that was associated with it and TTStyle.

NIAttributedLabel

An attributed label should support links. These links should be tappable and have a highlight
state. Tapping a link should notify a delegate.

NSMutableAttributedString+NimbusLabels

Proposed below are some potential additions that could be made to the NSMutableAttributedString
implementation.

@interface NSMutableAttributedString (NimbusLabels)

/**
 * Returns a mutable autoreleased attributed string with the label's font and colors applied.
 */
+ (NSMutableAttributedString *)mutableAttributedStringFromLabel:(UILabel *)label;

/**
 * Returns a mutable autoreleased attributed string with the markdown styles applied.
 *
 * Should support:
 * - Headers
 * - Bold/italic
 * - Links
 */
+ (NSMutableAttributedString *)mutableAttributedStringFromMarkdownString:(NSString *)markdown;

@end

Just downloaded the new Facebook for iPhone (v4.0) app, and quite like the new(?) slide out/under feature they use for the main menu. I was thinking this would be cool to have in Nimbus, to give more choices (not just launcher). Also, not sure if this is covered by default in iOS (haven't looked much into it) but I also really like the 'floating balloon' popouts you get when you click on the Like/Comment button in the feed. This would be really cool for adding extra features to a button (while saving screen space), but also, if designed correctly, could probably be used to emulate the iPad style menus on iPhone?

Just kind of braindumping here, not sure what is/isn't possible/already exists so let me know if i'm talking nonsense :)

Notes

The two features this issue relates to are:

• Covers - The slide out/under trays used in Facebook v4.0 app
• Flyouts - The 'balloon' notifications.
  • This should be implemented as closely to UIPopoverController as possible
  • Possibly allow it to call UIPopoverController if running on an iPad?
  • Name ideas: NIPopoverController, NIFlyoutController, etc?

References

• UIPopoverController - http://developer.apple.com/library/IOS/#documentation/UIKit/Reference/UIPopoverController_class/Reference/Reference.html

Other Implementations

• https://github.com/werner77/WEPopover
• https://github.com/KJoyner/SeaGlass

http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/

There is merit in building a feature dedicated to custom cell views using the flattening method described in Loren's excellent post on the subject of table view optimizations.

One common trouble area with this approach is how to handle interacting with specific parts of a cell. For example, if the user taps a link in the cell we should probably act on that link. On the touch down state we should show a highlight around the link, but if we're not using subviews then it is non-trivial to know 1. that the user tapped the link and 2. where/how to draw the highlight (especially when the cell is a composited image).

There are some obvious solutions to is problem (re-rendering the cell with a highlight applied, for example), but each implementation is likely more than a simple task. If we could provide a general purpose feature for this functionality we could improve the performance of many apps.

Hi, guys!

Got this error in my new project (ARC is on, of course):
"ARC forbids Objective-C objects in structs or unions in ...bla-bla.../Nimbus/src/core/src/NIDataStructures.h"

Prob., I'll have to remove this and all related classes as a quick fix and continue development until this issue will be resolved.
Is there another good solution to fix that?

Thx in advance!

I ran the demo on a simulator and rotated it while a photo was on screen - full screen. the photo was not centered after the rotation.

I'd like to be able to use a localized string to set the title of my table view sections. If I add an NSLocalizedString to my array of objects for the NITableViewModel, it ends up trying to create a cell for that element instead of setting it as a section title.

This should be a fairly straightforward port.

Bonus goal:

• Add support for the iPad as well. There is likely a need for multiple types of web controllers on the iPad, including: Safari-style with a top navigation bar and buttons; simple style with no toolbars at all for full-screen browsing; Twitter style with a toolbar at the bottom and buttons.

Allow the launcher to show a page that shows explanatory image and text.

It can often be helpful to display a coloured badge view showing unread counts. Such a view could be created in Three20 with TTLabel, but this required pulling in the entire TTStyle framework in order to do so. A better badge view implementation would simply be a UIView with a label and customizable tint colour. Every effort should be taken to ensure that this badge view is a pixel-perfect match of the system badge icon.

The implementation of this badge view will likely either heavily use layer styles or a stretchable image. A stretchable image would perform much better than using layer styles, while layer styles would allow for easier customization.

iOS5's release is just around the corner and along with it will be XCode 4.2. Default projects in XCode 4.2 have ARC enabled, therefore all Nimbus code will cause errors.

We need to have a think on how we are going to support ARC for new projects, and still maintain compatibility with previous projects.

Disabling ARC is an option, however I'm sure many (especially new) developers will want ARC on.

Does anybody have any thoughts on this?

This control should behave identically to the Messages app. As you enter text the height of the label should increase in order to accommodate the text.

Configurable settings:

• Send on enter or send button embedded in the control
• Max height

This control would likely be called NIAutoResizingTextView.

The photo view controller for the iPhone should be a specific feature of Nimbus. This does not include support for the iPad. iPad support should probably be a separate library due to the relatively complex nature of the photos experience on the iPad.

Included in this library would be:

• NIPhotoViewController
• NIAlbumViewController

I don't think that ThumbsViewController is a particularly accurate name for what it does, but these names are by no means set in stone.

The photos experience requires the following protocols:

• Album data source for fetching information about an album. Care should be taken to allow the data source to be loaded asynchronously. The library should support paging of albums.
• Photo protocol defining the basic aspects of a photo including: fetching the image for various photo dimensions.

I don't know whether it makes sense to have this library depend on network images or not. It would be nice if the data sources could simply request the image and if it wasn't ready show a loading indicator. This would allow anyone using the photo library to implement their own asynchronous loader (perhaps use their existing loader, for example).

User experience features:

• Photo captions
• Portrait and landscape orientations
• Swiping to change photos.
• Viewing the album from a particular photo.

How difficult will this be?

This has the potential to be a very challenging task. It's likely best to consider doing a complete rewrite of the photo feature from Three20. Much of Three20's functionality can be carried over though, so that should help in certain places. Care must be taken.

Hi, colleagues! )

I'm just wondering why don't you wrap Nimbus in a static frameworks?

I've tried this solution and it is perfect! You can handle dependencies, it is much easier to add framework to the project instead of static lib with all paths and other boring things. Also, there is no necessity to set "-fno-objc-arc" flag to a bunch of Nimbus *.m files! As for me - it would be perfect if nimbus will become a set of frameworks!

There is a quick links (if you're interested):

XCode 4 framework projects templates (I'm using real static framework, it is perfect as for me!): https://github.com/kstenerud/iOS-Universal-Framework

Articles, etc.:
http://db-in.com/blog/2011/07/universal-framework-iphone-ios-2-0/
http://stackoverflow.com/questions/6245761/difference-between-framework-and-static-library-in-xcode4-and-how-to-call-them

Cheers!

P.S. I love Three20 project and use it widely in projects. Also, I'm happy that you're starting Nimbus! So, good luck, guys!
(and sorry for my English ;) )

I'd like to iron out a release schedule for Nimbus that involves weekly releases of some sort.

The reality of an aggressive schedule like this is that some weeks will be less interesting than others. I think the benefits of ensuring that bugs don't get caught up in longer feature releases is worth it though.

I propose that every Tuesday we cut a new release containing as many bug fixes and finished features as possible.

More thoughts to come. Let's use this issue to track this discussion further.

UIButton should not be subclassed due to the fact that buttonWithType: is a factory method and may not respect subclassing correctly...

TODO: verify that this is true

Nimbus' documentation would be complimented rather nicely by a set of screencasts that dive into a variety of topics.

• How to add Nimbus to a project
• How to make a pull request for Nimbus on Github
• How to run the Nimbus unit tests
• 30 second (or less) clips of the example applications
• Any of the Nimbus features
• A video showing how much code you can destroy by using Nimbus Models

And any other idea you have! If you put together a screencast make sure to link to it here. We may set up an official youtube channel after a certain point.

I was getting a compilation error when I included the core and webcontroller. After looking at the code I believe there is a typo in NIWebController.m when it comes to including the header file.

Instead of including NIWebController.h it should be NimbusWebController.h. When locally I did this the error went away.

Regards
Kapil

As I'm writing CoreKit, I'm thinking about how to make app development easier and easier with as few lines of code as possible.

One thought I've had is configuring datasources to automatically figure out what type of table cell it needs to display for a value, then handling the changes automatically.

For example, in CoreKit, I've started writing CoreData bindings to UI Controls and blocks. When a value changes in the model or UI, it will auto update its corresponding binding.

What I'd like to see is the ability to have Nimbus say, "active is a boolean, i need to display a switch cell for this".

This may be a limited use case, or outside of what Nimbus' goal is... But wanted to see what everyone else thought about it.

If I specify the same url for photo (photoAlbumScrollView) and thumb (photoScrubberView), is Nimbus smart enough to not fetch it 2 times?

I'm building upon the photos example project.

Three20 has a lot of additions in the core that need to be migrated. It's probably best to place these all in a NimbusCore+Additions header file separate from the NimbusCore.h so that additions aren't forcefully injected into the developer's namespace.

Important files:

Everything in Three20Core's Additions folder

I am currently building an application using Three20 solely for the use of TTPickerTextField. I would love for this to be migrated to Nimbus sooner rather than later. I'm not well-versed enough to do it myself, but would be very grateful to whoever does. Thanks!

Nimbus is awesome, love what you guys are doing!

I tried building upon the photos example project yesterday, and within half an hour, without having touched Objective-C before, I had a working prototype.

What I'm missing is a way to specify a photo text and have it appear right above the NIPhotoScrubberView as an overlay. A lot of times when you want to show photos, you want to have some text with it that describe the photo or some other info.

I have made a quick mockup of what I would like:

Three20's CSS feature has the potential to be an incredibly powerful feature, making it possible to theme and style native applications using CSS. Three20's implementation is tightly bound to the TTStyle framework and this adds far more weight to the framework than is necessary.

Nimbus Stylesheets

A clean Nimbus implementation would port the CSS grammar and parser that were built for Three20 and make it incredibly easy to import css files and then apply them to standard views.

The interface I'm imaging would look something like this:

// Loads a stylesheet from disk and parses it. This would probably be done at
// app initialization. Because this is necessary for styling views, these style sheets
// should always be immediately available.
// If processing the stylesheet takes a lot of time, it may be worth breaking the
// stylesheets up into separate files and loading them on-demand.
NIStylesheet* stylesheet = [NIStyleSheet stylesheetFromFilePath:<path to css file>];

// This method would apply styles to the given view and all of its subviews.
// This is useful if you want to quickly style a controller's view hierarchy on
// viewDidLoad. This method should be *fast*.
[stylesheet applyRecursivelyTo:self.view];

One method of styling could be to use class names to apply styles to a type of view. For example:

/* All toolbar instances would have this style applied */
UIToolbar {
  tint-color: #000099; /* tint the toolbar red */
  translucent: true;
}

/* All network image views will have a white border */
NINetworkImageView {
  border-color: rgba(255, 255, 255, 0.5); /* semi-transparent white border */
  border-width: 1px;
}

Styling Specific View Instances

It's important to be able to target specific views and style them accordingly. Below are just two ways one could explore the implementation for this.

Four-letter IDs

We could also get fancy with ids in a couple of ways. One could use the tag property on all views to define a unique id using the four character id method. For example:

In code:

photoView.tag = 'ppic'; // This photo view is a profile picture.

In CSS:

#ppic {
  background-color: blue;
}

Pros:

• Easy to use (effectively automatic with the applyRecursivelyTo: method)
• Interface builder integration (you can set tags for views very easily)

Cons:

• Restricted to four letter domain for ids.
• Requires use of the tag property.

Manual Style Application

We could provide a method that allows us to pick a style and apply it directly to any view. An example use of this method would probably look something like this:

[stylesheet applyStyleToView:photoView withID:@"photoView"];

Pros:

• Allows full-length names for style IDs.

Cons:

• Requires manual application of style to every view.

Pseudo-Comprehensive List of Nimbus CSS Properties

color => [#xxxxxx|#xx|rgba(xx, xx, xx, xx.xx)|rgb(xx, xx, xx)|color-name]
dimension => [xx(px)]
font-size => [xx(pt)]
box-dimensions => [<dimension>|<dimension> <dimension>|<dimension> <dimension> <dimension> <dimension>]

UIView {
  border-color: <color>       {view.layer.borderColor}
  border-width: <dimension>   {view.layer.borderWidth}
  background-color: <color>   {view.backgroundColor}
  border-radius: <dimension>  {view.layer.cornerRadius}
  opacity: xx.xx              {view.layer.opacity}
}

UILabel {
  color: <color>                  {label.textColor}
  font: <font-size> <font-name>   {label.font}
  font-weight: [bold|normal]      {label.font}
  text-shadow: <color> <x-offset> <y-offset> {label.shadowColor label.shadowOffset}
  text-align: [left|right|center] {label.textAlignment}
  line-break-mode: [wrap|character-wrap|clip|head-truncate|tail-truncate|middle-truncate] [label.lineBreakMode]
  number-of-lines: xx             {label.numberOfLines}
  minimum-font-size: <font-size>  {label.minimumFontSize}
  adjusts-font-size: [true|false] {label.adjustsFontSizeToFitWidth}
  baseline-adjustment: [align-baselines|align-centers|none] {label.baselineAdjustment}
}

UILabel:highlighted {
  color: <color> label.highlightedTextColor;
}

UIButton {
  padding: <box-dimensions>; {button.contentEdgeInsets, button.titleEdgeInsets, button.imageEdgeInsets}
  color: <color>        {[button titleColorForState:]}
  text-shadow: <color>  {[button titleShadowColorForState:]}
}

UIButton:[highlighted|disabled|selected] {
  color: <color>        {[button titleColorForState:]}
  text-shadow: <color>  {[button titleShadowColorForState:]}
}

UITableView {
  separator-style: [none|single-line|single-line-etched] {tableView.separatorStyle}
  separator-color: <color> {tableView.separatorColor}
}

Just a very small issue but I think in nimbus/src/attributedlabel there should be a "deps" text file containing this:

core

[Frameworks]
CoreText.framework

Looking through the network image sources, I'm trying to figure out if there's already a mechanism to handle retina image scales. I got excited when I saw the scale parameters, but it looks like it's for something else, related to aspect ratios.

Is there anything special that needs to happen in order to load retina images vs. standard images when available (and the device is retina capable)?

The availability tools need to be migrated from Three20. This feature is fairly new so some thought may need to be invested in determining whether any changes need to be made.

Important files:

TTAvailability

So I was playing around with Facebook profile images and NINetworkImageView.
Facebook profile url looks like that: http://graph.facebook.com/806210656/picture
However it is redirected to this: http://profile.ak.fbcdn.net/hprofile-ak-snc4/261023_806210656_4149503_q.jpg

The image is added to the cache with the redirected url, so it is never hits for the original url. fun :)

All of the core methods from Three20 need to be migrated over. Each method needs to be properly documented and unit tests must be made as per the Nimbus requirements.

Important files:

TTGlobalCore
TTGlobalCoreLocale
TTGlobalCorePaths
TTGlobalCoreRects

A network enabled table view controller should support the following features:

• Loading indicator while the table is initially loading.
• Infinite loading (from the top and bottom).
• Pull to refresh or pull to fetch more.

The interface for fetching information from the network should be generic enough to allow loading from disk and memory as well. See the Nimbus Photos implementation for an example of this.

Occurs when using a NINetworkImageView in a NIB file, as an UIImageView subclass. Everything works, except that the http request is never sent (no logs, no error). Reason is self.networkOperationQueue is not assigned, because NIBs init is:
(id) initWithCoder:(NSCoder *)decoder

This init doesn't exist in NINetworkImageView, and self.networkOperationQueue is assigned in - (id)initWithImage:(UIImage *)image...

Solution is adding a initWithCoder method with all default assigns.