Things at litl have been busy and exciting these past few months. After winning the multiscreen award at Adobe MAX in October, we've been focused on securing markets for our existing webbook device and the TV set top box prototype. In our search for the ideal market to sell devices and promote developer apps, we've found our webbook has already struck a chord with several groups of users - particularly those looking for simplicity in everyday computing. And it makes sense. We've made photo sharing a snap, accessing the web as simple as possible, and turned Facebook into a relaxing and entertaining experience.

Our company has decided to focus on delivering more experiences and devices to markets where simple computing is essential. This strategy will affect our existing developer community efforts in a few ways:

1. As most platforms continue to do, we will no longer be looking for any-and-all apps from developers. In the coming months, we will assemble a specific list of apps based on core values of simple computing. We will work with industry experts, content and service providers, as well as developers to cultivate the very best applications for our users. This will allow us to focus platform SDK features and support on apps that bring the most valuable experience to our users.

2. Access to the litl SDK will be limited to only developers who have been approved to work with us on apps for our newly focused markets. If you are an existing registered developer, you will be among the first to be invited to re-join our community once everything is set in place. If you have been working on a litl app (also known as a Channel), we will be announcing details on a final submission date soon. Developers that formerly submitted apps for review by our Feb 14 deadline, as part of our MAX incentive program, will have their apps reviewed and be rewarded accordingly.

3. We are taking steps to dramatically increase our platform's distribution in key markets. Developers will find renewed opportunity as we ship devices to new users that we expect will purchase apps to further simplify their computing experience. We hope to create new incentive programs around these opportunities to help meet the demand of apps on our platform.

We have a great opportunity to continue improving the way people of all ages use technology and, our focus in strategy will help solidify our platform as the perfect launchpad for valuable applications for users looking to us for simple computing.

What is an Accelerometer?
An accelerometer is a piece of hardware that measures the acceleration of forces. There are two types of forces that we care about; static and dynamic. You can think of static force as gravity which at all times is pulling us towards the center of the earth. We use static acceleration to figure out the angle an object is tilted. Dynamic acceleration is used for measuring the actual motion of an object. For this intro we’ll be talking mostly about tilt-based static acceleration.

Common uses
There are accelerometers all around us from our cars to our computers and phones. In cars they use accelerometer data to determine vibrations on the engine and in the airbag sensors. Companies also use accelerometers in hard-drives to protect data during collisions and general impact. Nintendo Wii shaped the future of motion gaming adding an accelerometer to their remote. Whenever you see a labyrinth style game or are playing a driving game by tilting your phone or tablet you can thank the accelerometer. As developers it’s our job to learn and interpret this information in order to improve the experience to our users.

How to handle local accelerometer on mobile device
When you are writing flash application that will handle local accelerometer updates from a phone or tablet the work flow is very simple. You check the to see if the device supports accelerometer using the flash.sensors.Accelerometer.isSupported() method. If it is supported you register a few event listeners, then handle the updates when they come in.

if (Accelerometer.isSupported) {
		accelerometer = new Accelerometer();
		accelerometer.addEventListener(AccelerometerEvent.UPDATE, accUpdateHandler);
}

private final function accUpdateHandler(event:AccelerometerEvent):void {
	xSpeed -= event.accelerationX;
	ySpeed += event.accelerationY;
}

How to handle accelerometer data from litl os remotes
When you are dealing with multiple remotes connected to a single application things get a bit more complicated because you need to pair remote updates with specific remotes, manage connections, and not mix it up in the meantime. This is an approach that works for us. It involves the creation of three classes by the developer.

LitlRemoteManager()
We will need to extend RemoteHandlerManager in order to inherit functionality. By doing this now we can override two important methods; onRemoteConnected and onRemoteDisconnected. You can do whatever you want inside these methods knowing that they’ll be called when a remote connects/disconnects.

You will need to instantiate after you are connected to the LitlService() as you will need to pass a reference to your service into it’s constructor. You will also need to instantiate a new RemoteFactory() in the constructor. This is what it looks like in our instantiation:

private function createRemoteManager():void {
	remoteManager = new LitlRemoteManager(_service, new RemoteFactory());
}

RemoteFactory()
Implement IRemoteFactory(), return RemoteHandler() and you are all set. I usually set this up once and barely look at it again.

package service
{
    import com.litl.helpers.richinput.remotehandler.IRemoteHandler;
    import com.litl.helpers.richinput.remotehandler.IRemoteHandlerFactory;

    public class RemoteFactory implements IRemoteHandlerFactory
    {
        public function RemoteFactory() {
        }

        public function createHandler():IRemoteHandler {
            return new RemoteHandler();
        }

        public function get klass():Class {
            return RemoteHandler;
        }
    }
}

RemoteHandler()
We have one job left to do and RemoteHandler() keeps it simple and to the point. This is where we define what to do when we get accelerometer updates. Start by extending AccelerometerEventHandler() and implement IRemoteHandler(). Next, override onAccelerometerEvent and handle your logic to handle accelerometer data. I usually loop through an array of remotes/players in my model and reference the remoteID property to match up remotes.

package service
{
    import com.litl.helpers.richinput.remotehandler.AccelerometerRemoteHandler;
    import com.litl.helpers.richinput.remotehandler.IRemoteHandler;
    import com.litl.sdk.event.AccelerometerEvent;

    public class RemoteHandler extends AccelerometerRemoteHandler implements IRemoteHandler
    {
	public var xSpeed:Number = 0;
	public var ySpeed:Number = 0;

        public function RemoteHandler() {
            super();
        }

        override protected function onAccelerometerEvent(event:AccelerometerEvent):void {
	    xSpeed -= event.accelerationX;
    	    ySpeed += event.accelerationY;
        }
    }
}

Wrapping up
As you can see there are not too many differences between the two workflows. Check back soon as we'll be posting more advanced accelerometer development articles, tutorials, tips and tricks!

Overscan is extra image area around the four edges of a video image that may not be seen reliably by the viewer. It exists because television sets in the 1930s through 1970s were highly variable in how the video image was framed within the cathode ray tube (CRT).
source: Wikipedia

Simply put, overscan is about 5% (this will vary depending on TV size/manufacturer) of your content that will be cropped when put on a tv screen. If you crop an image and blow it up to the original size, you would be overscanning. If you are familiar with print, this process is similar to “bleeding”. Consider the example below.

The reason overscan exists is because of older CRT TV’s where the tube couldn’t produce quality images on the edge of the tube. In order to effectively deal with poor quality on the edges of tubes, TV manufacturers made tubes larger and hid the part that was blurry behind the TV casing, essentially cropping a portion of the image.

Look at the black bar of meta-data at the top of the screen

Check out the green line on the left of the screen.

Okay, I know what you’re saying, “So what; who still uses CRT anyway? Why am I still being affected by this?”, but the short of it is that over the years broadcast companies have been using this “cropped” area to send meta information over analog signals. Also, since they expect it to be cropped, there is less time polishing the content available on the edges of the screen. This is the reason that even modern TV’s overscan.

Tell me litl makes it easier?

We sure do! Now that you know all about overscan, know that we handle everything for you so you don’t need to actually do anything different! Continue to use liquid layouts (based off percentages) and set view & view sizes by listening for the ViewChangeEvent on your litl service. In that event you will find the full viewing area for your TV screen.

Check out this sample code.

ViewManager.as

package com.litl.overscan
{
    import com.litl.sdk.enum.View;
    import com.litl.sdk.message.InitializeMessage;
    import com.litl.sdk.message.ViewChangeMessage;
    import com.litl.sdk.service.LitlService;

    import flash.display.Sprite;
    import flash.utils.Dictionary;

    public class LitlViewManager extends Sprite
    {
        private var _service:LitlService;
        private var _currentViewState:String;

        protected var _view:Sprite;
        protected var controller:GameController = GameController.getInstance();
        protected var currentView:ViewBase;
        protected var views:Dictionary;

        public function LitlViewManager(view:Sprite) {
            _view = view;
            views = new Dictionary();
        }

        protected function setView(e:ViewChangeMessage):void {
            // Remove the current view from the display list.
            if (currentView && contains(currentView)) {
                removeChild(currentView);
            }

            if (views == null)
                views = new Dictionary(false);

            currentView = views[e.view] as ViewBase;

            switch (e.view) {
                default:
                    throw new Error("Unknown view state");
                    break;

                case View.CHANNEL:

                    if (currentView == null)
                        currentView = new ChannelView(_service);
                    _currentViewState = View.CHANNEL;
                    break;
                case View.FOCUS:

                    if (currentView == null)
                        currentView = new ChannelView(_service);
                    _currentViewState = View.CHANNEL;
                    break;
                case View.CARD:

                    if (currentView == null)
                        currentView = new CardView();
                    _currentViewState = View.CARD;
                    break;
            }

            views[e.view] = currentView;
            controller.currentView = currentView;

// IMPORTANT -- This is where we update the size of the display object
//                           based on the dimensions returned by our ViewChangeEvent

// NOTE  -- If you extend ViewBase from our SDK rather than sprite, you will have
//                 access to the setSize() method
            currentView.setSize(e.width, e.height);

            if (!contains(currentView))
                addChild(currentView);
        }

        public function set service(value:LitlService):void {
            _service = value;
            _service.addEventListener(ViewChangeMessage.VIEW_CHANGE, setView);
        }

        public function get currentViewState():String {
            return _currentViewState;
        }

    }
}

ChannelView.as

package com.litl.marbelmayhem.views
{
    import flash.display.Shape;
    import flash.display.Sprite;
    import flash.display.StageAlign;
    import flash.events.Event;
    import flash.net.URLRequest;
    import flash.text.TextField;
    import flash.text.TextFieldAutoSize;
    import flash.text.TextFormat;

    public class Scoreboard extends ViewBase
    {
        private var background:Sprite;
        private var timeBG:Bitmap;
        private var logo:Bitmap;
        private var timeDisplay:TextField;

        public function Scoreboard(e:ViewBase) {
            super();
            _view = e;
            init();
        }

        private function init():void {
            createChildren();
        }

// NOTE -- This is where we instantiate our objects and add them to memory
        private function createChildren():void {
            background = new Sprite();
            background.graphics.beginFill(0x333333);
            background.graphics.drawRect(0, 0, 1280, 800 * .15);
            addChild(background);

            logo = gameAssets.logoBitmap;
            logo.cacheAsBitmap = true;
            addChild(logo);

            timeBG = gameAssets.timeBGBitmap;
            timeBG.cacheAsBitmap = true;
            addChild(timeBG);

            var timeFormat:TextFormat = new TextFormat();
            timeFormat.font = "Calibri";
            timeFormat.size = 34;
            timeFormat.color = 0x000000;

            timeDisplay = new TextField();
            timeDisplay.autoSize = TextFieldAutoSize.LEFT;
            timeDisplay.defaultTextFormat = timeFormat;
            timeDisplay.setTextFormat(timeFormat);
            addChild(timeDisplay);
        }

// Note -- The sizeUpdated() is part of ViewBase and called when the setSize() is called.
//               This means that whenever our size changes the objects on our stage will
//               reset.  Notice how they are set using percentages (get liquid baby!)
        override protected function sizeUpdated():void {
            logo.x = this.width * .10;
            logo.y = (background.height / 2) - (logo.height / 2);

            timeBG.x = (this.width / 2) - (timeBG.width / 2);
            timeBG.y = (background.height / 2) - (timeBG.height / 2);

            timeDisplay.x = (timeBG.x + (timeBG.width / 2)) - (timeDisplay.width / 2);
            timeDisplay.y = (timeBG.y + (timeBG.height / 2)) - (timeBG.height / 2) + 5;
        }
    }
}

Be prepared to get your hands dirty on Thursday, 11/11 at 1:00 during the RIAUnleashed workshop. Kathryn Rotondo and Ryan Canulla will teach and guide you through the latest litl technology, including our updated Channel SDK, new AIR simulator and exciting Android-remote controlled Accelerometer features. We’ll hand out USB sticks with the latest litl bits and Chuck Freedman will be serving as Teaching assistant to help you during the workshop.

We are happy to announce that our special developer incentive program, which awards each developer that submits a channel both $500 and a free litl TV Companion device, will be extended to those attending the workshop.

Lastly, while those in attendance at the RIAunleashed workshop will get to bask in the brilliance of our presenters, we are streaming our workshop to our developer community via a LIVE webinar.

So, whether attending in person, or looking to get a limited seat for the LIVE webinar, please sign up here:

More details on the workshop:This lab is a great opportunity for developers interested in deploying Flash/Flex Channels on the litl platform. We'll have a good portion of our team on hand to work directly with you, doing a live walk through of our devices, platform, FAQs and sample channel code. The sample channel code projects are ready to import into either Flash CS5 or FlashBuilder, so they're ready-to-run. After introducing you to the devices, SDK and platform, we'll help you code your own channels and set you up to deploy them in our Channel store!

adobe max 2010 multiscreen awards from kathryn rotondo on Vimeo.

yay! tonight we (litl channels) won the multiscreen category at the adobe max 2010 awards, presented by william shatner. it is a wonderful acknowledgement that our work in the digital home space is relevant at a time when more and more phones and set-top boxes are clamoring for attention. i hope this recognition will encourage developers to stop by our booth outside the FITC unconference in the community pavilion, learn about our platform and forthcoming tv companion product, dream up awesome channel ideas and join our open developer community to bring them to life.

This will be my 5th MAX, and by far, the busiest and most exciting. Here’s the many ways you can see me and our awesome team from litl in action during MAX 2010 in LA. My theme is Back to the Future. Read on and you’ll see why:

See you in LA from one awesome MAX!

i also have the pleasure of returning to RIA unleashed, where i’ll resume my regularly scheduled program: presenting about litlOS development with my colleague, ryan canulla.

litl lab
This lab is a great opportunity for developers interested in deploying Flash/Flex Channels on the litl platform. We’ll have a good portion of our team on hand to work directly with you, doing a live walk through of our devices, platform, FAQs and sample channel code. The sample channel code projects are ready to import into either Flash CS5 or FlashBuilder, so they’re ready-to-run. After introducing you to the devices, SDK and platform, we’ll help you code your own channels and set you up to deploy them in our Channel store!

Time: 8:30 AM – noon
Date: Thursday, November 11

i’m really looking forward to helping developers get their channel ideas off the ground.  organized by adobe’s brian rinaldi, RIA unleashed packs a lot of developer power into a completely affordable two-day conference.  if you’re local and you haven’t registered yet, what are you waiting for?

During a recent Seattle Flex user group I had the honor of presenting at, Adobe’s Marty Mickelson (TheFlexGuy) took some awesome photos of me demonstrating some of the amazing technology Litl is unveiling in the coming weeks!

In this photo, I am showing the new Touch and Accelerometer remote (that’s my hand holding the real thing at the Litl offices in Boston). This remote will ship with the set top box, and our SDK has been updated to receive touch and accelerometer events from it. You can see it in its open form, with the full keyboard and special Litl buttons available. The actual set top box device has a powerful chipset (not mobile) to support everything Flash can do, including 3D:

This is me playing a multiplayer, 3D game prototype (based on Away3D’s Mario example) with the prestigious Nate Beck. We are both controlling Litl channel content with our own Android devices through the Litl AIR-based Simulator. You will be able to build Acceleroemter based Flash games for the TV with our SDK and Simulator. The Android control feature will let you build and test games without the device:

You can get early access to this technology by signing up here:

http://www.surveymonkey.com/s/YLFTTXX

Be sure to visit us at the FITC Unconference at MAX where Litl is sponsoring free beer.
See me or anyone from the Litl team for a full demo of the new technology and device.
The new SDK will be available for public download at MAX.
We are working on contests, incentives and more exciting details for MAX.
Can’t wait to see you in LA later this month with some awesome technology!

i’m really looking forward to the end of this month, when i’ll be travelling to adobe max in LA. litl is sponsoring the beer at the FITC unconference, where i’ll be presenting the following session:

Get a Second Opinion with Code Review
Code review is an essential tool for effective teams, with many benefits. Code review helps teams adhere to a coding style, ensures that there are always two people who understand every commit, and encourages developers to continually learn from each other’s code. When we know that colleagues will see our work, we are extra motivated to commit only clean, polished code. And, naturally, review offers a valuable opportunity to catch coding errors before the patch is merged into the repository.

In this talk we will discuss how to get started with code review. We’ll look at the code review tool that Google uses to ensure quality in its products, to gain a better understanding of how to implement constructive code reviews. Topics will include automating emails to a list of reviewers, and using a web interface to have inline dialog about specific lines of code.

By the end of this session you’ll have inspiration and information to get started with this programming best practice. Combine with Brian Connatser’s session Be committed to Version Control.  Learn Git. to supercharge your team.

Time: 4:00 PM
Date: Tuesday October 26
Room: FITC Unconference Room

this subject is close to my heart because i’ve worked at places with terrible code review practices, where “review” amounted to a group critique of someone’s classes midway-through or at the end of a project, and all too often devolved into style squabbles. bad! if your code reviews are suffering from a similar illness, or you haven’t been taking your daily dose of code review at all (gasp!), come to my session for an Rx.

of course, small boys, and girls of all sizes, are also welcome to develop for litlOS!