Dispatch From The Edge: Blacklists and Whitelists

written by gmoeck

The “true edge” of SproutCore nowadays is primarily the 2.0 branch, where the new and fresh is continually appearing. However that doesn’t mean that the 1.x branch has been forsaken, or forgotten. The 1.7 beta release has some pretty cool features that allow you to improve the performance of your application. What I want to focus on today is how to use a blacklist or whitelist with the 1.x build tools.

One of the biggest knocks against SproutCore 1.x is that it is a “big, monolithic framework”. You end up pulling in more than you’re ever going to use or need. This is a problem, particularly in a JavaScript context, because it increases the size of the file that needs to be sent down from your server, and then parsed by the browser. Particularly in a mobile context, this can be a serious performance drain.

Enter the SproutCore whitelist/blacklist. If there is a section of SproutCore 1.x that you’re not using inside of your application, you can use either a whitelist or a blacklist to tell the build tools not to include that code in the final packaged version of your application’s JavaScript. So for example, if my application is not using collection view, I could create a file called Blacklist inside of the root of my file directory, and put the following into it to exclude collection view:

{ "/sproutcore/desktop": "views/collection.js" }

“/sproutcore/desktop” is the “target” for the build tools, which you can think of as basically the framework to target. Then, “views/collection.js” which is the “rule” for the build tools. If the list is a whitelist, then the rule would mean to include the file in the final build, whereas if the list is a blacklist, then the rule would exclude that file. So in this case, “/sproutcore/desktop”: “views/collection.js” tells the build tools to exclude the file “views/collection.js” from the desktop framework.

So if you have a 1.x app and you’re looking to improve the initial load time of your app, I would create a blacklist for your application, and go file by file seeing what you can exclude from the framework. Happy optimizing.

Localization in SproutCore 1.6

written by pbergstr

Why Should I Care About Localization and Internationalization?

When developing applications, localization and internationalization are things that are easily overlooked and forgotten until the very end. In the case of smaller applications, they are targeted to only one language, and not having to account for localization or internationalization might work out in the end.

However, especially for larger applications or applications that are targeted to several international markets, planning and implementing an application with localization and internationalization is extremely important. Without proper planning, you can get into a lot of trouble that could have been alleviated with very little upfront effort. The type of planning you’ll need to do is what we’ll go over in this in this post.

Factor in localization early in your development cycle!

As a developer, you should plan for localization and internationalization early in your development cycle, when it is easy to deal with. Once an application grows too large, it is very difficult to add localizable strings.

If you develop without taking into account localization, often text winds up hard coded and, as with any application, these strings are found in a million different places. Having to track down all the non-localized strings after the fact is time consuming and unnecessary if accounted for earlier in the project.

Localizing Your Apps with SproutCore

SproutCore makes it easy to localize your application. Using a strings table for each language, developers can enter key-value pairs. These keys are generic and are referenced throughout the application.

When the application runs, instead of using the actual string in the view, SproutCore looks up the correct localized value from the strings table. This makes it easy not only to localize the application, but also to manage all of the strings in your application because they are all located in one place. If you need to finalize the strings, you can send that off to be finalized without having the stakeholders know any JavaScript. However, there are more things to localize than just strings. For each language or locale, you can have a sub-directory that contains not only your strings file, but also other resources such as images, CSS, and HTML templates. We’ll go into more detail how to properly set up your application for localization in the next section.

Set Up Your Application for Localization

Now that you’re thinking about localization, how do you go about setting up an application to be localized? There are some things that will need to be expanded upon from the normal directory structure that you are familiar with.

The directory structure

The first thing to go over is the general structure of a SproutCore application as it is normally presented when you create a basic app. Below is the directory structure for an application, MyApp, that contains an image, myapp_logo.png inside of the resources directory that contains some English text, and the normal en directory with CSS and a strings file. Most of time the, the strings file will be empty because the developer hasn’t considered localization.

apps/
   myapp/
      core.js
      en/
         strings.js
         myapp.css
      main.js
      resources/
         images/
            myapp_logo.png

However, this is not very localizable. Let’s say that we also want the application to be available in German. In this case, we’ll have to readjust the directory structure a bit.

First, the image in the case has some text that needs to be in German. Second, there is some CSS layout that needs to be readjusted for the really long German words. Third, and most important, there are a lot of strings that need to be translated, so we need to create a strings file.

apps/
   myapp/
      core.js
      en/
         strings.js
         myapp.css
         images/
            myapp_logo.png
      de/
         strings.js
         myapp.css
         images/
            myapp_logo.png
      main.js

In this structure, when you run the application in English, only the contents of the “en” directory will be loaded and vice versa for German. Therefore, you can optimize the code loaded for the specific language.

About Those Language Codes

The language codes that are used in a SproutCore application are standard internationally recognized language codes in the format: ‘language_REGION or just ‘language’. For instance, if you want to localize your application into British English and American English, you would have two localizable directories: en_US and en_UK.

The strings.js File

At the heart of the localization system that SproutCore provides is the strings file. Each language has its own file in its respective language directory. It is important to note that only the strings file in the language that you’re running will be loaded for any given language when the application runs.

Basically, the string file is a lookup table for a string key, which you reference in your application code, and a string value, which is the corresponding localized string for the key.

The strings file has a specific format that you will need to follow:

SC.StringsFor('en_US', {
	'key': 'value'
});

Localizing Your Application

Now that you have everything set up, you can write your localizable application. Whenever you create a view element using either a SC.View or a SC.TemplateView, it is likely that you will need some text to go with it.

Instead of putting in some hardcoded text, even if it is temporary, you should create a key and add that to your view element and a corresponding value in your strings file, regardless if it is final or not.

What is the Best Practice to Create a String Key-Value Pair?

There isn’t a hard and fast rule on how to create a string key, but as long as you come up with a consistent formula, it will work out in the end. One way to do it is to refer to the path of the view inside your application.

For example, if you have a list view in the application that has items with a title, you could name the string key something like MyApp.List.Item.Title. While this seems verbose, any developer who looks at your view will know what the key stands in for.

Another tip is that if a string is not finalized, you should make it stand out clearly in the UI until it is finalized. One way to do so is to precede it with an underscore: _MyApp is a great way search for beanie babies. Once that string is approved by the stakeholders, you can easily remove the underscore.

Localization in SC.Views

Several of the built-in SproutCore SC.Views have support for localization. for example, you can pass in localization string key into a SC.LabelView:

MyApp.TitleLabel = SC.LabelView.extend({
	localize: YES,
	value: "MyApp.TitleLabel"
});

Using the .loc() Function for Computed Strings

To understand how to do more complex localizations with passed-in properties, it is important to know how the .loc() function operates. In many cases it is run for you by SproutCore, but there are cases where you want to do something more dynamic.

The .loc() function takes optional parameters like the .fmt() function. For example, let’s say that you have a computed property on a customized SC.TemplateView that represents a list item. You want this list item to be more dynamic, showing a localized string with some parameters; note that the order of the parameters may be different in different languages.

The key-value pair is the following: “MyApp.List.Item.Title”: “%@1 employees working for %@2”

list_item.js view:

	MyApp.ListItem = SC.TemplateView.extend({
		templateName: 'list_item',
		localizedTitle: function() {
			var content = this.get('content'), ret = '';
			if(content) {
				ret = "MyApp.List.Item.Title".loc(content.get('employeeCount'), content.get('managerName'));
			}
			return ret;
		}.property('*content.employeeCount', '*content.managerName').cacheable()
	});

list_item.handlebars template:

{{localizedTitle}}

Now, the computed ‘localizedTitle’ property will be used inside of the template and properly format for any language.

Localizing Simple Values in Templates

In SC.TemplateView templates, there is a handlebars helper that allows you to easily localize strings without having to use a computed property. Computed properties only need to be be used if there are complex properties. In the case of a simple static string, you can use the ‘loc’ helper in the handlebars template directly.

{{loc "MyApp.Path.To.Loc.String"}}

Conclusion

SproutCore provides a powerful way to localize your application into as many languages as you need. The main takeaway from this post should be that if your application might support multiple languages, plan ahead and do the right thing early on. If you don’t, it will be difficult to retrofit your existing application to support localization.

SproutCore 1.7 Beta Released

written by pwagenet

I’m pleased to announce that SproutCore 1.7 beta is now available. This release is largely a bug fix release and the addition of some minor features so if you’re using 1.6 and like the cutting edge you should check it out. Installers are available for Mac and Windows. If you’re using RubyGems, just run gem install sproutcore --pre. A word of warning, however: if you’re using the installers the beta will overwrite any previously installed versions of SproutCore. As always, share any issues you encounter on Github Issues.

Read on for more information on the changes.

In the framework itself changes include:

  • Safari Lion browser detection.

  • Speed improvements

  • Flag to stop PickerPane repositioning when resizing the window

  • Option to enable or disable overflow in SegmentedView

  • Support for autoCorrect and autoCapitalize in TextFields

  • Minor improvements in SC.Statechart

  • New SC globals to provide information like build mode, build number and locale.

  • Lots of bug fixes

New features in the build tools include:

  • When a stylesheet hits the 4096 CSS selectors limit in IE , the files will now be automatically split.

  • Sprites are optimized to use less space

  • Layout.js, which includes location metrics, will be always first when building the js files

  • Added security feature for dev environment. By default sc-server can only be used from your local machine unless you set a flag.

Along with the following bug fixes:

  • Sprites are again the default for abbot due to performance issues with data-uris in some browsers

  • index.html will be minified again

  • Whitelist and black list fixes

  • Fixed iOS retina display styling

For a full list of all changes see the Changelogs: Framework and Build Tools.

Video from the August South Bay Meetup

written by mdouglas

Thanks to all of you who came out to our first meetup in the South Bay, at at Nokia HQ in Sunnyvale! For those of you who couldn’t make it, don’t worry; as always, we made sure to record everything for you.

It was quite the night— we heard presentations from Majd Taby and Greg Moeck, followed by community Q&A.; Majd started us off with a talk on how bindings help SproutCore make your application smaller, concluding with an impressive demo of his work on SproutCore Touch and TransformJS. Greg spoke about connecting SproutCore apps to your backend, and best-practice approaches based on your app’s structure.

Check out the videos below! Many thanks again to our friends at Nokia, who recorded the talks— note the improved video quality :P — and kept everyone happily fed with pizza, cookies, and refreshments for the night.

Hope to see everyone at the September meetup, back in San Francisco at Twitter!

Hubbub ❤ SproutCore - Introduction

written by tkeating

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). Typically, it won’t take so long to write an application, but I switched careers and postponed the app for several months, only recently picking it up again and releasing the beta. Hopefully the cathartic process of writing will shake loose a few of those early memories for you (or else you may find me wearing my underwear on the outside with a spoon stuck up my nose yelling at… uh, Morticent?).

So enough excuses, at least I should begin with an answer to:

Why SproutCore?

That’s easy. Like you, I knew right from the start that I wanted my app to be used by every person in the world, which meant it had to be on all the varied devices, which meant writing versions for iPhone/iPod Touch, iPad, Mac OS, Windows OS, Android Phone, Android Tablet, Blackberry Phone, Blackberry Playbook, Windows Phone, Linux OS, Web OS and…  stop!  I’m not a lunatic!  Of course I was going to build Hubbub as an application for the one decent common environment, the browser! In fact, I just can’t imagine building any application these days not as a “web application”1, other than perhaps writing a money-grubbin’ iPhone game.

So yes, a web application; but why a SproutCore web application? Why not a Ruby-on-Rails, Cappuccino or micro-Frankenstein app for example? That’s also easy. I have a preternatural knack for spotting winners.

Well, I did feel immediately that SproutCore was going to be the future for writing applications, but I’ll admit that there was a bit more to it than that.  For instance, I knew that I wanted to write a large-scale application (MVC, localizations, bindings, etc.), which excluded all of the smaller client-side frameworks that were going to leave me hanging after my app grew, and I knew that I wanted the application to be super fast and work offline, which excluded all of the server-side frameworks. Thus it came down to Cappuccino vs. SproutCore. I came from a background of writing Mac and iOS apps, so Cappuccino was appealing… but oh, Apple uses SproutCore. Oh, okay, sure why not.

The Company Line

Now, I realize “Tyler’s gut feeling” isn’t as compelling an argument for your VP of Engineering as it should be, but the only words I’ve ever found compelling have followed an action, not preceded it. I’m not going to waste time formulating theories that SproutCore’s apples are better than framework X’s oranges, but leave you to just look at the existing SproutCore apps like those from Eloqua and Apple and try and argue that they are not a higher class of web application.

For my part, my action is Hubbub, which I built entirely on my own, which means that that also is possible, which means imagine what you can do with a team and money and talent!

For a more scientific approach to choosing SproutCore, you can also read the excellent posts by Evin Grano and Majd Taby, How do you really build large impressive web applications? and When To Use SproutCore, and When Not To respectively.  Now back again to Hubbub ❤ SproutCore.

Standing on the Shoulders of People of Prodigious Size and Strength and Possible Gland Issues

I do recall that when I started with SproutCore, I made amazing progress at an amazing pace.  I also made amazing mistakes.  But those mistakes didn’t yet matter as I kept going forward and was also myself amazed time and time again at how little code did such big things.

SproutCore really does contain such a wealth of good ideas that you can simply turn them on as you go for quite a while. But then, eventually, your app will be big and you’ll need to do something no one else thought of before. I know when I hit that wall, it was a bit of a challenge.

The first truth to accept is that SproutCore is open source and so if no one has had your particular itch, then it’s up to you to scratch it.  The second truth to accept is that reading the source is the best way to learn how to use the framework as well as to extend it.

Back to those early mistakes. I recall that I refactored several times. In particular, moving to Statecharts was a big refactor and getting comfortable with the Datastore took a few attempts; so I would recommend that you work hard to understand and use these tools right from the start.  I can confirm that they work very well in concert with an extremely complicated UI and data layer.

The other mistake that I made was moving too quickly in some instances, so that I needed to basically go back and rethink large chunks of code.  Which brings me to the third truth, there are no shortcuts to good code, no matter what framework you use.  So now may be a good time for you to read carefully Colin Campbell’s thoughts on application structure.

Another major mistake I made was not to understand observers and bindings well enough and so I ended up often using the wrong tool for the job and creating unnecessarily complex dependency chains. This both hurt performance and was unwieldy to maintain.

Tune in Next Time

So, with that high level introduction to my experience with SproutCore out of the way, in my next post, Hubbub ❤ SproutCore - Getting My Feet Wet Behind the Ears (working title), I will describe in further detail the entire architecture of Hubbub, from the MongoDB database and Node.js server of the backend to the carefully tuned SproutCore 1.6 application on the client-side.

There is actually a lot that can be covered, such as:

  • the format of the JSON API that I use to communicate between the client and server

  • the inclusion of third party libraries like Google maps, Socket.io and Raphaël

  • how Statecharts manage the application flow

  • how I coordinate state changes to smooth out animations

  • or even my process of doing a Hubbub build and deploy.

So be sure to indicate if any of that is interesting and I’ll dedicate more space to it.

Thanks for making it to the end, you’re awesome!

  1. Wait! “web application”, like “native application”, is a loaded term. If you think that Hubbub isn’t complex software like any other complex software on your device you’re wrong.  If you think that it won’t be available in the iTunes App Store, Android App Store, Mac App Store, etc., then you’re not thinking very big. Why wouldn’t I embed the Hubbub code and launch it in the stores? I will! Just give me a couple minutes, I mean I have to finish this post and the follow-up posts and we just had another baby and I’ve got a full time job and it’s summer time, and come on!