Archive for September, 2015

Apple TV: Strange fmt errors in simulator

Errors stating EXCEPTION thrown ('fmt?') popped up while trying to work with AVFoundation on the Apple TV simulator. A little searching and, I googled across this Stack Overflow post that suggested changing the input in System Settings might work.

It did.

I don’t have “Internal Microphone” in my Sys Prefs Sound > Input pane but I do have “Line In”. I chose that. My output was already set to Headphones. That one change got rid of the issue and my ATV app is now running with sound.

Thought I’d leave this here for future googlers.

Revisiting the Permutation Generator in #swiftlang

It’s been a while, the language has evolved, and so I thought I’d visit my old friend the PermutationGenerator. Header docs say:

A *generator* that adapts a *collection* `C` and any *sequence* of its `Index` type to present the collection’s elements in a  permuted order.

You pass it a collection and a sequence of indices, and it returns elements based on that sequence. This code creates a scrambled index generator, which I feed to AnySequence to build the permuted output.

The permutation generator isn’t limited to random scrambles. You can use the same approach to build a strideable sequence as in this next snippet, or to any other computed walk through indices:

I had to tweak a bit with the distance check because you cannot use < to test two Self.Index operands. Update: Much improved. Thanks @oisdk.

While I don’t see myself using this a lot, I’m glad I had the chance to swing by it a second time for another look. As always, feel free to correct, tweak, or improve. Thanks!

Read On…

Kickstopper idea: Rethinking Self-pub

How good or bad an idea is it to write a book chapter-by-chapter, continuing on only if enough copies sell to cover costs to continue on for another chapter of writing?

If the playgrounds book taught me anything it is that writing for love (and I did love writing that) will not cover costs, especially for niche topics.

How would you set up a “pay-as-it-goes” writing system and what would be some gotchas? What price point for what might end up as a very short book? Could it turn purchasers into co-marketers, so they’ll keep getting updates?

Thinking of course, of an Apple TV book here, which seems pretty niche at this time. I’ll be done with the Swift Developer’s Cookbook very soon and am trying to brainstorm what’s next.

Thanks for your advice.

Apple TV Lessons 10: “Universal” purchase vs app

A post on devforums clarifies that tvOS apps will be standalone. You will not be able to build a universal app that works on both iOS and tvOS. However, you will be able to share code — assuming I can ever get my conditional compilation of #if os(tvOS) working.

Don’t confuse universal apps with the universal purchases mentioned in the write-ups: “Empower customers to enjoy their favorite apps on both iOS and the new Apple TV with a single purchase by enabling universal purchase for your app on the App Store.”

It looks like you’ll be able to create a bundle that sells with components for both systems, even if there are two actual apps that you’re building.

Apple TV Lesson 9: Indirect interfaces

It should not come as a shock to you that Apple TV apps are not touchable.

Sure, you can use the remote and slide your finger around, but there’s no compelling real-world correspondence between the blank touch pad and the large screen it relates to.

When you design, you must design for relative interactions. Think “directions” instead of “points”. For example, “this button is to the right of that button, so shift the focus to the right” or “I want my toy to move up, so I’ll swipe in that direction”.

This is where gesture recognizers show great value and direct interaction like touchesEnded don’t.

Today, I decided to push the limit and see how much I could convey just using the blind touch region on the remote. The video shows my interactions. It’s okay for experiential messing around but kind of awful for any purpose.

It helped to reinforce that creating frogger-like games (such as the one shown at the event) is going to be an easier task that anything that involves indirect input like drawing or goal point setting. If you’re kicking around ideas of “what might be a good game to create”, this is going to be a huge design point to consider.

Think more GameBoy-style, side scrollers, etc than Drawing with Friends.

I’m also thinking this might be a good time to bring back the Graffiti-style text input code of yesteryear (not to mention file radars for Siri text input).

There’s some good discussion about UI focus on buttons, tables, etc. in the docs. Although my primary interest is SpriteKit, I think it’s time to kick the UIKit wheels around a little.

AppleTV Lessons 8: Cross Platform Code

Today, while taking a break from my Swift book, I decided to set things up for Swift dev on the platform. When you live your life with cross-platform code, having to deal with a new platform is…difficult.

For the moment, I’m treating tvOS as a variation of iOS and converting all my statements that look like this:

#if os(iOS)
    #else
#endif

to be flipped on their heads to test for OSX instead. It’s a huge pain in the neck.

In theory there should be a construct like if os(tvOS) but I have yet to figure it out exactly. Grrr.

Update:

 #if os(iOS)
 #elseif os(tvOS)
 #else
 #endif

Swift lessons: Why write in Objective-C #swiftlang

A few people have asked why I’m exploring tvOS in Objective-C instead of Swift given how invested I am in the new language.

Quick answer: I want to use SpriteKit and all my Sprite libraries are in ObjC. I’ve attempted to port them a few times but Swift kept changing. Right now, I can throw everything together (SpriteKit, my Essentials pack, my Handy Utilities pack, Constraints, etc) and just use one language to get it all done.

Going back and forth in one project is a major cognitive burden and this just got me going quicker. I’ll probably start porting my SpriteKit utilities again now that 2.0 seems “stable” (hah, just watch, this is like Charlie Brown and the football, right?).

And yes, it’s really weird to spend your entire day in Swift and then poke around in ObjC in the evening to see what’s new in tvOS (which I keep want to write as osTV for some reason).

Apple TV Lesons 7: Crafting icons

First video:

You’ll want to design your icons and launch screen at a size of 1920×1080 and then trim down as needed. Leave at least 90 pixels to each side and 60 at the top and bottom to account for potential overscanning issues. Details are found at the Apple tvOS HIG.

 

Screen Shot 2015-09-10 at 4.48.07 PM

 

I built my icons in Photoshop (here’s hoping El Cap won’t kill my Photoshop!) and imported them into the App Icon & Top Shelf image template. Not all image sizes are listed in the Identity and Type inspector so I had to hunt around a bit. To save you time, here are my sizes:

Front, Middle, and Back (Large): 1280×768

Front, Middle, and Back (Small): 400×240

Launch Image: 1920×1080 (see advice above)

Top Shelf image: 1920×720

For the Top Shelf (this is the MOOSE image in my video), make sure you design side-to-side with enough space and visual punch. This image has a big  role in setting mood.

The front/middle/back sliced images are used to create some of the visual parallax effects. I designed mine all together in Photoshop layers and then saved each one to a different file. I think I may update Art Helper to make this easier.

Your launch image is stored in a separate slot in your xcassets folder so don’t forget it (I did initially) when setting up your art.