Tag Archive for Cocoa

Lessons Learned: Code Journal Early Release

As you may know Code Journal had its early release last week and it has been a pretty good experience so far. I got lots of great feedback from users and have already been able to update the application based on that feedback.  The purpose of this post is to share some of the lessons I have learned and create a discussion around independant software development and distribution. I could enumerate all the nice things that have been e-mailed or otherwise communicated to me re Code Journal, but I believe that there is more to be learned from criticism than praise, therefore, I am going to discuss some of  the application’s critiques.

Critique #1: Mountain Lion Only!?!?
Yup, I heard this one a lot. I decided to develop the application for Mountain Lion, because I thought a few 10.8 specific features were essential and that most of the application’s users would quickly upgrade to the new OS. Turns out that even though Apple reported record adoption of Mountain Lion (OS X 10.8), a large set of Code Journal’s potential users are running older systems: mostly Lion (OS X 10.7). The good news is that despite my miscalculation, I was able to rectify the situation quickly; I have already updated the app to support 10.7+ and I am happy to say that the updated version has been live for several days now.

Critique #2: No Pasting Passwords?
This one caught me a little off guard but really it shouldn’t have looking back. You see I have this odd habit of memorising long passwords, so typing them out is a pretty routine task. Most sane people, however, are using something like LastPass or a similar tool. I am happy to report that I have an update to Code Journal in testing that does allow the pasting in passwords and, unless any issues are found, that version will be pushed live early this coming week.

Critique #3: No App Store Version?
If you are a Coder Radio listener (and you should be), you will know that I am doing something of an experiment with Code Journal. Basically, I have not released it on the Mac App Store intentionally to see how that would affect sales and what (if any) feedback I would get regarding its distrobution. Before I mention what feedback I got I should say that this was the single most common critique of the app. In short, a lot of people have a strong preference to get all of their apps from the Mac App Store and do not want to purchase apps from a website. This is good news for Apple, but bad news for devs; I still hold that there is significant value in having a direct relationship to the users of your apps and the delays caused by Apple review process (22 days for Code Journal’s first binary) can be incredibly damaging if your strategy is to build and iterate rapidly. Assuming that the feedback I received is representative of the greater Mac user ecosystem, it seems that the Mac App Store will soon be the only feasible portal via which to sell apps; barring games that might do well in Steam.

Critique #4: What is Gumroad and Why Isn’t It PayPal?
This is another one that really surprised me, but it seems that there a lot of users who are not really comfortable entering their credit card data into Gumroad. Taking a high level look at my data I have x sales but x * 30 sales have ended right at the checkout screen. Think about that for a minute. The vast majority of people who like the info page enough to click “buy now” got all the way through the checkout process and turned back at the final checkout screen. The data aside, I have heard from several people that they or others close to them were not comfortable with entering the credit cards into Gumroad and would strongly prefer that I switch to PayPal. So why Gumroad at all? Well, they do a lot for me for the same cost as PayPal including verifying receipts, sending app updates to users, and a number of other small things that I would have to implement myself with PayPal. I am still considering how to handle this issue.

Bottom Line
In many ways I feel direct distribution has been incredibly successful, mainly because it allowed me to react quickly to user feature requests (back porting to Lion etc), however, the Mac App Store issue is a troubling one; if the percentage of Mac users who strongly prefer to purchase apps via the Mac App Store continues to grow, developers will have little choice but to conform to the somewhat draconian sand-boxing policies of the Mac App Store. Having said that, I am not against distributing Code Journal via the Mac App Store. In fact, if the numbers continue as they have (numerous users declining to purchase until an a version is on the store), then I probably am not going to have much of choice.

Comments? Questions? Find me on Twitter or Google+.

Bad Synchronous Call! Bad!

Back in the dark old days of Commodore 64 and its brethren computers were pretty much all synchronous; instructions executed one after the other, one at a time. It was a simpler time. Users did expect a responsive UI during slow operations or so I have been told. Wondering what a slow operation is? Well, how about any sort of IO? or large data transfer? or how about just pretty much any data transfer over 3G? Of course, there are other cases of long operations but no need to open old wounds….

Now I can hear you already, arguing ‘the platforms today are so much more multi-threaded / multi-core by default I don’t have to worry about writing asynchronous code.’ Well sir (or madam), you are dead wrong. It is true that or more modern platforms have done a lot to run their internal operations in a thread safe / optimized way, but there are a lot of cases where YOU MUST make your code asynchronous. The platform is not going to waive a magic wand and make your operation run asynchronously. Need an example? Here you go:

UIImage* image = [UIImage imageWithData:[NSData dataWithContentsOfURL:someURL]];

Looks reasonable, no? Wrong! That code though deceptively simple is actually very bad. Let’s take a look at what is actually happening in this little one liner:

NSData* imageData = [NSData dataWithContentsOfURL:someURL];
image = [UIImage imageWithData:imageData];

Still pretty simple, right? That’s the exact same functionality as the one linear above and the same problem. Take a closer look at that first line. Pretty simple, right? All it is doing is reading the contents of a URL (in this case an image) downloading the data, and creating an NSData object from it. See the problem yet? That is all happening in order synchronously. If the network is slow or the server is slow to return, the UI on your lovely app will lock for a second or so. Bad UX. Very bad. It is important to note that this code is using one of the most direct ways to create an image from an external service provided wholly by Cocoa. Not to hit this too hard, but the platform vendor’s framework (Cocoa in this case) is not doing anything magical to prevent this from happening. Your code is causing the problem and you have to fix it — yourself.

Oh? You actually want to see a correct version of this code? Well, ok. What needs to happen here is that the image needs to be dealt with asynchronously. I like to use the popular (albeit somewhat dated) iOS / Mac library ASIHTTP to accomplish this. For one request it is really easy:

ASIHTTPRequest* request = [ASIHTTPRequest requestWithURL:someURL];
__weak ASIHTTPRequest* _request = request;
[request setCompletionBlock: ^{
UIImage* image = [UIImage imageWithData:[_request responseData]];
}];
[request setFailedBlock: ^{
// handle failure
}];
[request startAsynchronous];

Not too bad, right? Just a quick walkthrough. If you are new to Cocoa you might not be familiar with the concept of blocks. It’s a pretty big topic and worthy of its own post (or series of posts) but they are similar to closures in other languages. Also, the “__weak” is to prevent a retain cycle for developers using ARC; if you are not using ARC in your new iOS or Mac OS X projects, consider it. Ok so what if you have to deal with a large number of images for something like a UITableView full images? Well check this out:

ASINetworkQueue* q = [[ASINetworkQueue alloc] init];
[q setDelegate:self];
[q setQueueDidFinishSelector:@selector(networkQueueDidFinish:)];
[q setRequestDidFailSelector:@selector(requestDidFail:)];
[q setRequestDidFinishSelector:@selector(requestDidFinish:)];
for (int i = 0; [someArrayOfImagesURLS count]; i++) {
ASIHTTPRequest* imageRequest = [ASIHTTPRequest requestWithURL:[someArrayOfImagesURLS count]];
[q addOperation:imageRequest];
}
[q go];

// delegate methods
- (void) requestDidFail:(ASIHTTPRequest *)request {
// something bad happened -- handle it!
}

- (void) requestDidFinish:(ASIHTTPRequest *)request {
UIImage* image = [UIImage imageWithData:[request responseData]];
// do something with the image
}

- (void) networkQueueDidFinish:(ASINetworkQueue *)q {
// do something magical when the queue is done
}

Ok so all that has changed is that we iterate through an array or URLS for the images, create ASIHTTPRequests based on them, add them to our operation queue, and deal with the delegate methods. One thing of note is that there are separate callbacks for when each individual request finishes and for the queue itself and if you fail to implement one of those required delegate methods your app will crash.

Hope this helps someone. I am going to be posting more about writing asynchronous code to best take advantage of the multi-threaded / multi-core nature of our favorite platforms. Stay tuned for a look at this type of thing on Android! Find me on Google+ or Twitter if you have feedback.


Programming Pitfalls: Bit in the ARC

Apple’s ARC (automatic reference counting) for Mac and iOS devices is intended to make Cocoa development easier. For the most part it does. However, in using it I have encountered a bit of a pitfall: by default the compiler does not optimize your code in debugging but uses its most optimized setting for release.  What does this mean? Well, the more you tell it to optimize your code, the sooner it will release objects for you, which can lead to some issues. To be clear the default settings for each mode are zero optimization and the most possible optimization respectively.

Basically,  a lib I was using was working fine in testing but was throwing BAD_ACCESS errors when running in release mode. After over an hour and half of investigating I found:

The screenshot is showing XCode’s “Build Settings” screen, where you can clearly see that a different level of optimization is being used for the two different modes.

From here the fix is pretty easy: tune down that optimization level. Alternatively, you could dig into the code that is having the issues, but that might turn out to be something of a premature optimization for most needs.

Hope this helps someone. You can find me on Twitter or Google Plus.

NSTask 100

I’ll get right to the point here. Reinventing the wheel is bad. Period. End of sentence. If you have a requirement that can be met by an acceptably licensed open-source software project and you are not using that project, then you are likely adding unneeded complexity to you project; you are certainly adding development time and therefore cost to the project.

Recently, I have been spending a lot of time developing an internal Mac OS X application for a client. This is a large scale application that has a lot of very specific requirements; these requirements range for media conversions to data sorting. After spending a little time trying to create my own internal Objective-C classes for many of these functions, I started wishing that I could just call down to OS X’s underlying UNIX utilities.

Then I remember something that I had read in a Cocoa book almost a year ago: NSTask. I popped open Dash and got to reading the documentation on this awesome class. Basically, you can use NSTask to call down to a UNIX utility, pass it parameters as you would from the terminal, and deal with its output.

Let me show you an example of how this would work with one of my favorite GPL’d tools: LAME.

NSTask* lameTask = [[NSTask alloc] init];
[lameTask setLaunchPath@”PATH_TO_LAME”];
[lameTask setArguments:[NSArray arrayWithObjects:@”CRAPPY_AUDIO_FILE.wav”, @”NEW_AWESOMENESS.mp3”, nil]];
[lameTask launch];
<

That’s it. It really is that simple. Keep in mind that for this to work the user needs to have LAME installed on his box already for this to work and distributing GPL’d software with proprietary software can be legally jeopardizing, so read those licenses. Also, MP3 is an IP encumbered format and I am not suggesting that you should violate IP by using the above code; I am only using it as a fun and easy to understand example of using NSTask to call a UNIX tool/

I hope this helps somebody out, if you have any questions or comments, please let me know or comment below.