Although it has been out for a couple weeks already, I had never officially announced the completion of the SproutCore Web Application Development book in this blog. So for anyone that has been waiting for a book on SproutCore, you should know that it has finally been completed and you can purchase a copy here.
This book covers almost every aspect of SproutCore with detailed explorations of the runtime environment, the MVC layers that SproutCore brings, using statecharts, interacting with multiple remote data stores and many many other topics all the way through to unit testing and deploying real SproutCore applications. So if you’re looking to take the next big leap in web software development and have ever been curious about SproutCore, now is your chance to learn everything you need to know in one easy read.
SproutCore 1.10.2 is now available. This is a patch level release and includes the following fixes:
- Fixed problems with keypress handling in IE8 and Opera.
- Fixed the swap transition plugin,
SC.ContainerView.REVEAL, to properly reset the content view’s layout after transitioning out.
- Fixed a problem with
SC.View.prototype.cancelAnimation(SC.LayoutState.CURRENT) that failed to stop at the proper top or left positions when using CSS transform animations when the top or left values were negative. This also improves the
SC.ContainerView.PUSH transition, making it possible to push multiple content views without overlapping (see example).
SC.ContentValueSupport to notify a change to each of the dependent content keys when the content changes entirely (i.e. the ‘*’ property changes).
SC.SelectView to update correctly when its items collection is replaced.
SC.AutoMixin to prevent the attributes from the former child views being applied to the latter child views.
- Fixed locally-scoped ‘and’ & ‘or’ bindings.
- Fixed a problem when the initial
isEnabled value of a view is
false, that failed to update the
isEnabledInPane value of that view and its child views.
- Fixed the problem that setting the
isEnabled value to
true of a view which had disabled ancestors, could change the value of
isEnabledInPane for that view to
SC.TextFieldView being able to still be edited if it had focus at the same time that an ancestor view was disabled.
- Fixed the
defaultTabbingEnabled property of
SC.TextFieldView to actually prevent tabbing when the property is set to
false. Also added
insertBacktab handler support to
interpretKeyEvents in order to prevent tabbing on shift-tab in
- Added missing support for touch events to
- Fixed a bug that caused
SC.TextFieldView hints to have a
0px line-height at times.
- Fixed a regression in collection views that prevented them from properly re-rendering when inside nested scroll views.
- Removed a duplicate listener on
selectstart events in
- Removed the jQuery ready hold in
SC.platform that was used to delay launching of the app until the transition and animation event names tests completed. Several browsers will not run the transition/animations in hidden tabs, which slows and possibly blocks an app from launching. Since the results of these tests are used only to optimize the event listeners set up in
SC.RootResponder, the code has been changed to setup the root responder at whatever point the tests successfully finish.
- Fixed picker panes failing to popup in the wrong place if they have some form of resizing. Added an observer to
SC.PickerPane border frames so that the pane will re-position itself if it changes size.
- Removed the appearance of an
undefined attribute in
- Fixed internal identification of IE7 to prevent any possible future version of Trident from being mistaken for IE7.
- Fixed a minor memory leak when manually removing event listeners from an element.
- Fixed a minor memory leak when using
This post is about one of the most important goals of SproutCore, making web app development easier and faster. SproutCore has always been largely about really fast app performance, but in many ways the performance benchmarks of a framework are only as good as the real world performance of the developers using that framework. Therefore, we wanted to highlight a number of recent additions to SproutCore purely for the purpose of helping developers create even faster SproutCore applications even faster.
One of the underpublicized changes we made in v1.10 was the inclusion of a great new
SC.SplitView. The existing view was broken in some key ways, and the new view, which had been marinating in an experimental framework for some time, was snazzy and stable. We decided that few enough people had gotten
SplitView working in their production apps that we could afford to swap in the new view, but it’s API-noncompliant and we should have made a bigger deal about it. Sorry about that!
Luckily, updating to the new
SplitView is easy. The most important thing to do is mix
SC.SplitChild into your
bottomRightView. If you want your views to have an initial height or width, depending on
layoutDirection, just set the
size property (whole-number pixel values only). The best news is that a
SplitView can now handle an arbitrary number of sections – you specify them in its
childViews array, just like a normal view.
Full documentation for the new SC.SplitView available here; more information about the new SplitChild mixin available here.
The first patch release of SproutCore 1.10 is now available. This update includes the following fixes:
- Allows inline text fields to work with automatic child view layout.
SC.Module loading for IE11 and future versions.
SC.Drag cancellation with the Escape key to call dragEnded for cleanup.
- Added a retina image for the default theme of
- Fixed the touch selection of
SC.CollectionView to prevent an item from appearing deselected when touched twice in a row.
- Fixed the insertion point code for
SC.GridView in order to show an insertion view when dragging and dropping onto grid views.
- Fixed an issue with
SC.ScrollView which would cause the HW accelerated content offset to be incorrect when the content view re-renders.
- Improved the deceleration animation of
SC.ScrollView for better performance.
- Fixed an error in the deceleration animation of
SC.ScrollView that could throw an exception when stopped very quickly.
- Changed the
SC.EmptyTheme class name to
sc-empty-theme to avoid conflicts with the use of
sc-empty. This fixes a bug where
SC.ProgressView would always appear empty when used with the empty theme.
- Fixed incorrect behavior of
SC.Statechart sendEvent that allowed events to be sent during a state transition.
- Fixed a bug that prevented queued events due to a state transition from being sent when the state transition was complete.
- Fixed a caching problem with
SC.routes that would allow the location property to be incorrect depending on how it was changed.
- Fixed a regression in determining the OS of Linux and Android in
We’re pleased to announce that Greg Fairbanks and Nicolas Badia have accepted becoming SproutCore Committers. These two have been especially active in submitting fixes and improvements to the framework and are great examples of persevering through the process of vetting pull requests with the core team in order to ensure each change meets the high standards of SproutCore. It can be a tedious process to get something approved, but the end result is better code that stands the test of time. Now that they are official Committers this will become even easier for them.
For those that aren’t sure of the difference between Committers and Reviewers, Committers are actually required to work in their own branches in the repo and submit every change as a pull request to be accepted by a Reviewer. The Reviewers are allowed to make direct fixes, but will most likely submit anything at all substantial as a pull request too in order to get a few other Reviewers’ feedback and acceptance. Both roles also include the responsibility to try to move the outstanding issues and pull requests towards a resolution.
As you can tell from the above description, both roles are a lot of work and it takes people with a real dedication to the project to accept what can be a thankless and demanding task, so please take a moment to catch all of these people on #sproutcore and email@example.com and show them your support.
The SproutCore team is very pleased to announce the final release of SproutCore version 1.10.0. This version is the fastest, most feature-rich and most stable version of SproutCore to-date and includes several new additions and improvements to make development with SproutCore even better and to make SproutCore apps that much more impressive. For a quick introduction to the many changes in version 1.10, please check out the official press release.
For those wishing 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
If you have any trouble installing or upgrading to 1.10, be sure to visit the mailing list firstname.lastname@example.org or the IRC channel #sproutcore for support. As always, the team and community are here to help!
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 and live updates; extensive internal architectural refactors to boost speed and reduce memory consumption; and more.
Upgrading your project to 1.10 is a no-brainer – even if you never get around to adding a little easy flare with view transitions, you get a free performance boost from the plugged memory leaks and Tyler’s great work refactoring SC.View. 1.10 also makes some changes under the hood which take some previously not great practices and turn them into warnings or breaks. These are good changes, and enable a lot of the efficiency gains that we packed into this release, but there are some previously-common practices that trigger some new developer warnings, so I want to go over what’s causing them and how to fix it.
You should read this post if you’re receiving unexpected developer warnings to the effect of “
Developer Warning: invokeOnce called outside of the run loop. This can cause problems in production code if not addressed.” I’m going to cover these possible causes of this issue:
- Misusing .create() when defining your view layer
- Using SC.MenuPane.create() when defining your view layer
- Using SC.FileFieldView ever
- Handling browser events directly, without setting up a run-loop
The third release candidate of Version 1.10.0 is now available. This version wraps up several internal changes to boost the performance of SproutCore views and closes a few more smaller bugs. If you’ve already installed the previous release candidate, please run:
gem update sproutcore —pre
Changes in 1.10.0.rc.3
- Bug fixes.
- Performance improvements.
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
- Improves the regular expression used by
SC.RenderContext to escape strings so that HTML entities like
à 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.