SC.ListView has a new trick in the upcoming v1.11 (available now on latest master): a new
layoutDirection property which can turn it from vertical to horizontal with one line of code. It’s a long-requested feature, and now it’s as easy as
In support of this brave new world, a number of list view properties have new names, replacing all now-outdated mentions of “height” with “size”:
rowHeight is now
rowSize, et cetera. The new API is backwards-compatible with the old one, with the usual crew of helpful developer warnings to ease your project over without breaking it.
It’s been noted often that there’s a serious lack of production-level SproutCore apps with readable source code. Developers often learn best by poking at something and seeing how it works, but until now there hasn’t been anywhere to go.
With an eye towards improving that situation, I’m excited to announce Juniper, a SproutCore app and annotated codebase. Check it out:
I wrote a fuller introduction here, and the source code itself is here.
If you’re new to SproutCore, or wondering if it’s right for your project, give it a poke! If you have any questions, say hi on the mailing list or on IRC. Any seasoned developers that want to give it a critical look-over should do so too – it’s intended as a showcase of possibilities and best practices, so if you spot something, hit me up in the GitHub Issues or directly.
(Juniper is inspired by Vesper, a really great note-taking app for the iPhone. If you have an iPhone and are underwhelmed with the built-in Notes app, you should check it out.)
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.
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
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.
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: