Tag Archive for Mac

WWDC 2012 Keynote Let Down

Earlier today I hosted Coder Radio with Chris Fisher of Jupiter Broadcasting and in the episode we discussed my reactions as a developer to the WWDC keynote this year (2012). First things first. I did not attend WWDC nor have I installed the iOS 6.0 developer release, so some of my information may be incomplete; I have to do this in this way due to Apple’s developer NDA. You can listen to the show to hear what I didn’t like, but I’d rather go through a few things that I would like to have seen that to my knowledge aren’t coming.

Inter-app Communications
This is by far my largest pet peeve with iOS development and using iOS. Why isn’t there are robust way for apps to work together and share data; within reason of course. Android has a version this in the form of “intents” and Windows Phone 7 has a incredibly powerful system called “contracts”. This really gets to me when I consider that iOS is a BSD system yet does not adhere to the UNIX philosophy of allowing many small applications to work together to do big things; yes, I know that iOS apps tend to be smaller in scope than their desktop counterparts but to date there is no real way for them to work together. There is so much functionality that cannot easily be done on iOS due to this restriction.

On my Android and Windows phone I can glance at the screen and get the latest tweets, view other data (such as a stock ticker), and play a song, or begin or pause listening to an audiobook. On iOS, almost all of those things require me to launch separate apps. That’s silly not to mention a bad user experience. I know there are definitely battery life concerns if you have too many widgets open, but there is no reason that Apple can’t add some sort of restricted mode for simple widgets to run in.

Siri integration
Ever since I got my hands on my 4S I have been waiting for a full Siri API. Apple has been working on it, but to date there is no fully functional Siri API for third party developers. This is understandable given how often Siri simply does not work but it is still a shame.

That’s all for now. Now I can finally take a look at the dev preview! For feedback please find me on Google+ or Twitter.

Review: Revolution in the Valley

Revolution in the Valley is the story of that first Apple development team that brought the world the Macintosh and in doing so changed computing history by making the computer a personal item focused on communication rather than computation.

Popular mythology portrays the development of the original Macintosh as a somewhat religious experience. In fact, that was not really the case. As with any large scale project there are problem, conflicts, and unforeseen bugs that raise both costs and tempers. Revolution in the Valley gives the reader what a more accurate account of the not only the development culture at Apple during its early days but also how large scale projects work in the really world when real people who don’t necessarily agree on the best ways to implement feature X.

As this is not a technical training or reference, there are really no prerequisites to reading but that does not mean that more experienced developers or even designers won’t get a lot out of the book; in fact, I always find it interesting to see how those early developers of the personal computer 1980’s  solved  complex technical issues with such limited hardware and software resources; after all there was no Github or BitBucket when the Macintosh was being developed.

In short, I would recommend this to anyone who works on or will be working on larger scale software projects.

For all the Apple haters, I know that my posts have been pretty Apple-centric for the last month or so, but I do have some interesting Android and other posts plans.

Tutorial: Recording Media with QTKit for Mac OS X

Mac’s are very popular among creative professionals ranging from the user interface designer who designed your favorite iPhone app to the starving videographer who is just starting to break into the field via Youtube and Vimeo.

Recently, I have taken the plunge into Mac OS X application development and had a need to implement a number of multimedia functionality into the application: recording video via a built in or external camera and recording audio via the built in or external microphone and a number of other things. One way to this with a minimum level of effort is to use Apple’s QTKit; for those not familiar with Apple technologies QT stands for Quick Time which is Apple’s entrant into the multimedia player space.

There are number of things that you can do with QTKit but I am only going to focus on recording video and audio for this post. Additionally, I am making some assumptions about you, my reader: I assume that you know how to add a framework to an XCode project, I also assume that you know at least a introductory level of Objective-C and will not providing samples of what I consider boilerplate code.

Ok, so let’s get to it. Once you have imported QTKit, open the header file the class that you want to deal with the recording and declare some variables like so:

QTCaptureSession* session;
QTCaptureMovieFileOutput* fileOutput;
QTCaptureDeviceInput* videoInput;
QTCaptureDeviceInput* audioInput;

You are also going to want to create an NSButton to receive a click from the user. Jump into your implementation file and it’s time to start using those objects and making some more to actually determine how capable the system is of recording media. The following code is probably best put in an awakeFromNib or some similar function:

QTCaptureDevice* videoDevice = [QTCaptureDevice defaultInputDeviceWtihMediaType:QTMediaTypeVideo];
if (videoDevice) {
videoInput = [[QTCaptureDeviceInput alloc] initWithDevice:videoDevice];

Ok, so what we’ve done here is create videoDevice and set it to refer to whatever the default video recording device is for the user’s systems; I would be willing to gamble that you will be dealing with the built in camera pretty much all the time, but even if some silly user out there is doing something well… silly QTKit does a good job of abstracting specific hardware concerns away. I’ve omitted a good deal of code from my implementation above that basically does some safety checks and checks to see if the once device that you have found can also do audio recording and if it can assigns it that duty as well. These checks are mostly BOOL checks and simple checks from the hasMediaType method.

Once you have your input device / devices configured it is time to actual configure how the media will be recorded:

QTCaptureConnection* connection;
NSEnumerator* enumerator = [[fileOutput connections] objectEnumerator];
while ((connection = [enumerator nextObject])) {
QTCompressionOptions* options = nil;
if (mediaType isEqualToString:QTMediaTypeVideo]) {
options = [QTCompressionOptions compressionOptionsWithIdentifier:@”QTCompressionOptions240SizeH264”];
} else If ...

Basically, all this code does is create a few objects and loop over some data (I know that’s a pretty hardcore oversimplification but from an implementation standpoint, that is all you really need to know) and then determine how to encode the data to be output. Again, I have shown the code for the video, but the code to encode the audio is very similar.

In the last code chunk I neglected to explain what fileOutput was. Simply put it is an object that, as its name suggests, represents the resulting data after it has been properly encoded. So using that object we can do:

[fileOutput setCompressionOptions:options forConnection:connection];
[session startRunning];

And there you go. Your output will know be encoded to whatever you set in the above loop, so if you kept my code, your video would be in H264. The last line of code should be self explanatory, so I am just going to move on.

Your fileOutput object has one more important job to do: determine where to write the resulting file or if to write it at all. Remember when I recommended that you create a button and an IBAction? Well, you are going to use it now. Put the following code in your IBAction:

[fileOutput recordToOutputFileURL:[NSURL fileURLWithPath:@”/Users/share/movie.mov”]];

Basically, all this does is tell you fileOutput object where to write its data. Fair warning, that last code sample breaks Apple’s new sandboxing rules for the Mac AppStore, so if you want to be in the Mac AppStore, you are going to have to write the data within your application’s own sandbox; see Apple’s developer docs for more details on the new sandboxing rules. Also, the keen eyed coder will notice that my samples require manual memory management, but I did not include and release statements. Be sure to manage your memory properly.

If you have any questions or comments, sound off in the comments. Additionally, I can be reached on Twitter @dominucco.