Hubbub ❤ SproutCore – Socket.IO & Modular Loading

written by Tyler Keating

As promised in my last post, I’ll go into more detail on some of the technical aspects of Hubbub. And since there was only a single request to talk about Socket.IO integration with SproutCore, that’s the topic for today. In order to keep these posts down to a nice bite-sized length, today will strictly be about how Hubbub uses SproutCore’s modular loading to include Socket.IO.

Socket.IO! I Choose You.

There is actually some nice stuff that happens in Hubbub in real time if you have the app open. For example, if someone sends you a message, signs out an item to you, makes a new item available, or any number of other events occur, then the application updates instantly without requiring a page reload. Sure it’s not new, but with Socket.IO and SproutCore it’s also not a difficult-to-implement kludge.

So for those that haven’t yet tried it, Socket.IO is available here. There are really good instructions on using Socket.IO on their site, but it’s so simple I will include my entire setup here.

My Setup – Server Side

Hubbub’s app server is written with Node and Express. So after installing Socket.IO, there’s nothing more to getting it working server-side than:

app = require('express').createServer({key:, cert:, ca:});
io = require('socket.io').listen(app);
app.listen(3443);

Note: I use port 3443 locally with TLS/SSL encryption, which is not strictly necessary. Continue reading

Hubbub ❤ SproutCore – Introduction

written by Tyler Keating

I was recently asked to do a write-up about my SproutCore app, Hubbub (@hubbubapp), as a general anecdotal guide to those interested in writing large scale applications in SproutCore for the first time.

I’m afraid this first post won’t be very technical, but I will at least attempt to make it an enjoyable read, and to tell you about some of my early bumps in the road so that you can avoid them. My overview of Hubbub will also span a few posts, so if you have particular questions, I can spend some time on them in future.

What’s all the Hubbub?

This isn’t the place to talk up the app itself, only how it operates, so i’ll just give you the briefest of descriptions now to help set the stage.

The premise for Hubbub is that we still live in the physical world; that we all have real families, real friends and real coworkers and that we also all have a lot of real stuff. Hubbub is a companion app for our real lives, helping us keep track of our real stuff and helping us share with our real friends and neighbours.  So with that idea in mind, let me present to you the development history.

Uh, but I don’t remember much about writing Hubbub.

It’s true, but not in the drunken orgy of code way that you’re imagining (calm yourself!). It’s just that Hubbub was written entirely in my spare time, evenings and weekends, going back over a year, which means my brain has jetissoned a lot of those early efforts to make space for everything I’ve learned since then (and to not lose the essentials, like using a spoon, my kids’ names and the order of pants vs. underwear).
Continue reading

Structuring Your SproutCore Application: Part 2

written by Colin Campbell

In Part 1, we started developing a Contact application for managing groups and people. Continuing with Part 2, we’re going to be implementing the application’s functionality in a way that’s going to scale with its complexity.

Loading The Application’s Data

Now that we have the base of our application, we need to start by loading some data into the application. Before we proceed, let’s make sure we’re on the same page. Check out step 4:

	git checkout step4

We’re going to do this using `SC.FixturesDataSource`. It allows you to use fixture data local to your application, but also simulates remote responses. That means when you implement a connection to a remote server, your application works as expected. Let’s create the FixturesDataSource in `apps/contact/data_sources/fixtures.js`:

1
2
3
4
	Contact.FixturesDataSource = SC.FixturesDataSource.extend({
	  simulateRemoteResponse: YES,
	  latency: 250
	});

We’ve defined a new FixturesDataSource class, turned on the simulation of remote responses, and set the latency to 250ms. This is a typical amount of latency between a client and a server but you can tweak this number to suit your needs.
Continue reading

Structuring Your SproutCore Application: Part 1

written by Colin Campbell

This is the first in a series of posts that recap Colin’s talk at the San Francisco Meetup 6/14 and go into some detail about structuring a SproutCore application. Stay tuned for more posts in this series, and, as always, we’re listening to your feedback– let us know where you’re confused or what you want to learn more about.


Building applications that scale well is very important, but “scaling well” isn’t limited to ensuring your servers can handle the load. It is equally important to structure your application so that you can easily maintain your code and introduce new functionality without needing to rewrite significant portions. There are libraries provided by SproutCore, like the statechart library, that will help your application grow smoothly.

Let’s dive into how to structure your SproutCore application so that it’s maintainable and can grow with your project. In Part 1, I’ll be covering how to set up your application so that you will be able to add functionality later with minimal refactoring.

Introduction

We’ll be going through an application I built for the SproutCore San Francisco Meetup earlier this month. It is available on Github.

To get started, let’s generate the application using the following command:

sc-init Contact --template

As you can see, we’ve named our application `Contact` and we’re choosing to use the new HTML-based application structure. We’re going to be developing this SproutCore 1.6 application so that we can upgrade it to the SproutCore 2.0 stream eventually. That means using `SC.TemplateView` for all of our content views, and limiting our usage of other views that rely on layout.
Continue reading

SproutCore Baby Steps for OS X

written by Tyler Keating

With the recent release of SproutCore 1.5, it seems like the perfect time for a “Getting Started With SproutCore” refresher. Whether you’re tired of trying to get the benefits of client-side code execution into your server-side apps, or whether you’re tired of trying to get the benefits of multiple platform support into your client-side apps, there’s no better time to give SproutCore a try.

This post will walk you through the very first steps you need to get up and running. It assumes you’re using OS X and have at least some basic familiarity with the command line (come on, it’s not so bad!).

Installation

Installation has been getting simpler and simpler, and the team is working on making this even simpler in the coming releases of SproutCore. Subscribe to the RSS feed to be notified of new posts on the blog; I’ll be sure to post an update once things change.

So let’s get into it; I’ll work my way from the bottom layers on up.

Step 1. Install the Xcode Developer Tools

You’ll need the Xcode Developer Tools to compile some of the RubyGems that the build tools depend on. The appropriate version of Xcode for your current version of OS X should have been included in your install DVD. If not, or if you’ve long-since lost the packaging from your machine, you can get a free copy of Xcode 3.2.6 by signing up for an Apple Developer account. Alternatively, you can buy Xcode from the Mac App Store for $4.99.

Follow the instructions for whichever install path you choose, and report back here when you’re done.


Continue reading

Introducing SC.TemplateView – Now With Tutorial

written by Tom Dale & Yehuda Katz

Yesterday, we released an updated version of the SproutCore 1.5 prerelease gem that contains our preliminary work on Amber and SC.TemplateView.

To us, Amber means significantly reducing the cognitive overhead of picking up SproutCore for the first time. A big part of that is leveraging technology that web developers already know: HTML and CSS. We’ve heard from developers in the past who said they loved SproutCore’s observers and bindings but were intimidated by the complexity of its view layer.

Part of easing developers into SproutCore means having the best documentation on the planet. Over the past month, contributors have done a kick-ass job of populating the SproutCore Guides site with up-to-date and easy-to-follow material. We wanted to provide a similar experience for SC.TemplateView, so we’ve written a hands-on guide to using it to build a simple (but still fully-featured) todo application.

You can find the guide at http://guides.sproutcore.com/html_based.html. It takes you through the process of initializing a new project, defining your models, designing your views, and then tying them all together with controllers and bindings. You can also check out the finished product at https://github.com/sproutcore/Todos-Example.

We think that describing the flow of data in your application, then allowing the framework to put the pieces together for you, leads to robust, maintainable applications. In fact, we think this declarative structure is the only way to build web applications that truly scale beyond simplistic demos like this one. We plan to create a second iteration of this app that really shows off how well the declarative model allows you to manage increasing complexity. But for now, we think you’ll be blown away at how features begin to emerge, almost like magic. By paying a small upfront cost, you begin to get functionality for free.

Continue reading