SproutCore 1.11.0 Release Candidate 1

written by SproutCore

We are pleased to announce the pre-release of SproutCore 1.11.0. Where version 1.10 drastically reduced the memory use of SproutCore, 1.11 goes even further to ferret out bottlenecks and improve the overall performance for SproutCore apps.

This new version also introduces many API improvements and additions to further ease the development of modern large scale web applications. When 1.11.0 final is released in the coming weeks, we will post an in-depth look at the major changes, but until then, the full list can be viewed here: https://github.com/sproutcore/sproutcore/blob/master/CHANGELOG.md

To install SproutCore 1.11.0.rc1 for testing, please upgrade your previous version of SproutCore by running the following:

gem update sproutcore –prerelease

We will be using your feedback over the next few weeks to finalize 1.11.0, so please be sure to try it out and let us know what you think: Github Issues, #sproutcore on IRC or email to sproutcore@googlegroups.com.

Developer Journal

written by Tyler Keating

Since there has been so much activity in SproutCore lately in the run up to 1.11.0, I thought it would be best to start a more regular update on the changes occurring in master. While we occasionally highlight a specific new feature in depth through a “Dispatches from the Edge” post, there are actually hundreds of small, yet interesting, changes occurring weekly that aren’t large enough to warrant their own post. It’s my hope to capture these changes in a weekly to bi-weekly developer update. So let’s begin with the last couple of weeks (Note: no changes are final).

Touchy Mice

If you own an Apple Magic Mouse, you may have found some web apps difficult to use. A notable public example of this problem was in the Google Maps app. When you released your finger after dragging the map around, the extra mouse wheel events that were sent as your finger was lifted caused the map to zoom in and out rapidly. Now I believe Google has fixed that problem with their app and we have as well for SproutCore’s SC.SliderView and SC.ScrollView, both of which use mouse wheel events. To prevent the extra mouse wheel events that can occur on click or release from triggering the control, we ignore any mouse wheel events that fire while the mouse is pressed up until 250ms after the mouse up event. Depending on how adept your users are with their mice clicks, the result may be a huge improvement or barely perceptible, but even as small a change as it is to prevent scrolling jiggle on mouse click, it’s just one more brick in the incredible user experience wall that we’re trying to build with SproutCore.

Performance

We’ve been working diligently on SC.ScrollView performance (more on that later), but in the process we’ve implemented some other performance improvements.

We fixed a problem with excessive layout updates for certain types of views. If a view used viewDidResize to check for size changes and then make further adjustments to its position, the adjustments to its position would have appeared as further changes to its size. In particular, SC.PickerPane suffered from this, since it re-positions itself whenever its size changes.

Speaking of SC.PickerPane, this one got a performance scrub down. You may not have been aware, but SC.PickerPane now has some special code enabling it to appear within scrollable content and move correctly when the content scrolls. It’s a really nice advanced feature, but there were a couple of issues hampering the performance of it. The first was that the scroll view observers were too greedy observing offsets of the scroll view for changes and repositioning on each change. What this meant was that an SC.PickerPane could reposition itself up to 6 times in a single run loop as the content of the scroll view changed. Instead, the proper pattern for observing multiple properties (or noisy properties) is to filter the input through an invokeX (i.e. so even though 6 calls to the observer function may occur, we only call positionPane once). Additionally, we no longer observe the offsets if the scroll view can’t even scroll and finally, there is a bug fix in there too. When the picker’s anchor gets moved on its own, we ensure that the anchor is in its new position before we re-position.

One of the most important classes within SproutCore has been sped up a bit too. SC.State had two observes helper functions used to be notified when its enteredSubstates and currentSubstates arrays changed. Since these arrays are modified by the owner statechart, the observers needed to be chained enumerable observers. However, this resulted in slower object initialization for each state object and excess observer firing as the entered and current substates change. Instead, we simply notify the target state directly each time that the owning statechart makes a change to its enteredSubstates and currentSubstates. This one has has a couple benchmarks to site:

Benchmarks:

  • initStatechart in unit tests: ~21ms to ~13ms (~38% faster)
  • initStatechart in large application: ~81ms to ~51ms (~37% faster)

While a reduction of 30ms in a, generally once run, method isn’t much to write home about, we are relentless in shaving every possible millisecond that we can. More notably, we’ve recently made some serious performance improvements to the core SC methods: SC.mixin, SC.supplement as well as to SC.Function.enhance. SC.mixin and SC.supplement iterated the arguments object to insert a boolean flag to pass to a private function that then iterated the arguments again in order to remove the flag argument, which is totally unnecessary. Instead, SC.mixin and SC.supplement iterate the arguments once and pass the new Array to the private function, removing the need for a second iteration.

More importantly though, is that these three areas no longer access the arguments object to copy it, which required the browser to instantiate it and is costly. Instead, we now do a fast copy (similar to this: http://jsperf.com/closure-with-arguments) without instantiating the arguments object. By doing a fast copy of arguments these functions are now optimizable by V8.

Benchmark: SC.mixin & SC.supplement ~ 58% faster

Also,SC.RenderContext‘s setStyle method was updated so that it could be optimized for V8 as well.

SC.ScrollView and SC.MenuScrollView Refactor

This one will actually get its own blog post. For now, I just wanted to mention that these views have seen massive refactoring. The purpose of the changes has been to simplify the logic, which had gotten fairly unruly, but more importantly to grind and grind on the little details so that scrolling and scaling should feel as good and as natural as possible. We’ll post an in-depth on SC.ScrollView in the next couple weeks.

SC.MenuPane Tidy

We fixed SC.MenuPane automatic resizing to fit within the window. The positioning code used in SC.PickerPane failed to apply adjustments to the width or height of the pane, which had been calculated in order to fit long menus within the window. This included improving the menu positioning code to respect the value of windowPadding and fixing a problem where the items array was not observed for content changes if it was set on create.

We removed an unnecessary layout change in createChildViews, which also meant that creating a menu pane as a singleton (i.e. with no run loop) would throw invokeOnce warnings.

WARNING We removed the SC.MenuPane.VERTICAL_OFFSET property. SC.PickerPane already has a provision for offsetting panes from the window’s edges, windowPadding, and that is the property that is being used now.

General fixes and changes

Finally, there are always a large number of little changes. Here are some from the last few weeks.

  • Removed an extra call to SC.RootResponder‘s computeWindowSize each time that a pane is appended. This is unnecessary, since the root responder recomputes its window size property whenever the window actually resizes.
  • Improved the default styling of overlay scroller views. Making them look more like natural overlay scrollers in OS X and making them more visible against dark backgrounds.
  • Improved the view management of SC.ContainerView a bit. If contentView is set as an uninstantiated view class, it will instantiated correctly (you should set nowShowing though normally).
  • Fixed SC.ObserverSet to pass the given context to the observer method. SC.ObserverSet.prototype.add() accepts a third argument, context, but it did not actually pass it along to the observer method.
  • Improved SC.MenuItemView handling of submenus. Previously if the item’s submenu was visible and the mouse exited back onto the menu item view, it tried to re-append the same submenu. Instead, it now checks to see if its submenu is already attached before attempting to enter it again.
  • Fixed a bug in SC.ContainerView‘s override of set so that it may be chainable.
  • Did you know you can cancel animations created with animate in place? This includes transform transitions whose in place value is represented as a 4×4 matrix that must be decomposed to find the current value for translate, scale and rotate in the three planes. We’re still working on rotation around the X and Y axis, but all other transforms can be cancelled. A demo on this will come later.

I apologize that this post is quite long, if it actually included all the work in the scroll and scroller views it would be three times longer, but as you can see, there is a lot going on. I hope to keep these posts much shorter from now on by keeping them more regular.

Dispatches From the Edge: Polymorphic Records

written by Tyler Keating

We have good news for anyone using the experimental polymorphism framework from within SproutCore. You’ll be glad to know that it has now made its way into the official datastore framework as part of SC.Record. If you have been using this framework, you’ll be even more glad to learn that polymorphic records are now significantly faster and more memory efficient. As well, this change includes a critical bug fix that resulted in polymorphic records getting mismatched when their id was changed.

For those interested in what this change means, here’s how it works. First, if you’re not familiar with polymorphism, it’s similar to inheritance, but differs in that polymorphic subclasses share a common “identity”. Here’s what that means with respect to the data model. In typical inheritance, the subclasses inherit the traits (attributes) of their superclass, but they can’t stand-in for that superclass (i.e. their identity or type is unique). In polymorphic inheritance, the subclass still inherits the traits of the superclass, but is now also considered to be the “same” type as the superclass. This means that when you query for records of a polymorphic super type, you’ll also receive records of all the polymorphic sub types.

This is especially useful functionality, because data is often stored in exactly this type of generic manner. It’s typical in SQL databases to have a large table where certain attributes apply to one specific subtype of the data, other attributes apply to another subtype and some attributes apply to all. With polymorphism, we can model this situation precisely.

So how do we use it in SproutCore? It’s simply a matter of adding the isPolymorphic property to a record class and extending it. Let’s look at an example from the SC.Record documentation that will hopefully clear up any remaining confusion on how polymorphism works.

// This is the "root" polymorphic class. All subclasses of MyApp.Person 
// will be able to stand-in as a MyApp.Person.
 MyApp.Person = SC.Record.extend({
   isPolymorphic: true
 });
 
// As a polymorphic subclass, MyApp.Female is "equal" to a MyApp.Person.
 MyApp.Female = MyApp.Person.extend({
   isFemale: true
 });
 
// As a polymorphic subclass, MyApp.Male is "equal" to a MyApp.Person 
// also. Not it is not "equal" to a MyApp.Female.
 MyApp.Male = MyApp.Person.extend({
   isMale: true
 });
 
// Load two unique records into the store.
 MyApp.store.createRecord(MyApp.Female, { guid: '1' });
 MyApp.store.createRecord(MyApp.Male, { guid: '2' });
 
// Now we can see that these records are in fact "equal" to each other. 
// Which means that if we search for "people", we get "males" & 
// "females".
 var female = MyApp.store.find(MyApp.Person, '1'); // Returns record.
 var male = MyApp.store.find(MyApp.Person, '2'); // Returns record.
 
// These records are MyApp.Person as well as their unique subclass.
 SC.kindOf(female, MyApp.Female); // true
 SC.kindOf(male, MyApp.Male); // true

Enjoy!

Dispatches from the Edge: ListView Goes Sideways

written by Dave

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 layoutDirection: SC.LAYOUT_HORIZONTAL.

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.

Happy horizontaling!

Automating SproutCore Unit Testing with PhantomJS

written by Greg

One of the new features in SproutCore v1.10.0 was a PhantomJS unit test runner. It allowed us to automate SproutCore’s own framework unit tests, giving us awesome continuous integration support right in GitHub via the great Travis-CI service.

If you use CoreTest, SproutCore’s built-in (QUnit-like) unit test framework, then you can also use this to run your own tests from the command line – meaning you can automate it, and hook it up to your own CI scaffolding. It’s impossible to overstate the impact that continuous, automatic unit testing has on the quality and stability of your codebase.

Prerequistites

You will need to have PhantomJS installed before using the test runner. Full instructions for this can be found here.

If you are using SproutCore 1.10.1 or later, you can use the new sc-phantom command. This will handle invoking the test runner, passing through any arguments to PhantomJS.

If you are using 1.10.0 or are not using the gem, you will need to track down SproutCore’s installed location in order to run its test runner script. If you’ve got a copy checked out into your project’s frameworks directory, great! Just use that. If you’re using the gem, you’ll have to track it down yourself. It’s usually somewhere like ~/.rvm/gems/ruby-1.9.3-p374/gems/sproutcore-1.10.0 – if you’re unable to track it down, run gem env and look under the GEM PATHS heading for a hint.

Running the tests

First, start sc-server as you normally would. Once that is running, we can start the test runner. (If you are running SproutCore v1.10.0, replace sc-phantom with phantomjs $SC_PATH/lib/frameworks/sproutcore/phantomjs/test_runner.js in the following examples. See $SC_PATH note above for details.)

sc-phantom

By default, this will run all the unit tests that abbot knows about, including the tests in SproutCore itself. This is probably not what you want, so you can use the --include-targets flag to tell the test runner what tests you want to run.

For example, if your app is called todos, running

sc-phantom --include-targets=/todos

will run only the unit tests in your app. If you also have a framework you want to test, you can make the argument to –include-targets a comma-delimited list of targets:

sc-phantom --include-targets=/todos,/my_framework

There are a few other options available for excluding certains tests and only running certain types of tests (app, framework, etc). For the full list, run:

sc-phantom --help

Introducing Juniper: SproutCore app + annotated source

written by Dave

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:

http://juniper.dcporter.net/

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.)

SproutCore Book Available

written by Tyler Keating

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.

Thank you!

 

SproutCore 1.10.2 Release

written by SproutCore

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).
  • Fixed SC.ContentValueSupport to notify a change to each of the dependent content keys when the content changes entirely (i.e. the ‘*’ property changes).
  • Fixed SC.SelectView to update correctly when its items collection is replaced.
  • Fixed 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 true.
  • Fixed 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 SC.TextFieldView.
  • Added missing support for touch events to SC.PopupButtonView.
  • 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 SC.RootResponder.
  • 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 SC.TextFieldView.
  • 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 SC.InlineTextField.

Building Bridges

written by SproutCore

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.

Continue reading

v1.10 Upgrade Tips: New SC.SplitView

written by Dave

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.