SproutCore 1.10.0 Release Candidate 2

written by SproutCore

We’ve just published the second release candidate of Version 1.10.0. The first candidate gem was incorrectly packaged and would not work with a regular install. If you’ve already installed the first release candidate, please run:

gem update sproutcore --pre

Changes in 1.10.0.rc.2

  • Fixes gem problem, which resulted in `gem_original_require': no such file to load -- bundler/setup errors when trying to run any of the SproutCore command line tools.
  • Removes a developer warning when animating with a duration of 0, which can be valid if the duration is calculated. In any case, animating a duration of 0 has always been supported by SC.View.prototype.animate.
  • Improves the regular expression used by SC.RenderContext to escape strings so that HTML entities like ' or à are preserved.
  • Fixes a regression with SC.RadioView that failed to add the disabled class to disabled radio items.
  • Fixes some internal SproutCore unit tests.

SproutCore 1.10.0 Release Candidate 1

written by SproutCore

The SproutCore team is pleased to announce the pre-release of SproutCore 1.10.0. Version 1.10 is, without a doubt, the fastest and most feature-rich version of SproutCore to-date and includes several new features, internal improvements and bug fixes and is a recommended upgrade for all SproutCore developers.

To install SproutCore for the first time, please visit http://sproutcore.com/install/ for instructions. If you are upgrading from a previous version of SproutCore, simply run the following:

gem update sproutcore --prerelease

Highlights of Version 1.10.0

In this release we dug deep into the core of SproutCore to improve the entire development and runtime experience from start-to-finish. This includes clean-ups of the developer API to improve consistency and memorability, brand new features for automatic layout, transition animations, live updates and more and working through extensive internal refactors of key components to boost speed and reduce memory consumption.

Continue reading

Develop SproutCore on Cloud 9

written by Dave Porter

Contributor & community member Umberto Nicoletti has discovered a great way to develop SproutCore applications – and SproutCore itself – using Cloud 9’s great browser-based IDE for free, any time, and anywhere, including his living room! He’s got a step-by-step guide to firing sc-server off in a Cloud 9 workspace up on his blog; check it out here.

Dispatches From the Edge: Automatic Transitions and SC.View Optimizations

written by Tyler Keating

Version 1.10 is shaping up to be a fundamental advancement of SproutCore as the best framework for creating powerful user experiences on the web.  We’ve already been doing the best of breed practices for creating dynamic web applications for some time.  For example, running in the client, maintaining the application “truth” in code, minimizing touching the DOM and many other practices that keep SproutCore apps as fast as possible.  These features allow you to create extremely complex interfaces that update instantly as the user interacts with them.  However, while instant updates were a major advancement, they can give the interface a jarring feel and therefore the next level of application design is to go beyond instant updates and add “life” or “play” to your user interface with subtle transitions.

As such, SproutCore 1.10 will include a new automatic transition architecture that is so easy to use, developers can actually play around with complex transitions while first implementing a view rather than needing to commit more time to it later.  To do so, you simply specify a transition plugin to use during one of the four state changes: appending, becoming visible, becoming hidden and removing.  To make it even easier, SproutCore includes a few built-in transition plugins: SC.View.FADE, SC.View.MOVE, SC.View.BOUNCE, SC.View.SPRING and SC.View.SCALE and it’s very easy to write your own transition plugins to do any type of advanced animation based on the SC.Transition protocol.

Continue reading

classNameBindings: Dynamic CSS classes made easy

written by Dave Porter

As a mature framework, SproutCore is full of little features to make common tasks drop-dead simple – including some hidden gems. I recently added some documentation to the framework (and to the indispensable docs.sproutcore.com) for one of them, and wanted to highlight it here on the blog too.

Dynamically adding and removing CSS classes on a view is a common need — for example, to swap background images when a property changes. But there’s no obvious way to do this; I burned my share of time trying to crack it manually, and I’ve watched other devs do the same. The usual solution ends up being a custom renderer, but that’s messy and verbose, operates at the wrong level of abstraction, and opens the door to all kinds of bugs if you’re not intimately familiar with the render API.

Enter classNameBindings. It’s is a quirky but powerful little property that makes dynamic class names a breeze. (No relation to the convenience key format fooBinding, by the way.) Here’s what classNameBindings looks like:

Continue reading

SproutCore 1.9.2 Released

written by Tyler Keating

We are pleased to announce the immediate release of SproutCore 1.9.2.  This release contains important fixes to the 1.9 code-base and is fully backwards compatible.  We recommend that all users of SproutCore upgrade to this latest version in order to have the best development experience.  To upgrade to the latest version, simply run:

gem update sproutcore

This is a patch release and contains the following bug fixes:

Build Tools

  • We’ve softened the build tools dependency requirements from being ultra-pessimistic (i.e. within the minor version) to being just pessimistic (i.e. within the major version).  This helps to prevent Bundler conflicts.
  • Fixes the snake case generator for ‘sproutcore gen‘, so that names like ‘SCProject’ get properly transformed to ‘sc_project‘ and not ‘s_c_project‘.
  • Fixes the ‘$repeat: repeat‘ property used with the @slice SCSS directive when generating the @2x version.  It was incorrectly appending @2x to the end of the whole path (ex. /resources/images/image-sliced-from.png@2x) instead of inserting it before the extension (ex. /resources/images/image-sliced-from@2x.png).
  • Fixes incorrectly named “responder” generator to “state” generator for generating SC.State subclasses.  You can now generate an SC.State file using ‘sproutcore gen state‘ or ‘sc-gen state‘.
  • Added support for un-prefixed background-size CSS attribute when spriting.  This allows spriting to work properly in retina Firefox.
  • Fixes inconsistencies and improper syntax in several templates created with ‘sproutcore gen‘.  Generated files are now cleaner and provide more descriptive help comments.
  • Fixes missing stylesheet warnings on a clean app generated with ‘sproutcore gen app‘ or ‘sproutcore gen statechart_app‘ by adding a default stylesheet to the app. Also adds a default stylesheet to a design, when using ‘sproutcore gen design‘ (i.e. creating an SC.Page resource).


  • Fixes regression in IE7 and IE8 which caused XHR requests to fail to notify.
  • Fixes improper binary search used by SC.ManyArray.prototype.addInverseRecord that resulted in an infinite loop when using addInverseRecord with an orderBy function.
  • Fixes bug that allowed the context menu to appear regardless of overriding contextMenu in a view or setting SC.CONTEXT_MENU_ENABLED (globally) or isContextMenuEnabled (on a view) to false.  This makes the context menu event handling behave the same as the key, mouse, etc. event handling.
  • Fixes actions: insertNewLine, deleteForward, deleteBackward, moveLeft, moveRight, selectAll, moveUp and moveDown to be always handled by the SC.TextFieldView element when it has focus.
  • Fixes the hint value for SC.LabelView so that it will appear when the label has no value and isEditable is true.
  • No longer modifies the underlying items given to an SC.SegmentedView directly so that we don’t dirty the original objects.
  • Fixes debug files being included in builds. These files (one of which is a 2.5MB test image) would get included into every build, because they were at the wrong path.  These files should not ever be loaded in an app, but if you created an app manifest based on the contents of the built static directory, you could invariably cause the client to download over 2.5MB of files that are never used.
  • Fixes determination of touch support in Chrome on Win 8.
  • Adds missing un-prefixed border-radius rules to the default theme for browsers that have dropped the prefix.

As always, every bug fix includes an accompanying unit test to ensure that the bug does not re-appear in the future.

Dispatches From the Edge: Super Fast Collections

written by Tyler Keating

One of the most advanced changes coming in 1.10 is the formalization of a major enhancement to SproutCore’s collection views.  Some of you may have heard of, used or tried to use the SC.CollectionFastPath mixin which gives SproutCore’s collection views, namely SC.ListView and SC.GridView, a massive performance boost.  The performance boost comes from pooling the item view objects, pooling item view layers (i.e. elements) and re-positioning layers using layout styles without modifying the DOM tree.  By re-using objects and elements, we can increase the speed that our collections can update, making gigantic lists perform like butter, even on mobile.

However, using SC.CollectionFastPath was unwieldy and difficult to get working correctly.  Turning it on was not enough, you also had to provide a couple properties on your item view class that were totally undocumented.   Due to the fact that SC.CollectionView is already optimized to create item view objects and layers only for the visible portion of the collection, it could be hard to even be sure that the fast path code was active or not.  This is all changing in 1.10.

We believe that every SproutCore view should be as fast as possible out-of-the-box on every platform and so we’re making these improvements a part of SC.CollectionView directly.  This means that by default, SC.ListView and SC.GridView will be fully optimized without any further configuration.  That said, when creating custom item views, you should properly support render and update.  Since view performance is so important, you should already know how to do this and if you need a good example, check out the custom item views in the new demo in the SproutCore Showcase.  This demo was created to debug this new technology as well as to demonstrate working with gigantic lists.

For now, the feature is still being tested and fine-tuned and any additional real-world feedback is appreciated.  So please check it out on the SproutCore master branch and bring any issues forward so that they can be addressed before release.



For discussion, please use sproutcore@googlegroups.com or #sproutcore on IRC.

Note:  Whereas, before you needed to set properties to turn this on, you have to set properties to turn it off right now.  If for whatever reason, you don’t want to pool elements, you can set isLayerReusable to false on your custom item view and if you don’t want to pool views, you can set isReusable to false as well.

Dispatches From the Edge: Invoking “Next”

written by Tyler Keating

As the 1.10 release nears completion, I thought I’d better start writing about some of the many improvements now, lest the final release blog post would take me two days to write.  A lot of the changes, including today’s topic, were the result of working on big feature additions and discovering that more support was needed closer to the core.  Which brings me to the topic of this post:  SC.RunLoop.prototype.invokeNext. Continue reading

SproutCore 1.9.1 Released

written by SproutCore

We are pleased to announce the immediate release of SproutCore 1.9.1.  This release contains important fixes to the 1.9 code-base and is fully backwards compatible.  We recommend that all users of SproutCore upgrade to this latest version in order to get the best development experience.  To upgrade to the latest version, simply run:

gem update sproutcore

This is a patch release and contains the following bug fixes:

  • Fixes a bug that left childView elements in the DOM when they were rendered as part of their parent’s layer and the child was later removed.
  • Fixes improper implementation of SC.SelectionSet:constrain() that prevented the last object in the set from being constrained.
  • Fixes minor memory leak due to implicit globals in SC.MenuPane.
  • Fixes memory leak with child views of SC.View. The ‘owner’ property prevented views from being able to be garbage collected when they were destroyed.
  • Fixes SC.stringFromLayout() to include all the layout properties.
  • Fixes the excess calling of parentViewDidResize() on child views when the view’s position changes, but it’s size doesn’t.
  • Fixes an issue that occurs with SC.ImageView’s viewDidResize implementation, where it fails to resize appropriately.
  • Fixes a bug in SC.Locale that caused localizations to be overwritten by the last language localized.
  • Fixes SC.Request’s application of the Content-Type header. It was incorrectly adding the header for requests that don’t have a body which would cause some servers to reject GET or DELETE requests.
  • Fixes a bug where SC.Record relationships modified within a nested store, would fail to propagate the changes to the parent store if isMaster was NO in the toOne or toMany attribute.

As always, every bug fix includes an accompanying unit test to ensure that the bug does not re-appear in the future.  For further details, please view the complete Change Log.