Archive for the ‘Languages’ Category.

Full Screen Content and EdgesForExtendedLayout in iOS 7

One of the difference that jumps out dramatically to a programmer — especially those of us who typically build our UIs in code rather than using a visual design surface — is the new “full-screen content” concept.

This is particularly evident with UINavigationControllers. This picture shows the difference between the default mode (UIViewController.EdgesForExtendedLayout = UIRectEdge.All) and the “iOS 6″-style (UIViewController.EdgesForExtendedLayout = UIRectEdge.None).

You can see that in UIRectEdge.All mode, the current UIView‘s drawing rectangle covers the whole screen — you can see the diagonals extend under the navigation bar, toolbar, and even the status bar, and you can see the blue tint coming up through those elements (they are also blurred, which you cannot see in the image).

ChromeCast Xamarin Binding and Sample Source Code on GitHub

Due to popular demand…

Here is source code for a preliminary Xamarin.iOS binding for Google’s ChromeCast

and

Here is C# source code for a simple iOS app that casts a video URL

In order for this to work, you’ll need:

This is just source code, not a step-by-step walkthrough. Everything associated with this is in beta and I don’t want to invest a lot of time making things just so at this point.

You can read an overview of the programming model here.

# ChromeCast Home Media Server: Xamarin.iOS FTW!

As I blogged about last weekend, I got a ChromeCast and had a simple-enough time creating an iOS-binding library for Xamarin.iOS, allowing me to program the ChromeCast in C# (or F#, maybe next weekend…).

This weekend, I wrote a simple Home Media Server that allows me to stream… well, all my ChromeCast-compatible media, primarily mp4s. Here’s how I did it…

ChromeCast Programming: Intro

Essentially the ChromeCast is nothing but a Chrome browser on your TV. If you want to display HTML, no problem, but what you probably want to display is a great big video div:

<video id="vid" style="position:absolute;top:100;left:0;height:80%;width:100%">

But where does this HTML come from? Here’s the first kind-of-bummer about ChromeCast: Every ChromeCast application is associated with a GUID that Google provides you. Google maintains a map of GUID->URLs. And, since you have to send them your ChromeCast serial to get a GUID, it’s a safe bet they check the hardware, too. When you start an application with: session.StartSessionWithApplication("93d43262-ffff-ffff-ffff-fff9f0766cc1"), the ChromeCast always loads the associated URL (in my case, “http://10.0.1.35/XamCast”):

So, as a prerequisite, you need:

  • A ChromeCast that’s been “whitelisted” for development by Google;
  • A Google-supplied GUID that maps to a URL on your home network (a URL you decided during the “whitelist” application to Google)
  • A WebServer at that URL

It’s important to realize that what’s at that URL is not your media, but your “receiver app”: which might be plain HTML but which is likely to be HTML with some JavaScript using the ChromeCast Receiver API that allows you to manipulate things like volume and playback position, etc. I basically just use this file from Google’s demo, with minor tweaks.

Home Media Server : Intro

So if you want to stream your home media, you need a WebServer configured to serve your media. This doesn’t have to be the same as your App Server (it probably will be, but conceptually it doesn’t have to be):

The structure is straightforward:

  1. The mobile controller gets a list of media from the Media Server
  2. The application user selects a piece of media
  3. The controller sends the selected URL (and other data) to the ChromeCast
  4. The ChromeCast loads the media-URL from the Media Server

For me, the “App Server” and “Media Server” are the same thing: an Apache instance running on my desktop Mac.

ChromeCast Media-Serving : Components and Life-Cycle

This is a rough sequence diagram showing the steps in getting a piece of media playing on the ChromeCast using the Xamarin.iOS binding:

  1. Initialization
    1. Create a GCKContext;
    2. Create a GCKDeviceManager, passing the GCKContext;
    3. Create a GCKDeviceManagerListener; hand it to the GCKDeviceManager;
    4. Call GCKDeviceManager.StartScan
  2. Configuring a session
    1. When GCKDeviceManagerListener.CameOnline is called…
    2. Create a GCKApplicationSession;
    3. Create a GCKSessionDelegate, passing the GCKApplicationSession
  3. Playing media
    1. After GCKSessionDelegate.ApplicationSessionDidStart is called…
    2. Create a GCKMediaProtocolMessageStream;
    3. Get the Channel property of the GCKApplicationSession (type GCKApplicationChannel);
    4. Attach the GCKMediaProtocolMessageStream to the GCKApplicationChannel
    5. Create a GCKContentMetadata with the selected media’s URL
    6. Call GCKMediaProtocolMessageStream.LoadMediaWithContentId, passing in the GCKContentMetadata

Here’s the core code:

public override void ApplicationSessionDidStart()
{
    var channel = session.Channel; 
    if(channel == null)
    {
        Console.WriteLine("Channel is null");
    }
    else
    {
        Console.WriteLine("We have a channel");
        mpms = new GCKMediaProtocolMessageStream();
        Console.WriteLine("Initiated ramp");
        channel.AttachMessageStream(mpms);

        LoadMedia();
    }
}

private void LoadMedia()
{
    Console.WriteLine("Loading media...");
    var mediaUrl = Media.Url;
    var mediaContentId = mediaUrl.ToString();
    var dict = new NSDictionary();
    var mData = new GCKContentMetadata(Media.Title, Media.ThumbnailUrl, dict);

    Console.WriteLine(mData);
    var cmd = mpms.LoadMediaWithContentID(mediaContentId, mData, true);
    Console.WriteLine("Command executed?  " + cmd);
}

Plans

The core of a real home media server for the ChromeCast is the Web Server and the UI of the mobile application that browses it and chooses media. To turn this hack into a turnkey solution, you’d need to:

  • Run a public Chromecast application server that
    • Deferred the URL of the media server to the client
  • Write the media server, with all the necessary admin
  • Write a nice client app, that stored the mapping between the public ChromeCast app server and the (strictly-local) media server
  • Make a great user interface for selecting media
  • Make a great user interface for controlling the media

I have no plans on doing any of that stuff. What I plan on doing once ChromeCast and iOS 7 are out of beta is:

  • Make a nicer binding of the ChromeCast API and put it up for free on the Xamarin Component Store; and
  • Play around with serving media and blogging about anything interesting that comes up

Conclusion

The real thing that I wanted to do was see if Xamarin.iOS worked well with ChromeCast (resounding “Yes!”) and come up with a hack for my own use.

Achievement Unlocked.

ChromeCast Home Media Server with Xamarin

Code to follow…

whale_on_tv

Programming the ChromeCast with Xamarin

ChromeCast Notes

I guess I got under the wire with the Netflix deal, so the net cost of the thing was $11. Even at $35, it’s a no-brainer for a developer to pick up and see if they can target.

Experience

Very good OOBE: plug it in to HDMI port, power via USB, and… yeah, that works. Setup via iOS didn’t work for me (hung), so I set it up via Chrome on laptop: fine.

Add extension to Chrome, can “cast” any single tab. Works great with Comedians in Cars Getting Coffee. Integrated is better, though: very easy to watch Netflix and cue up next issue of “Breaking Bad, Season 5″ (they’ve just released, dontcha’ know). YouTube app was a little confusing.

Local files cast from Chrome

Mixed bag. Worked well with raw GoPro MP4s, but not my QuickTime output Content On This Page Is Not Supported. Some MKVs played fine, others didn’t have sound (DTS not supported?).

Photos cast perfectly, but obviously would benefit from a native app.

ObHacks

The one that jumps out is, of course, “DLNA -> Cast.” This would presumably require setting up an auto-transcode to supported formats. Would be best with an XPlat mobile controller: use iOS, Android, or Computer to select files on DLNA server. ? Is there a barebones DLNA library / app that could be hacked?

“It’s not a slide projector, it’s a time machine…” Photo browser.

Video logger: Watch raw footage on TV, hit “in/out”, make notes, triage.

Imperfect information turn-based games (e.g., card games, Eurogames): TV is public, devices are private. Better than “pass-and-play” for, e.g., “Ticket to Ride”. Poker.

Party photos: QR code on screen specifies photos taken in next N hours with device are shown / shared with others with same guid. (How to make work with different photosite / storage options?)

Development

Beta SDK available and simple apps at Github.

I downloaded the iOS SDK and used Objective Sharpie to create Xamarion.iOS C# bindings. Very straightforward; tool did 95% of work. Needed to massage some stuff (some things improperly changed to fields, needed to change FieldAttribute.

“Hello world” Sender app easy-peasy lemon-squeezie:

var gckContext = new GCKContext("net.knowing.xamcast");
    var deviceManager = new GCKDeviceManager(gckContext);
    var dmListener = new DeviceManagerListener();
    dmListener.CameOnline += (s,e) => CreateSession(gckContext, e.Device);
    deviceManager.AddListener(dmListener);
    deviceManager.StartScan();

etc.

BUT… No generic media-receiver app? Can’t just write Sender app and send “GET endpoint to supported format”?

That means all dev requires going through “whitelisting” phase, which takes at least 48 hours. Just figured this out this AM, so guess limited dev this weekend.

Plans…

It’s a beta SDK, so I’m not going to invest much effort in “C#”-ifying the bindings yet. Eventually, I’d like to make it available as a free component on the Xamarin Component Store, but initially I’ll probably just put it up on Github. I’ve already put up the silly Hello XamCast!.

Using Extension Methods on a C# Interface to Enable DCI in Xamarin

Scala has several nice language features, including the elegant use of val for immutable variables and var for mutable, but the feature that I miss the most on a day-to-day basis is “traits.”

Traits allow you to implement one or more methods of an interface. The canonical use is to “mix-in” behavior while avoiding the “diamond-problem.”

DCI has the idea that Objects (domain-meaningful entities that correspond to user conceptions) adopt Roles, which are context-specific. Roles interact to produce value. So, for instance, when you’re transferring money at an ATM, you’re dealing with two accounts that are the same type of Object (Account), but which are in two different roles in the context of “Transfer Money”: a TransferSource and a TransferSink. And an Account in a TransferSource role has different behavior than an Account in a TransferSink role (e.g., TransferSource expects to withdraw(Money amount) while TransferSink expects to credit(Money amount)).

In C#, the way to specify that a class has a certain set of behaviors is to specify those behaviors in an interface and specify that the class implements them:

public class Account: TransferSource, TransferSink

And then, of course, you would implement the various methods of TransferSource and TransferSink within Account.

But the very essence of DCI is the premise that classic OOP type-systems don’t appropriately capture the relationships between Objects-in-Roles, even though “Objects-in-Roles working with each other” is the domain-users mental model (“I pick a source account, and a destination account, and specify an amount, and the amount is debited from the source and credited to the destination”). So DCI says that the TransferTo method that corresponds to the use-case should be elevated to a first-class object.

But in C# you cannot partially implement an interface. But you can create and implement an extension method on an interface!

  public static class TransferContextTrait
  {
    public static void TransferTo(this TransferSource self, TransferSink sink, Decimal amount)
    {
        try
        {
            if(self.Funds < amount)
            {
                self.FailTransfer(new TransferFailedReason("Insufficient Funds"));
            }
            else
            {
                self.Withdraw(amount);
                sink.Deposit(amount);

                var details = new TransferDetails(self.Name, sink.Name, amount);
                self.AccomplishTransfer(details);
            }
        }
        catch(Exception x)
        {
            self.FailTransfer(new TransferFailedReason(x.ToString()));
        }
    }
}

Note an interesting restriction, though: You cannot trigger an event from within an extension method! So in this case, although I would have preferred to propagate the results of the calculation by self.TransferAccomplished(this, details) I have to use a proxy function in Account:

public void AccomplishTransfer(TransferDetails details)
{
       TransferAccomplished(this, new TArgs&lt;TransferDetails>(details));
}

public event EventHandler&lt;TArgs &lt;TransferDetails>> TransferAccomplished = delegate {};

I’ll be talking more about DCI and other cross-platform architectural techniques at MonkeySpace in Chicago next week. Hope to see you there!

OOPSLA Day 2: Explicit Use-Case Representation in Programming Languages

One of the emerging themes at this conference is the need to move “examples” (and their older siblings, scenarios and use-cases) “into the code,” so that examples/stories/scenarios/use-cases, which are tremendously meaningful to the subject-matter experts, are actually traceable directly into the code, which is tremendously meaningful to, you know, the machine.

I very much enjoyed a talk on “Use-case Representation in Programming Languages,” which described a system called UseCasePy that added a @usecase annotation to Python methods. So you would have:

@usecase(DrawARectangle,DrawALine)
def drawLine(ptA, ptB) … etc …

Now, even if you go no further, you’re doing better than something in a documentation comment, since you can easily write a tool that iterates over all source-code, queries the metadata and builds a database of what classes and methods participate in every use-case: very useful.

Even better, if you have a runtime with a decent interception hook, you can run the program in a particular use-case (perhaps from your BDD test suite, perhaps from an interactive tool, acquire the set of methods involved, and determine, by exercising a large suite of use-cases, metrics that relate the codes “popularity” to user-meaningful use-cases, which could be very helpful in, for instance, prioritizing bug-fixes.

Oh, by the way, apparently we no longer call them “users” or even “domain experts,” they are now “Subject Matter Experts” or even SMEs (“Smees”).

OOPSLA Day 2: More on Dart

I think when people saw that Dart was from Gilad Bracha and Lars Bak there was an expectation that Dart was going to be a grand synthesis: a blazingly-fast NewSpeak-with-curly-brackets. It’s very much not such a language. It doesn’t seem, academically, vastly innovative because it doesn’t add much. But, in truth, optional types are a radical design decision in that they take away runtime aspects that a lot of mainstream programmers expect. (Of course, this raises the question of how to define the “mainstream”…)

Pros and Cons of Mandatory Typing In Descending Order of Importance (per Gilad Bracha):

Pros:

  • machine-checkable documentation
  • types provide conceptual framework
  • early error detection
  • performance advantages

Cons:

  • expressiveness curtailed
  • imposes workflow
  • brittleness

Having said that, I attended a lecture in which someone, perhaps from Adobe, measured the performance impact of optional typing. Their conclusion, although admittedly done on the troublesome-ly small and artificial SunSpider benchmarks, was that the performance penalty of implicit types amounts to 40% (with a very large standard of deviation). That “feels” about right to me — definitely significant but not the overwhelming performance benefit you might get from either parallelization or an algorithmic change.

OOPSLA Day 2: Gilad Bracha on Dart

Gilad Bracha started the day’s Dynamic Languages Symposium with an invited talk on Dart, a new Web programming language (read: JavaScript replacement) in which “Sophisticated Web Applications need not be a tour de force.”

OOPSLA is attended by academics, who are typically less interested in the surface appearance of a program (they’ve seen just about variation) and more interested in semantic questions whose impact in the real-world might not be felt for many years. So Bracha begins his talk by disavowing the “interesting-ness” of Dart: it’s a language whose constraints are entirely mundane:

  • Instantly familiar to mainstream prorgammer
  • Efficiently compile to JavaScript

(Personally, I take it as a damnation of the audience that “Of interest to 90% of the programming world” is not of importance, but the gracious interpretation is that these are the trail-blazers who are already deep in hostile territory.)

The gist of Bracha’s talk was on Dart’s “optional types” semantics. The great takeaway from this, I think, is that:
“Dart’s optional types are best thought of as a type assertion mechanism, not a static type system”
which allows for code that can make your blood run cold; what certainly looks like a statement of programmer intention (“this variable is of type Foo”) can be blithely trod over at runtime (“in fact, this variable is of type Bar”) without so much as a by-your-leave.

The type expression is only evaluated at compilation time and, if the developer puts the compiler in “development” mode, you get warnings and errors. But once out of development mode, there are no runtime semantics of the type expressions. They have no behavior, but on the other hand, they have no cost. And, argues Bracha, this seemingly extreme position is important to support a language that remains truly dynamic and does not “put you in a box” wherein the type system becomes a restriction on expressiveness.

One of the seemingly-obscure corners of language design are the semantics of generics (the building blocks of collection classes). Generics in Dart are reified and covariant, which to an academic means “the type system is unsound.” Bracha acknowledges this and says that he’s “given up” on fighting this battle.

Another interesting design element of Dart is its recognition that the “classic” object-oriented constructor is a failed abstraction that only allows for “I want to allocate a new instance…” instead of common scenarios such as “I want to get an object from cache,” “I want an object from a pool of a specific size (often 1),” etc. So you can declare something that looks an awfully lot like a classical constructor, but in fact is “allowed” to return whatever the heck it wants. (I put “allowed” in quotes because, remember, all this type stuff is just epiphenomenal <– mandatory big word every paragraph!)

The lack of mandatory types preclude the creation of type classes or C#-style extension methods. Those are grating, but really of concern to me is that their lack also precludes type-based initialization. This leads to the disturbing design that variables will have the value null until they are assigned to; a “disturbing design” that is standard in the mainstream but hated by all.

…off to lunch, more later…

OOPSLA Day 0

I am in Portland for OOPSLA / SPLASH, a conference that is my sentimental favorite. I think my first OOPSLA was in New Orleans circa 1990 and OOPSLA Vancouver 92 is filled with memories (mostly because Tina came and we dove Orcas Island in wetsuits).

OOPSLA is traditionally the big academic conference for programming language theory and implementation. When I was a magazine editor and track chair for the Software Development Conferences, OOPSLA is where I trolled for new fish — concepts and writers that were ready for trade exposure. That’s no longer my business, and I wonder if I’ll get the same thrill from attending that I used to.

The program looks promising and I’ve just spent a few hours going over the papers in the proceedings DVD (no more phonebook-sized proceedings to bow the bookshelves, but I’m sure I can still steal some article ideas…).

I’m happy by the late addition of talks by Gilad Bracha and Lars Bak on Dart, the new programming language from Google. I’m unabashedly a fan of Bracha’s NewSpeak and the one time I heard Bak talk, I said he was “dynamite….Concrete, informed, impressive….” so I’m favorably disposed to like their language, even if it does have null (and not just have it, but

In Dart, all uninitialized variables have the value null, regardless of type. Numeric variables in particular are therefore best explicitly initialized; such variables will not be initialized to 0 by default.

Which strikes me as flat-out crazy, reiterating Tony Hoare’s “Billion-Dollar Mistake.”
Early reaction to Dart has been pretty harsh, it will be interesting to discuss it in-person (where the tone will be 1000x more reasonable and respectful than on the Internet).

div>