This is a Boxee app template, with useful common setup and bits, to kick-start your Boxee app development. Removing the need to go through common setup tasks and little best practice. Hopefully this will makes things quicker when creating new Boxee apps.

Features

This is a very much a work in progress and I will add useful bits as they come to mind. Feel free to add your own useful bits and submit a pull request. What’s currently in there is:

• PSD template for creating thumbnails for your apps. With sashes(implemented as layers) to identify your different app flavours within Boxee – development, staging, live.
• .gitignore file specific for Boxee development
• A prefilled descriptor.xml with common values and guidance to add the necessary customisations. Plus an example descriptor file.
• Packaging script for automating the packaging/zipping of your apps ready for deployment to your staging repository or official Boxee repository.
• First xml layout to instantly get started.

Instructions

To create a new app based on this template/boilerplate. Navigate to the Boxee apps directory in a terminal. Then run:

Code block

git clone git://github.com/tommysqueak/Boxee-Boilerplate.git developer-id.your-app-id

The developer-id should be your unique prefix for you or your company. Mine is ‘greatboxee’. The unique app id you intend to use for the app. Eg grooveshark, so the full id, and dir, would be greatboxee.grooveshark

Then open up the descriptor.xml (located in the developer-id.your-app-id directory eg greatboxee.grooveshark) in your editor of choice and fill in the blanks. Open Boxee and check it runs ok. Make a kick-ass app.

If you’re using Git for source control, rename example.gitignore to .gitignore

This is about a Rake script that will consistently package your Boxee Apps for deployment to your repositories and the official Boxee App Library.

This is based on the NAnt version I made, with some added improvements. Since I wrote the NAnt script I have moved from Windows to Mac. So the NAnt script is no longer useful and Rake means it can run multi platform.

Why Do You Need One

If you’re an agile developer, you’ll be showing your app to your client regularly, in order to get feedback and iterate. Having an automated packaging solution ensures you can package your app quickly, easily, consistently and without mistakes. By being quick and easy it lowers the barrier to deploy often.

The best way to show your app to clients is to have your own custom repository. If you don’t have one, you can still use this script to package your apps for the official Boxee App Library.

What Does it Do

It packages your app into the Boxee zip file format, for each specified repository environment. You can specify as many environments as you wish. I usually specify 2, my staging repository (which clients use to see the apps) and the official boxee repository.

In Detail

• Packages the app into a zip file, in the right structure, ready for deployment
• Strips out unwanted files (.svn, .git, thumbs.db, Eclipse projects files etc)
• Automatically removes the test-app tag
• Version management automatically increments the version of your app, embeds the version into your descriptor file and appends to packaged zip
• Keeps an audit trail of packaged apps, in case you need to go back to a deployed version
• Allows you to easily identify between the different flavours of your app in Boxee. Eg The one your developing locally, the version in the staging repository and the version in the official Boxee repository.

Why does it package the app for each environment at the same time? When the client is happy with the app that they see in your staging repo.  You can then deploy exactly the same app you have just shown them to the Boxee repo. No room for mistakes.

Packaging

Prerequisites

You can either clone the Boxee Boilerplate repo (more to come on this) if you’re starting a new app or copy the build folder to your current app directory.

You’ll need Ruby, Rake and bundler installed (gem install rake, gem install bundler) to run this script.

From a terminal run the following, to install the gems the script depends on.

Code block

cd build
bundle install

One Time Configuration

Open build/environments.yml and fill in the blanks. Give the app flavours different names or logos, so you can distinguish between them when they are listed in Boxee App Library. You can also add any other descriptor properties you want for an environment.

To Package

From a terminal:

Code block

cd build
rake

Any problems, let me know.

If you’re developing apps for a client in an agile fashion, you’ll be showing the app to the client many times as you introduce new features in order to get feedback as soon as possible. Ensuring you have a nice tight feedback loop and the right app gets built. Any kind of friction will only slow you down and perhaps even avoid deploying as often. An automated solutions works in seconds, is consistent and avoids mistakes.

To be effective at getting rapid feedback you will need 2 things:

• A custom repository to deploy your apps to, for clients to use your app and give feedback.
• A build script to automate packaging and deploying the app to your custom repository. That’s what this post is about.

I did have an automated package and deploy until API keys were introduced, so at the moment this only packages. I’m hoping to redevelop that part, if it’s possible, so I can deploy in seconds too (joy).

The Build Script

The build script packages your app into a zip file, ready for publishing to a custom repository and the official Boxee library. Your free to download the build script and use it in any type of Boxee app development you like. It’s good to go as it is without and configuration (as long as you adhere to some conventions, although it’s easy to change if you like). It uses NAnt, so Windows only I’m afraid. I’m currently transitioning to a Mac, follow greatboxee on twitter or subscribe to this blog to hear when that’s out.

Features

• Packages the app into a zip file, in the right structure, ready for deployment
• Strips out unwanted files (.svn, thumbs.db, Eclipse projects files etc)
• No need to remember to remove the test-app tag
• Version management automatically increments the version of your app, embeds the version into your descriptor file and appends to packaged zip
• Keeps an audit trail of packaged apps, in case you need to go back to a deployed version
• Easily identify the version of the app your coding, the version in the custom repository and the version in the official Boxee library

Getting it Working

Download the build script (GreatBoxee.Builds\package.build) from the Great Boxee GitHub repo and put in a folder inside your app in a folder called ‘Build’. There’s also an example app there with it working.

Create 3 descriptor files in your app root, one for each location the app will exist or be deployed to. They must have these names (conventions!).

• descriptor.xml – the version of the app that your developing in your current apps folder on your dev machine. This will have the test-app tag in it. eg App Id – greatboxee.myvids
• descriptor.beta.xml – the version of the app that will be deployed to your custom repository eg App Id – greatboxee-beta.myvids
• descriptor.prod.xml – the version of the app that will be deployed to the official Boxee repository eg App Id – myvids

You can also give the app different names or logos so you can distinguish between them, when they are listed in Boxee App Library.

Then navigate to the Build folder in a command window and execute nant package. I use a little batch file to run which is in the example app on GitHub too. This runs the packaging task in the build script and only takes a few seconds. This creates 2 zipped up apps, ready for deployment, in your build location (see build.dir property, the default will create it in your ‘Build’ folder). One is for the custom repository and one for the official Boxee library. You get 2, so when your client says “That’s fantastic, I’m happy with that make it live” you can then deploy exactly the same app you have just shown them in your custom repository. No room for mistakes in going to package the app as it stands on you dev box (or source control).

This packaging script is just a part of the puzzle that is continuous integration.With a build server you can automate the entire process (test, package, tag, deploy). Triggered by checkin into your source control or manually.

Get the Build Script