Structuring Large-Scale SproutCore Project Teams

written by Peter Bergstrom

Writing large desktop-like applications in SproutCore comes with a unique set of challenges that you wouldn’t encounter writing a smaller application. A smaller project with one or two contributors is a lot more flexible and requires less planning; a large project with many contributors and moving parts is a completely different beast.

I’ve worked on many SproutCore applications, both large and small, since 2007 and I’ve seen where a project can get into trouble when it grows larger both in scope and in team size. The goal of this post is to share some of my personal experience developing a large SproutCore application.

The Bliss of Smaller Projects

The benefits of smaller projects with one or two developers are relatively obvious. A small team makes it easy to stay on task for the limited scope of the project. Everyone knows what is going on because communication is easy and each developer has the opportunity to wear every hat in the project. Also, the developers working on the project know the code well throughout, mainly because two developers can transfer knowledge and be most effective if they are pair programming.

The Challenge: a Large Application

If you are given the task of creating a larger SproutCore application, such as a calendaring client, one or two developers cannot possibly deliver the application in the required time frame. In some cases, more than 100,000 lines of code may be required, much more than a small group of developers can manage.

In this case, the team must grow to a size where you can meet your timelines while not adding so many people that the project slows down. Since there is so much to do, you need to split up responsibilities; instead of having developers wear all the hats in the project, developers wear one or two hats, and act as the person the rest of the team can trust to deliver their specialized part of the code or functionality.

This is true of working in any large team; the goal of this post is to highlight the particular roles that need to be filled when creating a SproutCore project in particular.
Continue reading

Dispatch From The Edge: New Controls Built on Templates

written by Greg Moeck

The construction of the view layer has been greatly simplified by the new way of delegating the view’s rendering to templates. With templates, most things have gotten easier to do– particularly view rendering. However, there are a couple of benefits that the older ways of building views provide that became a bit more difficult within templates– namely, building controls. In this post, I’ll take you through the ways in which Templates have affected how we construct controls, and how to build yours as efficiently as possible.

Before templates, we had several drop-in objects that handled common controls. If I wanted to add a button to a view, all I had to do was something like this:

SC.View.extend({   
  button: SC.ButtonView.extend({     
   target: object,     
   action: 'something'   
  }) 
})

What was nice about this approach was that you didn’t have to worry about describing exactly how the button renders, or how it responds to things like mousedown or mouseup. This was convenient because generally all buttons have the same structure and code, and it let us work at a higher level of abstraction. If we were to do this inside of a new template structure, we would have to do something like the following:

views:
 
BaseView = SC.TemplateView.extend({   
        templateName: 'some_template' 
})
 
CheckAllView = SC.TemplateView.extend({   
    target: object,   
    action: 'something,   
    ...   
    mouseUp: function() {     
      ...
      this.get('target')[action]()
      ...
    }
    ...
 })
 
template:
<div class="something">
    ...   
    {{#view CheckAllView }}      
 
    {{/view}}   
    ...</div>

Continue reading

To Do: Build a SproutCore App

written by SproutCore

In this 10-minute screencast, Tom Dale takes you from creating an empty SproutCore project to building a simple todos application. You’ll learn about defining model objects, crafting a user interface using HTML, then connecting them together with controllers. While doing so, Tom explains how thinking of your app in terms of its state, instead of how to respond to events, will change the way you build applications.

SproutCore 1.6 Beta Released

written by Tom Dale

We’re excited to announce the release of SproutCore 1.6 Beta 1. As we mentioned in our last blog post, we are switching to a six-week release cycle, and this is the first release in that new plan.

Because we will be releasing more frequently, each release will be less of a big-bang release and more incremental improvements to what we had before. SproutCore 1.5 shipped with a number of new features, including TemplateView, and SproutCore 1.6 significantly improves the stability of TemplateView, TemplateCollectionView, and their integration with other parts of the system, especially DataStore.

If you are using SproutCore 1.5 today, you should upgrade to SproutCore 1.6 beta. It is essentially the same as SproutCore 1.5 with a large number of bugfixes and stability/efficiency improvements.

Changes

  • Bugfixes to synchronization between SproutCore RecordArray/ManyArray/ChildArray and TemplateCollectionView
  • Moved forms to experimental framework
  • Moved routing into its own framework
  • Improved ability to use table elements in Handlebars templates
  • CSS and cross-browser fixes for built-in controls
  • Significantly cleaned up in-line documentation

SproutCore and PhoneGap

written by Colin Campbell

Making sure your apps work everywhere is an important part of any mobile strategy. The mobile web allows you to reach your users wherever they are, and users have grown to expect that you’ll be there wherever they go.

Increasingly, users want to access applications through app stores; to reach your users, you have to be available to them as many ways as possible. PhoneGap allows you to put your web applications in a native wrapper and deliver them in the Apple App Store, Android Marketplace, and many other native app stores. It also integrates really well with SproutCore, making it the natural choice.

Getting Started

PhoneGap provides both JavaScript and native code. First, let’s deal with setting up the native side. For the purposes of this post, we’ll assume you’re setting up an iOS project. You can follow the Getting Started docs on PhoneGap’s website to get a running start.

Create your PhoneGap XCode project and save it right inside your SproutCore project’s directory (the one created with you ran sc-init). Let’s assume you’ve saved your PhoneGap project to ‘iphone/'.

Integrating PhoneGap with SproutCore Projects

The JavaScript code that comes with PhoneGap allows you to communicate with the Objective-C code (in the case of iOS) running on the native side. The best way to include this JavaScript API in your SproutCore application is to create a framework and then require it in your Buildfile. In your projects directory, run the following commands:

mkdir -p frameworks/phonegap

cp ~/Documents/PhoneGapLib/javascripts/phonegap-uncompressed.js frameworks/phonegap

Then, when editing your application’s Buildfile, require the PhoneGap framework you’ve just added:

 config :all, :required => [:sproutcore, :phonegap] 

The next time you build your app, the JavaScript you’ve included in your framework will be built with your project.  Continue reading

Dispatch From The Edge: Contributing To Sproutcore

written by Greg Moeck

The recent release of 1.5 has brought many new people to SproutCore, and as our community grows, more and more people are asking how they can help. This week, instead of focusing on whats new, I’m going to focus on how you can contribute to the bleeding edge of SproutCore. I’ll start with my top three suggestions.

1. Contribute to the SproutCore Guides

Back in the beginning of January, we recognized that the biggest challenge to new users trying to learn SproutCore was the limited quality and quantity of documentation. To solve this problem the SproutCore Guides project was born. To date, 15 guides have been completed and made available to the community, drastically improving the help that is available for people. But there’s still more work that can be done.

How can you start helping?

To be able to contribute to the project, the first thing you need to do is build the guides on your own system. In order to do that, do the following:

  1. Download and install the guides package
  2. Clone the guides source from git://github.com/sproutcore/sproutguides.git (git clone git://github.com/sproutcore/sproutguides.git within the directory you want to work).
  3. cd into the cloned directory (sproutguides), and run “guides build” to generate an the output directory, where you can build the files locally.

Once you’ve set up the directory, you can modify any of the files within the source directory.

Next, run “guides generate” to see them reflected in the output. The following video illustrates a typical workflow:

If you’re interested in writing a new guide for a section of SproutCore that hasn’t yet been covered, contact Yehuda at wycats@sproutcore.com with your idea.

2. Contribute to the Source Itself

There are two ways that you can contribute to improving the code of SproutCore itself.  Continue reading