Automating SproutCore Unit Testing with PhantomJS

written by Greg

Comments Off

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

Comments Off

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

Comments Off

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

Comments Off

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

Comments Off

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

Comments Off

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

Comments Off

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

Comments Off

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

Comments Off

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

Comments Off

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