Wednesday, April 16, 2014

On Writing an Over the Air TV Schedules App

Apple has been kind enough to accept my iOS App for reading TV schedules from an HDHomerun network TV tuner: Schedules GH. The first question that comes to mind, is why would I do such a thing? People have always connected Internet connections and the Internet is filled with TV schedule data. For instance, my MythTV server gets its listings from Schedules Direct, and I also go to Titan TV when that isn't available. So, I will admit this is a niche product, useful to OTA enthusiasts and the handful of people who take their HDHomeruns RVing.

Sometimes, you write an app just to show what you can do. It is not a beginners task, to walk line by line through the ATSC spec, to figure out the packet structure, implement a Huffman decompressor, decode various odd flavors of text, and know what every bit of a data blob means.  And then to turn around, and make an attractive, iOS7 themed app which scrolls at 57 fps, can call (at least five) multiple tuners concurrently, has a pleasant on-boarding experience all with a consistent color palette.  Earlier in the year, I'd been doing the rounds looking for a job, and what I heard from companies was a need full-stack app developers, especially with the new hot topic being energy-efficient Bluetooth LE. So I concentrated on finishing a product which would showcase my overall skills. On interviews, I'd bring out an HDHomerun and a Leaf-style antenna and show them what I was up to.

Schedules GH
The idea to write a scheduling app came out of the shelved idea of writing a TV audio app. I had read about Silicon Dust releasing a transcoding version of the HDHomerun, the HDTC-2US, and I thought it'd be interesting to write a player app, concentrating on audio listening. However, what I had assumed was that the tuner would not only transcode video but would also transcode Dolby Digital, and it doesn't, at least not yet. Well, Dolby takes both an arm (upfront license fee) and a leg (per unit royalty) to legally decode their audio data. So I'll wait on Silicon Dust updating the firmware.

 But I'd already explored various ways to get schedule data into my app. I couldn't get it from Schedules Direct as I wasn't planning on open sourcing the app, and while I did talk to a pleasant man at Tribune Company owned Zap2It Labs, I wasn't going to have the volume to make it worth their while. So, I reasoned, why not just get the information from the device itself.

Thus I started a journey down into A/65:2013. the technical standard in the United States for broadcast digital TV. LibHDHomerun is a bit helpful, in that you can tell it to filter and deliver kinds of packets, but the sample code is about extracting video streams, not reading data packets, so all the locating the various tables in the spec: the master table, the terrestrial channels table, the system time table, the event record, the extended text table was up to me. It took the longest time to work right; I was particularly vexed by missing that over a certain packet size (188 bytes) tables would have to be stitched back together before calculating a validating CRC.  I leaned heavily on unit tests, and I can at least say that my code works for the stations in the greater Boston area.


I hadn't heard the term on-boarding before WWDC 2012, but it makes sense, the user's experience the first time they load the app is critical towards them knowing what the app does and how to use it. With a hardware tied app, its absolutely necessary (and yes, the next version of Signal GH will have an on-boarding sequence).

So, the onboarding is just a 3 step process of choosing an initial tuner, scanning for channels and sub channels, and finally choosing which tuners to call to get schedule information. If I had done this on my Signal GH app, I'd have a lot fewer confused users. 

UI Niceties

In the old days of iOS development, we'd get details about a table item by sliding over to a detail view. It seems like the fashion these days is to do more inline. So tapping on a schedule listing, just animates an expansion of the table, revealing the whole description text, and some action buttons.
You'll notice I'm using a green stripe to indicate a show that is on right now. No need to hit the user over the head.

I experimented with using pull to refresh instead of the refresh button, but pull to refresh requires me to be at the top of the table, which I might likely not be. So I went with the refresh button. 

All the graphics, given that I wrote it, are of course in vectored SVG format including the network logos. So I don't worry much about scaling. I drew all the artwork that wasn't a network logo with my SVG Paths app and I think everything turned out nicely. 

In general, the UI does not try to extend the boundaries of app design. Just execute a recognizable, flat design and keep out of the way. I review a lot of apps tied to devices on Amazon through the Amazon Vine program and I wish others would follow this guidance.

Submitting to Apple

As this is an app tied to a specific device, and I'm not actually sure how Apple reviews Signal GH (do they have an in-house HDHomerun?), I asked Apple reviewing for guidance and they told me to ship them hardware, so I shipped them my cheapest HDHomerun with an attached antenna. Which they promptly lost for a week, apparently, but eventually the app was reviewed, and became available yesterday night. 

Hopes and Dreams

Well, I don't expect a lot of income out of this app. It will likely be extremely useful to a handful of people in specific circumstances. And other, more hobby minded, people will likely find it interesting what TV stations put into their data stream. It was a nice demo when I was job hunting, although in the end, the job I did get didn't even involve a face to face interview. And the code will be used in other apps in the future. So a decent use of my time.

Thursday, January 30, 2014

Announcing SVGgh - A library for rendering SVG in iOS

I've spent the last several days putting the finishing touches on open-sourcing my code for rendering SVG: SVGgh. This is the first time I've put anything public up on GitHub, and I hope my fellow developers can find it and make use of it. It's under MIT license, so I expect there will be no problems using it in your projects or extending it for your own uses, or even just as a tutorial for understanding Core Graphics or Core Text.

Here are a few highlights:

  1. SVGDocumentView - A view to replace UIImageView with a nice, crisp, re-scaleable SVG image. Configurable from a Storyboard or nib.
  2. GHButton - A UIControl button which can draw a nice chrome appearance, and have an embedded SVG icon.
  3. SVGRenderer - A class capable of rendering an SVG into a CGContextRef, so if you wanted to convert an SVG to a PDF or some bitmap format, that would be doable. 
  1. It doesn't do everything in the SVG spec. No animations, SVG Fonts, filter effects.
  2. It has code that needs some bug fixing. Just today, I realized my gradients weren't working properly with entities that had a transform attribute set.  But in general, I've been using this code for over a year in my own apps and it's been fine. 
  3. It's not necessarily the best code for making an editor.
I've cleaned the code like crazy the last couple days. Renaming classes, cleaning up parameters, adding Doxygen style header comments, and moving code around to have better organization. It should be in good shape for others to just pop in and use. 

Monday, January 13, 2014

Signal GH app Reviewed by Solid Signal Blog

One of the multitude of problems with alerting potential users to my apps is getting independent reviews, and when an app requires special hardware, as is the the case with my Signal GH app to monitor the signal quality of over the air digital TV streams, that problem is multiplied. So I eMailed Stuart Sweet, the author of the Solid Signal Blog, if he'd review my app if I were to ship him my own HDHomerun, and he kindly agreed. He was also agreed to ship it back, I paid for all this Fed-exing, which he promptly did; thankfully my wife gets a good deal on shipping. Luckily, between Christmas and New Years, there isn't much on broadcast TV, and my other single tuner HDHomerun was able to grab all but 2 shows I'd otherwise have watched.

And he gave it a positive review, saying  "This app is a total must-have for the HD HomeRun user...". so the trouble was well worth it.

The near-irony here is that as a top-500 Amazon reviewer, I get requests nearly daily to review someone's gadget, iPhone case, or book and I nearly always refuse due to either time constraints, the fact that I don't review novels, or not feeling comfortable taking something that I might have to slam in my review. (I have no problems slamming products I get through Amazon's own Vine program, as I don't get those directly from the manufacturer.)

Anyway, thanks to Stuart for taking the trouble to review Signal GH in his fine blog.

Wednesday, November 27, 2013

Writing an iOS Kids App-Frog Draw

I recorded an episode of The Tablet Show this week where I talked about what I've learned about writing an app for the Kids section of the App Store, the kid's shape drawing app, Frog Draw.

The Parental Gate

Apple rejected my app three times. The first was because of sloppy layout issues on my part, but the last two were because of the Parental Gate. Basically, apps in the kids section have to ask for parental permission every time the kid wants to buy something or interact with the wider Internet. I somehow missed this, so the second rejection was because I'd missed this requirement. So, no gate on purchasing my beautiful stickers, and no gate on sending artwork via e-mail; bam another 5 days in the review queue. 

So I looked around at what that actually meant, and found these examples at Dreambot Studios. Amazingly, Apple didn't provide a standard API for providing a secure gate. I'd have expected there would have been an API that provided a localized challenge string, and a cryptographically secure method of validating a response. Instead, developers have to roll there own method to differentiate between a 12 year old and an adult. I chose a math problem I didn't think my precocious 8 year old could solve:

Frog Draw's Parental Gate


Apple provides a mercifully short set of guidelines for iOS app submissions and here is the entire relevant guideline for the need for a parental gate:
 24.3 Apps primarily intended for use by kids under 13 must get parental permission or use a parental gate before allowing the user to link out of the app or engage in commerce
So given this directive, I thought it would be easiest on the parent to provide a convenient one stop location for all the parental controls, so that the  parent could allow or disallow purchases, allow for making a quick trip to the App Store to rate the app, and turn on various means of sharing the drawings. All of these were off by default.
My Rejected Parental Controls Pane
I even put some Emoji characters in there so that non-English speakers could tell what they were agreeing to. And I submitted it to Apple and it was (I wish I could say promptly, but it was another 5 days) rejected. Why? Because while the guidelines make no mention of this, Apple has a rule that you cannot permanently enable a gated feature. Their rule is that the parent has to agree to its use each and every time.

I was pretty upset about this, but I kept calm and appealed the ruling to the review board, and was promptly told my appeal was rejected; this was indeed how the review team interprets rule 24.3. Two things, one I don't like arbitrary rules ruining my beautiful app with user hostile behaviors; I want to empower my users to have fun and draw some silly images.  And two, as a parent, I am not feeling empowered. As a parent, I would likely want to disallow in-App purchases even though Frog Draw only sells non-consumable clipart/stickers—I still remember spending $35 on Smurfberries—and allow e-mails. I don't care either way about rating the app. And turn off everything else.  But it's Apple's playground, so I did it their way.

Can Kids Apps be non-Skeuomorphic? 

As an adult with something approaching design taste, I am happy with iOS 7's lack of chrome and general removal of fake analog reality. I wish buttons had just a little bit of chrome, but otherwise, I'm a happy iOS user. But do children need something more? I guess I'll find out.
Here's my iPhone layout while displaying its color toolbox:
Frog Draw with Color Buttons
You'll notice that I am using recognizable buttons, but with light chrome. Also that the artwork projects into the status bar; this is under the user's control. Want to see what time it is? Draw something light under the clock. I'm using a light highlighting to show which tab is active, and in general I'm following the rule that controls should not be visually distracting. The important part should be the art. 
Frog Draw with Stickers

I hope this applies to kids too, and they don't require Fisher-Price controls and fuzzy bunny cartoons wasting space and distracting them; or more importantly for downloads that parents don't have a pre-existing view of what kids apps look like.

In my first version of this interface, I thought it would be cool to have iOS 7 style squircles behind my shapes. But testing with my kids revealed that children are already hard coded to tap on that shape (instead of what I want them to do, drag a copy off). So I removed the squircles which led me to change the color of my toolbox, which led me to change the color of my toolbox tab bar, which lead me to change my highlighting color which led to my final design, which I love.

An Early Design that had Issues. I missed Halloween.

The design choice I made which I'm most unsure of is the icon. On the one hand, modern iOS icons are geometrically simple, clean lined, abstract pieces of art. On the other hand it's hard to make a happy smiling abstract frog, it'll look too much like a duck. If my app doesn't sell, I'll blame the icon.

[Update: I've changed my mind on the icon. I'll dial back the cold inaccessible look and add some humanity to the 1.1 version's icon.


Kids and Gestures

I've already covered the importance of gestures in a modern interface but a few words about kids. Kids are more adept than we old folks at picking up gestures. They get the visual cues, they know what worked in other apps and they don't have a lifetime of mousing to unlearn. In fact, my daughter asked me the other  day, "what is a mouse?" when she was trying to figure out a Flash game on PBSKids (we use Magic Trackpads with our Macs). Kids pick up gestures if you give them enough clues or a visual explanation of what will happen when you do what. My major concern is communication with the user about the non-discoverable gestures like my 2 finger up down swipe to change the order of shapes. Thus, the importance of having a decent on boarding screen for the first time the app gets run. As I have the ability to animate the whole creation process of a Frog Draw document, my on boarding window has an animation of some gestures, and I hope this is enough, but I'll likely revisit this.

Make a Quality App

There is nothing about writing for kids that means you can cut corners. My son knows what a good app looks like and how it acts. Last night, he was making sure I knew I should have a longer tutorial/level  up section just like his best games have. At release of 1.0, I have a good app. I've profiled it to look for speed bottlenecks, I've rejected my own submissions to Apple more times than I'd like to count when something came up which would result in a child having a bad experience. The last month of development has humbled, but I think the end product is worthy. 

I don't know if people value this, but I do. The packaged up App is only 4MB. It would have been under 3MB, but at the last minute I had to add 64-bit support or Apple's face recognition functions wouldn't have worked on A7 based iOS devices. This was all possible because pretty much every pixel in the interface is drawn either in code or by rendering lightweight SVG, and not with bulky bitmap images. I hope potential customers don't see the small download size and think there's something missing, I value efficient use of a user's limited space. Being bulky will get an app booted off my iPad if I don't use it daily.

Frog Draw 1.0 Free in the App Store, no Ads, no consumable in-app purchases, just some child-friendly vector clip art. Thanks. [Update: now the app is $.99 and there are no in-app purchases. I'm trying different ways to make money. Still no ads.]

Sunday, November 24, 2013

Change of Distribution Policy for Signal GH

Today I saw this review for Signal GH my HDHomerun utility: Don't buy if you're in Europe 1 Star Bought this without detecting that it is USA only. I wasted my money. Should have said on the App Store. Ripped off. Now obviously, this user didn't write me to try and resolve his problem. And I don't know if he didn't notice there was a setting for using the European TV standard, or if he did and it didn't work, or if he was upset that US users got the benefit of a map of broadcasters, but the fact of the matter is I don't know that Signal GH works in the UK or not; I just assumed it would. So, I am stopping distribution in Europe (excepting Denmark where I've been distributing for years without complaint). If someone in the UK or any other European country would like to try it out, let me know and I'll turn distribution back on temporarily. And users of the App Store should know they can contact Apple support shortly after purchase for refunds. [Update: Apparently the version I just put on the App Store 1.4.1 is broken for people who haven't done an initial scan and this is probably the problem the U.K. user saw. I've removed it from distribution and will be posting a 1.4.2 update presently]. [Update 2: I've submitted a 1.4.2 update to the App Store, and I apologize for the bad impression I've given to new users over last week. It was my error in not testing a clean install.]

Sunday, November 03, 2013

Touch GUI and Replacing Buttons With Gestures

I've been thinking a lot about gestures lately. I submitted a kids drawing app, Frog Draw, to the App Store this week, and while I'm proud of it, it certainly ended up different than the plan in my head when I first sat down in Xcode and started coding it. Much of this, comes because of a gradual realization that gestures are better than buttons. Here for instance was my first thought for a interface for modifying objects:
The idea behind this was that the user would tap an onscreen object, a square perhaps, and this item would appear to give options in button form, including a rotation button which would follow the finger in a circle as he twirled the whole edit ring and object around. I had it all worked out that the buttons would rotate with the ring's rotation. I was quite proud of the geometric perfection of its layout; it was a perfect hexagon inside a perfect ring. And then I actually tried to use it.
The ring was in the way of things, preventing me from selecting other objects. And what if the object was up in a corner, obscuring a button, which required redundant buttons such as the doubled X delete buttons in the above. No, this would never do.

So I went with gestures. Translating via dragging a finger and pinch and scale gestures could be easily enough done, but what was the gesture to delete something? At first, and for much of the development cycle, I went with an analogous gesture to the Mail app's delete swipe, a quick leftward flick.
But that turned out to be too unreliable, as it was hard to both distinguish between a normal leftward translation and a delete, so half the time, I just ended up moving the object a bit to the left, or worse, an unintended deletion. Yes, I have unlimited undo, but still. In the end, I just accepted a drag of both the finger and the object into the toolbox area as a delete. Easy to do and easy to understand.

Which brings up another idea, the unimportance of direct manipulation. In the real world, if you wanted to drag a card around on a table top you'd put your finger down on the card and move it around, the finger always obscuring some of the card. In the digital world of the touch screen the programmer has a choice. If I have a selected object, why do I have to have my finger over it, preventing me from seeing where exactly I want it to go. Oh, I could bring up a loupe view to show what's under my finger, and perhaps magnify it, but won't that take up even more precious screen space? So, I decided that I could pinch, rotate and translate anywhere in my document view and it would change the selected object.
As I was testing my app, it became more and more obvious I needed an easy way to change the front to back order of objects. Many times, I'd draw a mask (maybe a frog's face) and want to put a photographic face behind it, peering through a hole. In the old days of desktop apps, this would be a menu item or a button or both, but not in mobile where space is precious. For a long time, I was intending to have a table of all the objects in a document layer, and the user would manipulate z-order by dragging one object cell to a different position (and I still might do this) but it seemed like this was a good opportunity for another gesture, and the easiest that came to mind was a 2 finger up or down drag.
This worked out quite well, as I could bring an object up or down several levels in a single swipe. I even used the same mechanism to re-order layers if no object was selected. What I'm giving up here is discoverability, few users will discover this behavior on their own. I put a diagram in the initial onboarding dialog, but time will tell if that's enough.
Not that the button is dead, I had thoughts of dragging color swatches onto objects, but that was just too much to ask of the user in terms of consistency, so I just have simple buttons to apply colors or other style settings to the selected object. Look for Frog Draw in the App Store next week.

Thursday, September 19, 2013

Typing iOS Icons in SVG

I know many people when faced with the task of making an icon will fire up Photoshop and start pushing pixels. But lately, when graphics are needed, I've been jumping into my text editor, BBEdit, and creating an SVG document from scratch. Like this one for—appropriately—my new iOS app about learning and playing with SVG paths called SVG Paths:



Sorry about what my code formatter is doing to the rect element in the above.

I can then open the result in iDraw, scale the drawing down to the appropriate size for an iOS icon and save it out as a PNG.  For smaller icon sizes, 29 pixels? really?, I might tweak it a bit to emphasize just one sub-element. The advantage for me is I get exactly what I expect with mathematically pure shapes. And it's a lot simpler than the times I've programmed graphics in raw Postscript. It wouldn't necessarily be a good way to make an elaborately textured icon, but with the flat simplicity mantra of iOS 7 the stark clean lines of SVG are a good fit.

Oh, and here's an animated GIF my new app can generate of me drawing the icon: