Dynamic Type in iOS 7: Not Quite as “Dynamic” as You Might Think

One of the nice features in iOS 7 for old fogeys such as myself is that the user can use the general Settings to increase and decrease the fonts used in apps. This is called “Dynamic Type.” Judging by developer forums, I’m not the only one who thought that this was something that was built in to the various widgets. It’s not. To do this in your own app, you have to respond to the ContentSizeCategoryChanged notification and invalidate the layout in any widgets you want to have change size. In Xamarin.iOS, the code looks like this:

[code lang=”csharp”]
public class ContentView : UIView
{
public ContentView()
{
var txt = new UITextView(UIScreen.MainScreen.Bounds);
txt.Text = "Lorem ipsum dolor …";
ResetDynamicType();
//Respond to notification of change
UIApplication.Notifications.ObserveContentSizeCategoryChanged((s,e) => {
ResetDynamicType();
});
AddSubview(txt);
}
public void ResetDynamicType()
{
txt.Font = UIFont.PreferredFontForTextStyle(UIFontTextStyle.Body);
}
}
[/code]

The crucial point being that you have a ResetDynamicType method (or whatever you want to call it) that you call both at initialization and then again every time you get notified of a request to change font size (if you want, you can read the new size from the e in the lambda). So “Dynamic Type” isn’t really anything special in terms of display: it’s still up to the application developer to have a function that’s called. What is dynamic is the value returned by UIFont.PreferredFontForTextStyle, which varies based on the user’s Settings.

Xamarin Code for iBeacons

Did I mention how easy it is to track an iBeacon using Xamarin?

[code lang=”csharp”]
locationManager = new CLLocationManager();
var beaconId = new NSUuid("E437C1AF-36CE-4BBC-BBE2-6CE802977C46");
var beaconRegion = new CLBeaconRegion(beaconId, "My Beacon");
locationManager.RegionEntered += (s, e) => {
if(e.Region.Identifier == "My Beacon")
{
Console.WriteLine("Found My Beacon");
//Fire up ranging
locationManager.StartRangingBeacons(beaconRegion);
locationManager.DidRangeBeacons += (lm, rangeEvents) => {
switch(rangeEvents.Beacons[0].Proximity)
{
case CLProximity.Far:
Console.WriteLine("You’re getting colder!");
break;
case CLProximity.Near:
Console.WriteLine("You’re getting warmer!");
break;
case CLProximity.Immediate:
Console.WriteLine("You’re red hot!");
break;
case CLProximity.Unknown:
Console.WriteLine("I can’t tell");
break;
default:
throw new ArgumentOutOfRangeException();
}
};
}
};
locationManager.StartMonitoring(beaconRegion);
//Create a beacon
var peripheralManager = new CBPeripheralManager(new MyPeripheralDelegate(), DispatchQueue.DefaultGlobalQueue, new NSDictionary());
var beaconOptions = beaconRegion.GetPeripheralData(null);
peripheralManager.StartAdvertising(beaconOptions);
[/code]

My Favorite iOS 7 APIs Part 1: iBeacons and Multipeer Connectivity

Since Xamarin provides full native capabilities, developers don’t need to wait for us to exploit iOS 7’s awesome new APIs, such as:

  • iBeacon: This, to my mind, is the stealth API of the release. An iBeacon is a Bluetooth device (just iOS devices for now, but Apple says they’ll release a Bluetooth profile for h/w manufacturers) that broadcasts a UUID (the UUID is intended to be shared between many devices, e.g., a store-chain will have a UUID and all their stores will broadcast it: new store’s geofence works instantly). The UUID travels up to Apple and apps that monitor for that UUID get alerted when they enter a geofence around the beacon. Within the beacon’s region, BT, not GPS, is used to indicate proximity. Pair that with…

  • Multipeer Connectivity: Ad Hoc messaging and data with none of the hassle. Broadcast a protocol string (“com.MyCompany.MyApp”) and everyone in BT range or on the same WiFi network advertising their interest in that protocol string gets an alert and, boom!, you’ve got Birds of a Feather. (Whoever writes the “Fetish Friend Finder” app using iBeacon and MPC is going to retire early. Of course, there are only 2^122 GUIDs, so you couldn’t track every kink.) (UPDATE: A sample chat app I wrote )

iBeacons can be combined to create many actionable zones within a physical location:

Here’s some Xamarin code

3D Maps in iOS 7 with Xamarin

It’s trivially simple to show 3D maps in iOS 7:

[code lang=”csharp”]
var target = new CLLocationCoordinate2D(37.7952, -122.4028);
var viewPoint = new CLLocationCoordinate2D(37.8009, -122.4100);
//Enable 3D buildings
mapView.ShowsBuildings = true;
mapView.PitchEnabled = true;

var camera = MKMapCamera.CameraLookingAtCenterCoordinate(target, viewPoint, 500);
mapView.Camera = camera;
[/code]

MKMapCamera

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.

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!