v1.10 Upgrade Tips: New SC.SplitView

written by Dave Porter

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 topLeftView and 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.

SproutCore 1.10.1 Release

written by SproutCore

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.
  • Fixed SC.Module loading for IE11 and future versions.
  • Fixed SC.Drag cancellation with the Escape key to call dragEnded for cleanup.
  • Added a retina image for the default theme of SC.MenuPane.
  • 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 SC.browser.

Welcome New Committers: Nicolas Badia & Greg Fairbanks

written by SproutCore

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 sproutcore@googlegroups.com and show them your support.

SproutCore 1.10.0 Release

written by SproutCore

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 sproutcore@googlegroups.com 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.

Continue reading

v1.10 Upgrade Tips: invokeFoo Developer Warnings

written by Dave Porter

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
Continue reading