Moving beyond the App Store

I got a nice e-mail from Rogue Amoeba this morning about their release of Airfoil 5, and it indirectly highlighted nearly every single thing that is wrong with the App Store. Here they are, in the order that they appeared in the e-mail:

  • A lack of direct customer interaction
    Rogue Amoeba was able to reach out to me directly as a customer to let me know about their release
  • Poor discoverability and weak cross-promotion
    The e-mail’s header included the icons and titles (each as a link) for all six of Rogue Amoeba’s major products.
  • A lack of free trial versions
    The e-mail included a prominent link to download a trial version of Airfoil
  • A lack of paid upgrades
    As an existing customer of Airfoil, I was offered a discount of $14 (nearly 50% off the full price)

Most of these things are key to an indie software development business (and frankly, pretty important in non-indie shops as well). The inability to implement sustainable business models is, I think preventing many otherwise reputable side-projects from pivoting into real businesses. Some have argued (can’t find the link at the moment), that we developers need to get with the times, and that in-app purchases are the future, etc.

I don’t agree. Sure, you can prompt users for their e-mail address at startup, you can cross promote apps or “upgrades” with in-app notifications (and many of the more successful developers are doing just that), but I think that these kinds of tactics are simply hacks to work around a broken system.

Dan Counsell of Realmac Software wrote last year about how the Mac App Store still needs paid upgrades, and we are now three months into Phil Schiller’s promotion that put him in charge of the App Store. Unfortunately, it looks like things aren’t going to change anytime soon.

I don’t know the internal’s of Rogue Amoeba’s business, but they seem to be doing pretty well, and they’ve been around for a long time. The nature of their software forced their hand in staying out of the App Store, but in retrospect in might have been a blessing in disguise.

It’s time to move beyond the App Store…

Creating your own Facebook share button

I recently found out that Facebook no longer offers a “share” button. I think in some cases, the “share” button can give you a better return on your social traffic than a “like” button. I went ahead and wrote up a very short tutorial while I created my button so that you can have your own “share” button too:

Step 1: Create the button:

HTML:

<div class="f_btn"><a href="#" target="_blank">Share</a></div>

CSS:

.f_btn {
font-family: 'Helvetica Neue', Arial, sans-serif;
font-weight: normal;
font-size: 11px;
line-height: 18px;
}
.f_btn a {
position: relative;
display: inline-block;
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
-ms-box-sizing: border-box;
box-sizing: border-box;
color: #222;
overflow: hidden;
height: 20px;
outline: none;
text-decoration: none;
background-color: #f8f8f8;
background-image: -webkit-gradient(linear,left top,left bottom,from(#fff),to(#dedede));
background-image: -moz-linear-gradient(top,#fff,#dedede);
background-image: -o-linear-gradient(top,#fff,#dedede);
background-image: -ms-linear-gradient(top,#fff,#dedede);
background-image: linear-gradient(top,#fff,#dedede);
border: #ccc solid 1px;
-moz-border-radius: 3px;
-webkit-border-radius: 3px;
border-radius: 3px;
}

It should look something like this:

btn

Step 2: Clean up the button

HTML:

<div class="f_btn"><a href="share.php" target="_blank"><span>Share</span></a></div>

CSS:

.f_btn span {
position: relative;
display: inline-block;
padding: 0 4px 0 19px;
}

.f_btn a:focus, .f_btn a:hover {
border-color: #bbbbbb;
background-color: #f8f8f8;
background-image: -webkit-gradient(linear,left top,left bottom,from(#f8f8f8),to(#d9d9d9));
background-image: -moz-linear-gradient(top,#f8f8f8,#d9d9d9);
background-image: -o-linear-gradient(top,#f8f8f8,#d9d9d9);
background-image: -ms-linear-gradient(top,#f8f8f8,#d9d9d9);
background-image: linear-gradient(top,#f8f8f8,#d9d9d9);
}

.f_btn a:active {
background-color: #efefef;
-webkit-box-shadow: inset 0 3px 5px rgba(0,0,0,0.1);
-moz-box-shadow: inset 0 3px 5px rgba(0,0,0,0.1);
box-shadow: inset 0 3px 5px rgba(0,0,0,0.1);
}

It should look something like this:

better_btn

Step 3: Add a nice logo

HTML:

<div class="f_btn"><a href="share.php" target="_blank"><i></i><span>Share</span></a></div>

CSS:

.f_btn i {
position: absolute;
top: 50%;
left: 3px;
margin-top: -6px;
width: 12px;
height: 12px;
background: rgba(0, 0, 0, 255) url('../img/f_tiny.png');
}

It should look something like this:

img_btn

Step 4: Add the share count

HTML:

<div class="f_btn"><a href="share.php" target="_blank"><i></i><span>Share</span></a><div class="f_count">2450</div></div>

CSS:

.f_count {
position: relative;
display: inline-block;
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
-ms-box-sizing: border-box;
box-sizing: border-box;
vertical-align: top;
background: #F7F7F7;
border: 1px solid #BBBBBB;
margin-left: 4px;
padding: 0 3px 0 2px;
-moz-border-radius: 3px;
-webkit-border-radius: 3px;
border-radius: 3px;
height: 20px;
}
.f_count:after, .f_count:before {
right: 100%;
border: solid transparent;
content: " ";
height: 0;
width: 0;
position: absolute;
pointer-events: none;
}
.f_count:after {
border-color: rgba(247, 247, 247, 0);
border-right-color: #F7F7F7;
border-width: 3px;
top: 50%;
margin-top: -3px;
}
.f_count:before {
border-color: rgba(187, 187, 187, 0);
border-right-color: #BBBBBB;
border-width: 4px;
top: 50%;
margin-top: -4px;
}

It should look something like this:

with_count

If you want the share count to be dynamic, you can use Facebook SQL, and load the value using an AJAX request like this:


https://api.facebook.com/method/fql.query?format=json&query=SELECT%20share_count%2C%20like_count%2C%20comment_count%2C%20total_count%2C%20commentsbox_count%2C%20comments_fbid%2C%20click_count%20FROM%20link_stat%20WHERE%20url%20%3D%20%27eisbox.net%27

Storing a Directed Graph in SQL

I recently ran into the problem of having to store a directed graph in MySQL. Actually, I was trying to efficiently store a thesaurus in SQL so that it both used little space and had high performing lookups. A thesaurus, as you probably know, could best be represented as a graph of some type; perhaps as a tree (in a naive implementation), or a directed acyclic graph, or even a directed multigraph.

SQL, unfortunately, does not readily lend itself to these type of data structures at first glance. With some thought, however, one can readily store a tree or any other graph in SQL. Consider the following example:

directed-cyclic-graph

This quickly becomes much more complex as we want to attach definitions to words, and some words in the thesaurus may be the same ‘word’, but a differing class of speech, such as a noun, verb, etc.

How to store this in SQL? One possible solution is to build a node list and an adjacency list:

The node list:

ID Word Definition …
1392 dork nerd; stupid person …
3729 geek odd person; computer expert
7318 nerd geek, but lacking in social grace …
8504 tech computer guru …

The adjacency list:

src dst
1392 7318
3729 1392
3729 7318
3729 8504
7318 1392
7318 3729
7318 8504

Relatively fast and efficient lookups can now be done using SQL JOIN. While I’m sure this isn’t the most optimal structure for performance, it has to be close to the most efficient(*) means of storing these cross references.

I’ve set up a live demonstration of the thesaurus right here:

It contains 83,318 words and phrases, and 1,112,705 cross references for synonyms. Most uncached lookups take place on the order of less than a 1/10th of a second on this busy shared hosting server. Cached queries are virtually instantaneous. And of course, MySQL is not my area of expertise; I would imagine that this could be made even faster.


(*) The context of this problem was specifically storing a directed graph in SQL, not a thesaurus in SQL, nor a directed graph in general. If you’re looking for an optimal structure for a thesaurus or dictionary, you should look into a DAWG like this one: How to Create an Optimal DAWG

Objective-C Memory Management

Regardless of what your language background is, memory management in Objective-C can be a bit difficult to get a handle on. I won’t claim to be an expert on the topic, since I’m still learning myself, but here’s a few of the things I’ve learned while trying to unravel the complexity lately:

There’s a seeming mass of various methods with which you can message NSObjects and any class object that is extend from NSObject, including: alloc, dealloc, retain, release, autorelease, and finalize. But just what do all these mean?

First of all, you need to know that Objective-C has garbage collection capability. If you don’t know what garbage collection is, do a Google Search and familiarize yourself with the topic. Once you’re familiar with the wonders of garbage collection, you need to know that Objective-C may not always use it…

So, as best as I can tell, here’s what the above methods do:

  • alloc: Allocates a block of memory the size necessary for a new instance of an object, returning an uninitialized instance of the object – the object should be initialized using a class initializer after being allocated.
  • dealloc: Automatically called when a block of memory is to be released – ONLY if garbage collection is NOT enabled. Classes should release – not dealloc any objects allocated by the object from here, as they should no longer be needed. Finally, subclasses should also call the superclass dealloc method. This method should NOT be called manually
  • retain: Increments a “retain” count for the object – if the retain count of an object is greater than zero, it will not be garbage collected, autoreleased, dealloced, or finalized in any case.
  • release: Decrements a “retain” count for the object – when the retain count of an object becomes zero, it is free to be garbage collected, autoreleased, and dealloced or finalized.
  • autorelease: Adds the object to the “innermost” autorelease pool; the object will be released when the autorelease pool schedules the next release. When the schedule autorelease occurs, the “retain” count will be decremented and the object removed from the autorelease pool. Calling autorelease multiple times will add the object to the autorelease pool multiple times, and thus call release the same number of times before the object is removed from the pool. If the “retain” count reached zero, the object will be dealloced.

That’s the ugly… Is general, things are actually quite simple:

1) If an object is created using alloc, it will have a retain count of 1, and should be released using release when the object is no longer needed.

2) Calling retain will increment the retain counter; release will need to be called the same number of times to bring the retain count to pre-retain state. (Excluding autorelease scenarios)

Using native Objective-C methods for C Callbacks

For the modern Macintosh programmer, given the incredible power of the Objective-C programming language combined with the fact that you can inline C code directly in the Objective-C code, there are few things left wanting … almost.

One of these stickly issues is the use of C callbacks; passing the reference of a function to a function in order to later make use of it. If you’re writing up your own code from scratch this really isn’t going to come up. But if you want to use a C library in your Objective-C code, especially if you want to call an object method instead of a C function for the callback, it’s a problem very likely to come up.

Because of the Object-Oriented nature of Objective-C, it’s essentially impossible to make a callback to an object method. (Think about it; the method is part of an object instance, and because of the dynamic nature of an object, it’s impossible for the compiler to know the reference to an instance of an object) Thanks, however, to the magic of dynamic typing, even this can be done without too much problem. The one caveat is that the library (or other implementation requiring callbacks) must have the option to pass an arbitrary data reference to the same callback. Here’s how it works:


// Dummy callback object - to prevent compiler warnings
@interface CallbackObject
- (void) updateObject: (void *)data;
@end

@implementation CallbackObject
- (void) updateObject: (void *)data { }
@end

// The C function passed as the callback
static void updateObjectCallback(void *ptr, void *parent)
{
CallbackObject *parentObject = (CallbackObject *)parent;
[parentObject updateObject: ptr];
}

First, some background: In Objective-C, objects are generally passed around as references. For example, if we’re passing around an instance of NSObject, this will generally be in the form of an (NSObject *). In a special case, the variable self is also a reference to the current instance of itself (as opposed to the actual data). This is very useful to us for dealing with callbacks.

Consider the case of a library that manipulates an array of items. The library has a function requiring a callback that will allow you to perform some custom manipulation of each item (The callback being the function that performs the manipulation on each individual item). So, when calling the callback function, the library will pass the item reference as the first parameter, and the arbitrary reference as the second.

This is how the above example works; the callback function has two parameters: the first being a reference to a particular item, and the second being an arbitrary reference, which we decide to use as the reference to the instance of an object. We then can cast the second arbitrary reference to a type of an object containing the callback method we want to use.

But… Why the “Dummy” CallbackObject? It doesn’t even do anything? Exactly. In fact, it’s important to note that the code will work without the “Dummy” CallbackObject. We could have cast the reference to an NSObject *, or, in fact, any Objective-C object. The only reason we use CallbackObject is to prevent compiler warnings that the given object may not respond to the updateObject method. (We already know that the updateObject will exist when we call it) More on why we used this approach in a moment…

Here’s the code in a class that actually makes use of the callback function:


- (void) updateObjects:(NSObject *) object;
{
libUpdateObjects(library->objectList, updateObjectCallback, self);
}

- (void) updateObject: (void *)item
{
// Do stuff with the item here
}

Now we’ve come full circle. The class calls the updateObjects method, in turn invoking the C library function libUpdateObjects, which in turn calls updateObjectCallback on each item, passing the reference to each item, along with the reference to the current object (self).

That goes up to our previously defined callback function, which casts the reference into an object instance of type CallbackObject, and then sends a message to the method updateObjects in that instance. Note that because of the dynamic nature of Objective-C, the updateObject method in CallbackObject never gets called.

Finally, with each item, it’s back in the current instance, doing whatever is supposed to be done with the item in updateObject; and as a result, all the class variables, etc. are fully available to the method!

Granted, this could be set up slightly simpler, however, the beauty of this approach is that any class reference can be passed into the callback – there’s no limitation that requires that “self” be passed as the object reference. Suppose you had another class that also had an updateObject method – you could without reserve pass the reference to that object. (It goes for granted that the method needs to deal with the same type of ‘item’)

Finally, this may also be obvious, but if you want to have multiple callback routines, you’ll need to set up a separate callback template and method for each one. So, that’s how to use native Objective-C methods for C Callbacks.