Blog Archives

The Mac App Store is here, and is now up and running on all three of my Snow Leopard-sporting machines. As you might expect, the experience is very much like what you get from the iOS App Store. But the Mac version has its differences, too.

First, let’s talk about the similarities. The Mac App Store looks a lot like the iOS version, especially the one you find on the iPad. Like the iOS App Store, the Mac store requires you to have and sign-in with an active Apple ID. You’ll need this to purchase and download free apps from the store, though your account doesn’t have to be associated with a credit card if you want to just download free apps or use iTunes gift cards. Promotional codes appear to also work, if you can get your hands on some.

Purchasing apps works much the same as on an iOS device, too. You click the item’s price and it will ask you for your Apple ID credentials, or begin downloading immediately if you’ve recently provided them, triggering an animation of the app’s icon jumping to your dock. Every app you download from the App Store will appear in the dock by default, though it actually resides in your Applications folder. There’s no way to turn this off, since the App Store lacks a preferences menu, but you can always just drag icons out of the dock after the fact. The app’s icon will show a loading bar as it downloads and installs, and will appear as normal once the operation is complete and you’re free to use it.

The fact that there is so little you can customize or change about the Mac App Store is indicative of the direction Apple seems to want to go with software. As with iOS, the goal is probably to provide a surface-level simplicity that reduces potentially confusing menu items to the absolute minimum.  Many third-party apps that launched with the App Store seem to share this design philosophy, too.

Since the Mac App Store lacks its own dedicated preference menu, I initially thought users couldn’t limit access to it in the way they could the iTunes and iOS App Stores. Not so, since Mac App Store restrictions can be set using Parental Controls, found in OS X’s System Preferences, as shown in the screenshot below.

One of the best carry-overs from the iOS version of the App Store is the ability to install software on multiple machines. Software purchases on my iMac can easily be installed on my MacBook Pro or Mac mini just by “purchasing” it again on each of those machines with the same Apple ID. Alternatively, you can hit the “Purchased” icon at the top of the App Store interface to check what you’ve bought, and an install option will appear if you don’t yet have it on the machine you’re using. Unfortunately, you can’t transfer purchases from your iOS device to your Mac, so if you bought Angry Birds on your iPhone and your iPad, you still have to buy it again for OS X.

Note that only apps you purchased through the Mac App Store have this ability. While the App Store will recognize that you have iWork or iLife apps installed from before, for instance, trying to purchase these on other computers will actually result in a charge to your account, not just a free re-download.

One big difference many iOS users will notice is in pricing. Mac App Store prices tend to vary much more than those for iPhone and iPad apps, and tend not to reside around the $0.99 mark. Around $20 to $30 seems to be fairly common, and some software climbs as high as $80 or even $150. For now, at least, the introduction of the iOS model of software distribution hasn’t led to a similar pricing model.

I’ve yet to experience updating an app, since everything I’ve purchased so far is already up-to-date, but I suspect it won’t differ all that much from updating apps on the iPhone or iPad. And while it’s early days yet, I think the Mac App Store will be a success for Apple, considering I’ve already bought around three times more OS X software than I have during the past three months combined. How about you?

Related content from GigaOM Pro (sub req’d):

• How to Market Your iPhone App: A Developer’s Guide
• Mobile App Developer Survey: Profiles, Platforms and Monetization
• App Developers: Are You Ready for HTML5 and Metered Data?

If you have files on your Mac you don’t want others to have access to, the simplest way to secure them is to create an encrypted Apple disk image. An Apple disk image is a single file that can be mounted by OS X as a drive. You can create new blank disk images, which bear the familiar .dmg file extension, on a Mac using Disk Utility.

1. Open Disk Utility (located in Applications>Utilities) and select File>New>Blank Disk Image from the menu bar.
2. Under “Save As,” enter the desired filename for your .dmg. Enter a name for the disk image (this is what will appear in your source menu when it’s mounted) and choose the size of the disk you want to create.
3. Keep the format set to the default: Mac OS Extended (Journaled)
4. Go ahead and set the encryption to 256-bit AES
5. Set Partitions to Single partition – Apple Partition Map
6. For Image Format, choose read/write disk image

When you click Create, you’ll be prompted to set a password for the file you’ve created. If you click on the key image next to the password field, a Password Assistant will pop up to help you create a strong password. Choose Memorable and a long length (the max length of 31 characters is most secure), and the Password Assistant’s autogenerated password will be very hard to guess using a software program (the level of security is similar to that of a Captcha, the word-generating fields used to determine whether a visitor is human or not).

Dragging data to your disk image when it’s mounted will copy it to the .dmg. Once you eject the disk image, you’ll need to enter your password to mount the image again and access your files. If the .dmg file is unmounted (ejected), people who don’t have access to your password won’t be able to get the data within. You can securely mount the resulting .dmg file from any Mac. If you decide to remember the password in your Mac’s Keychain (the password prompt will ask you if you want to do this), keep in mind that anyone else who has access to the user account that keychain is associated with will also have access to the files within.

This technique is particularly useful when preparing taxes or hiding the electronic trail of receipts and correspondences related to a special gift you want to keep secret from tech-savvy nosy kids this holiday season.

Related content from GigaOM Pro (sub req’d):

• Five Things Needed for a 48 Million iPad Market
• How to Reach Mobile Shoppers This Holiday Season
• 4 Ways Technology Will Change Black Friday

Apple today released iOS 4.2 for the iPod touch, iPhone and iPad, and iOS 4.1 for Apple TV. Together, the updates allow you to use the new AirPlay feature to stream audio and video content from your device to your television. It sounds like a killer feature, but does it live up to the hype? NewTeeVee certainly doesn’t think so, but AirPlay does have its good points.

It will depend largely on what you want to be able to do with AirPlay. Right now, it does two basic things pretty well: It streams photos from your on-device camera roll or Photos app to the Apple TV; and it streams audio and video from both the built-in YouTube app and the on-device iPhone or iPad-formatted video library. What it doesn’t do is transmit any video and audio content you come across to an Apple TV-connected display.

No third-party (downloadable) apps I tried had support for streaming video to the Apple TV yet (I tried the HGTV app, CityTV’s iPad app and Air Video). Audio streaming, on the other hand, seems built-in everywhere (works on HGTV, TuneIn radio, and with web-based content). Whether that means that audio streaming works without developer intervention, while video streaming must be programmed in, or whether third-party software will only have very limited access to video streaming isn’t yet clear.

Even if Apple does allow third-party programs to stream video, there will be some limitations. The video being streamed must be in a format the Apple TV can recognize, for example, since AirPlay just pushes the content from the iOS device to Apple’s set-top box, and there’s no processing involved. So .MKV files, a common format for HD video, won’t likely ever be able to be streamed from the VLC app, for instance. It also doesn’t work with home video recorded on your device, which seems like something I’d probably do most with the feature, were it available.

As for what it does provide, there are some limitations that show it’s early yet for the AirPlay tech. First, YouTube videos take quite a while to load before playing, at least in my experience. I thought it wasn’t working properly, in fact. Second, when streaming photos, there’s quite a delay, and no indicator there’s any kind of loading in progress before the image shows up on your screen. I was swiping through my library thinking photos didn’t stream when all of a sudden the first one I’d viewed showed up. The experience of many others on Twitter confirms that I’m not alone in this.

Devices using iOS can still run other apps while streaming content to the Apple TV, so that’s a huge benefit. You can check your email or play games while a movie broadcasts in the background, for instance, and you can control playback on either your portable or using the Apple Remote with your Apple TV. Also, content will display a TV as the AirPlay icon when it can stream video, and a speaker icon when it can only transmit sound, so you know at a glance what you’ll be getting.

For now, AirPlay remains a nice feature, but one that’s in its infancy. To truly have a wide appeal, I think it needs to be extended to third-party applications, and work better and faster while keeping user surprises to a minimum by telling users exactly when it’s loading. Apple also needs to seriously consider making this a two-way street, since being able to stream from iTunes libraries to an iOS device without having to install additional, unofficial software would be fantastic. Of course, it would also limit the appeal of larger on-device storage sizes, which is likely why it’s being ignored by Cupertino.

If AirPlay was the reason you were waiting to make an Apple TV purchase, I’d wait a little longer to see how the tech matures in future iOS iterations. What do you think? Is AirPlay in its current form grounds enough to justify buying the new Apple TV?

Related content from GigaOM Pro (sub req’d):

• Five Things Needed for a 48 Million iPad Market
• Report: The Live-Stream Video Market
• Report: The Connected TV Marketplace

As many of you may have seen in recent weeks, Twitter changed its access policies and now requires OAuth from all third party applications that access Twitter user accounts. This is a large change from how many iPhone developers having been incorporating Twitter into their applications. What is OAuth exactly? How can iPhone developers get their apps up to date so they don’t break their Twitter incorporation? Well we have all the info you need to know about the OAuth-Apocalypse.

What is Oauth?

Twitter has a brief explanation of the difference between Basic Authentication and OAuth. They use the example of a letter and how it is addressed as their metaphor, and I think this gets the idea across clearly. You can see their entire explanation along with pros and cons here.

TL;DR With Basic Auth you would make every request and would include a username and password with each. This method is very insecure because it allows applications to actively hold user’s credentials and does not have any accountability for which application is performing what action on who’s account. If you imagine your Twitter account as a room, this is like having access to the room be granted based on a single key that many people have copies of. OAuth makes access to your room be granted by a key pad. And everyone that has access to the room has a different code they input into the keypad. You can see who came in and when and revoke anyone’s code at any time.

Twitter is evolving and now requiring that applications register. As a result, user’s gain more control over what services have access to their account. Additionally, Twitter can be more effective at targeting malicious applications, and developers can get more accurate feedback on the frequency of their app’s use throughout Twitter. With all this said, OAuth is tough to implement from scratch. So today we are going to go through the installation and use of a collection of classes that takes care of the dirty work for us, and let developers update the Twitter functionality of their application easily.

Required Classes

Today we are going to be building off a collection of classes that were created by several different people. The main portion of the class is the MGTwitterEngine which was created by Matt Legend Gemmell who’s website can be found here. From here, Ben Gottlieb took the classes and added his own drop in view controller to them. With all this together we have a simple view controller that will perform login and OAuth, and from there an engine that will perform any type of Twitter request we are looking to do. You can get a zip file of the root folder that contains all of these files here.

Installation

We are going to start out with a blank, view based iPhone project called iCodeOAuth. Once the project has come up, take the folder you downloaded called “Twitter+OAuth” and drag it into the “Other Sources” folder within Xcode. Make sure you check the box to copy the sources into the project folder. If we do a build now, you will get a ton of errors. That is because these classes require that libXML be a target of the project build as well. This can be accomplished by clicking the arrow next to Targets in the left column of the Xcode project. Here there will be an application called iCodeOAuth. If we right click on this and select Get Info we will see the info about our target. From here we click the build tab and search for the field “Header Search Paths”. You need to add the following into the Header Search Paths:

$(SDKROOT)/usr/include/libxml2

EDIT: I forgot to include here that you must also include a special XML library for the build to be successful. The Framework is called libxml2.dylib. You can find it at

/Macintosh HD/Developer/Platforms/iPhoneOS.platform/Developer/SDK/iPhoneOS4.1SDK/usr/lib

If you build again, you should see no errors and we can move forward with using this awesome set of classes.

Getting your Creds from Twitter

Now that we have these classes properly installed, it is time to take care of some registration requirements for OAuth. In order to use OAuth you must identify your app to Twitter. Once you do so, Twitter will provide you with an OAuthConsumerKey and an OAuthConsumerSecretKey. These are going to need to be provided to the classes we have just added into our project in order to talk with Twitter’s OAuth system. To register your application and get these creds go to dev.twitter.com/apps/new. I have created a application called the iCodeBlog OAuth Demo, whose credentials are included in the sample app which I have provided. For your own personal app you will need to go create your own Twitter Application and get your own keys.

Using SA_OAuthTwitter Engine

Ben Gottlieb used a great design pattern to create a very easy to use access point for the more complex MGTwitterEngine which lies underneath. In order to use these classes we will go into out view controller and add the following code to the header:

#import "SA_OAuthTwitterEngine.h"
#import "SA_OAuthTwitterController.h"
 
@interface iCodeOauthViewController : UIViewController  {
 
	IBOutlet UITableView *tableView;
	IBOutlet UITextField *textfield;
 
	SA_OAuthTwitterEngine *_engine;
	NSMutableArray *tweets;
}
 
@property (nonatomic, retain) IBOutlet UITableView *tableView;
@property (nonatomic, retain) IBOutlet UITextField *textfield;
 
-(IBAction)updateStream:(id)sender;
-(IBAction)tweet:(id)sender;
 
@end

And add the following into the Main

- (void)viewDidAppear:(BOOL)animated {
 
	if(_engine) return;
 
	_engine = [[SA_OAuthTwitterEngine alloc] initOAuthWithDelegate:self];
	_engine.consumerKey = @"PzkZj9g57ah2bcB58mD4Q";
	_engine.consumerSecret = @"OvogWpara8xybjMUDGcLklOeZSF12xnYHLE37rel2g";
 
	UIViewController *controller = [SA_OAuthTwitterController controllerToEnterCredentialsWithTwitterEngine: _engine delegate: self];
 
	if (controller)
		[self presentModalViewController: controller animated: YES];
	else {
		tweets = [[NSMutableArray alloc] init];
		[self updateStream:nil];
	}
}

This will instantiate our engine with the appropriate consumer and consumer secret keys. With this done we will create a controller. If you run the app now you will see a modal web view come up and lead to a sign in page for Twitter. This is a web view, but the great classes written by Ben are set up to programmatically handle the progression of these web views as the user signs in.

Scrolling to the bottom of this page there will be a username and password field to fill out. Don’t put in your Twitter credentials yet. We need to fill out a few delegate methods to handle the callback from SA_OAuthTwitterEngine.

Handling Login Callbacks

Insert the following into your main class.

 
-(IBAction)updateStream:(id)sender {
 
}
 
-(IBAction)tweet:(id)sender {
 
}
 
#pragma mark SA_OAuthTwitterEngineDelegate
 
- (void) storeCachedTwitterOAuthData: (NSString *) data forUsername: (NSString *) username {
 
	NSUserDefaults	*defaults = [NSUserDefaults standardUserDefaults];
 
	[defaults setObject: data forKey: @"authData"];
	[defaults synchronize];
}
 
- (NSString *) cachedTwitterOAuthDataForUsername: (NSString *) username {
 
	return [[NSUserDefaults standardUserDefaults] objectForKey: @"authData"];
}
 
#pragma mark SA_OAuthTwitterController Delegate
 
- (void) OAuthTwitterController: (SA_OAuthTwitterController *) controller authenticatedWithUsername: (NSString *) username {
 
	NSLog(@"Authenticated with user %@", username);
 
	tweets = [[NSMutableArray alloc] init];
	[self updateStream:nil];
}
 
- (void) OAuthTwitterControllerFailed: (SA_OAuthTwitterController *) controller {
 
	NSLog(@"Authentication Failure");
}
 
- (void) OAuthTwitterControllerCanceled: (SA_OAuthTwitterController *) controller {
 
	NSLog(@"Authentication Canceled");
}

We just implemented the SA_OAuthTwitterControllerDelegate and the SA_OAuthTwitterEngineDelegate. The SA_OAuthTwitterEngineDelegate methods take care of storing the OAuth data string in a plist so that when the app is launched again the user will not have to sign in. SA_OAuthTwitterControllerDelegate methods are callbacks depending on what happens upon sign in. In this case when sign in is successful another method in our class called updateTweets will fire. For now we have those methods defined but we don’t have them filled in. We will get to that in a few steps. If you run the application and login using some Twitter credentials, you should see a successful authentication message appear in your debug screen. With this done, let’s add some interface elements to our view controller XIB so that we can start interacting with Twitter. Our final product is going to look like this:

Building the Interface

To Build the interface open up the XIB for your view controller. We are going to be putting in 2 buttons, a UITextField and a UITableView. Lay the elements out like so.

Make sure to connect the delegate and data source of the table view to the file owner. Also connect the “Tweet This” button to the tweet method and the Update Tweets method to the updateStream method. Finally, make sure the IBOutlets for the UITextField and the UITableView are set. With these in place we can fill in the final methods to take advantage of our Twitter engine.

Filling in our IBActions

Put the following code in for the IBActions which we defied before.

#pragma mark IBActions
 
-(IBAction)updateStream:(id)sender {
 
	[_engine getFollowedTimelineSinceID:1 startingAtPage:1 count:100];
}
 
-(IBAction)tweet:(id)sender {
 
	[textfield resignFirstResponder];
	[_engine sendUpdate:[textfield text]];
	[self updateStream:nil];
}

The update stream method will ask our engine to get the Twitter timeline of the people you follow. It will retrieve the first page of the first 100 tweets. There is a delegate method that fires off on this request completing that we will fill out in a moment. The tweet method dismisses the keyboard and then uses our engine to send an update. Once the update is send we update the tweet view below.

Making a really simple Tweet Object

To help us with displaying tweets we are going to make a very quick Tweet object. This will be a simple NSObject subclass. Use this code for the header:

@interface Tweet : NSObject {
 
	NSDictionary *contents;
}
 
-(NSString*)tweet;
-(NSString*)author;
 
@end

And this code for the main

@implementation Tweet
 
-(id)initWithTweetDictionary:(NSDictionary*)_contents {
 
	if(self = [super init]) {
 
		contents = _contents;
		[contents retain];
	}
 
	return self;
}
 
-(NSString*)tweet {
 
	return [contents objectForKey:@"text"];
}
 
-(NSString*)author {
 
	return [[contents objectForKey:@"user"] objectForKey:@"screen_name"];
}
@end

Finally make sure to import the class within the main of your view controller class. These will simply give easy methods to get the info we want out of each tweet dictionary that the MGTwitterEngine will return to us.

Filling in our MGTwitterEngineDelegate Methods

The MGTwitterEngine is doing most of the heavy lifting here when it comes to interacting with Twitter. The methods we are using to get tweets and to send tweets are all defined within the MGTwitterEngine. There is also a defined MGTwtterEngineDelegate which defines the callback methods that fire upon these requests finishing. For the sake of completeness, I have filled out all the methods, although only a few of them will be called in the case of our application working properly. Insert the following code into your main.

#pragma mark MGTwitterEngineDelegate Methods
 
- (void)requestSucceeded:(NSString *)connectionIdentifier {
 
	NSLog(@"Request Suceeded: %@", connectionIdentifier);
}
 
- (void)statusesReceived:(NSArray *)statuses forRequest:(NSString *)connectionIdentifier {
 
	tweets = [[NSMutableArray alloc] init];
 
	for(NSDictionary *d in statuses) {
 
		NSLog(@"See dictionary: %@", d);
 
		Tweet *tweet = [[Tweet alloc] initWithTweetDictionary:d];
		[tweets addObject:tweet];
		[tweet release];
	}
 
	[self.tableView reloadData];
}
 
- (void)receivedObject:(NSDictionary *)dictionary forRequest:(NSString *)connectionIdentifier {
 
	NSLog(@"Recieved Object: %@", dictionary);
}
 
- (void)directMessagesReceived:(NSArray *)messages forRequest:(NSString *)connectionIdentifier {
 
	NSLog(@"Direct Messages Received: %@", messages);
}
 
- (void)userInfoReceived:(NSArray *)userInfo forRequest:(NSString *)connectionIdentifier {
 
	NSLog(@"User Info Received: %@", userInfo);
}
 
- (void)miscInfoReceived:(NSArray *)miscInfo forRequest:(NSString *)connectionIdentifier {
 
	NSLog(@"Misc Info Received: %@", miscInfo);
}

These methods are all very straightforward in their naming. The only one we fill out significantly is the statusesReceived:forRequest method. Here is where tweets will be returned to us, each as a separate dictionary when we request the timeline for a user. We will clear the tweets array that we have defined for our class and create a Tweet object for each of the dictionaries we have representing a tweet. From there we will ask our table view to reload. The only task we have left to perform is to fill in our table view data source methods to show all the tweets.

Table View Data Source and Delegate Methods

Now we have everything in place. We just need to create a UITableViewCell for every tweet we have. We will also do some tweaking of the size of each cell and the number of lines of each UITextField within each table view cell. These methods are very common so I wont go into much detail on them. Here are the necessary Data Source and Delegate Methods.

#pragma mark UITableViewDataSource Methods 
 
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
 
	return [tweets count];
}
 
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
	NSString *identifier = @"cell";
	UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];
 
	if(!cell) {
 
		cell = [[UITableViewCell alloc] initWithStyle:UITableViewStyleGrouped reuseIdentifier:identifier];
		//[cell setBackgroundColor:[UIColor clearColor]];
	}
 
	[cell.textLabel setNumberOfLines:7];
	[cell.textLabel setText:[(Tweet*)[tweets objectAtIndex:indexPath.row] tweet]];
 
	return cell;
}
 
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
 
	return 150;
}

With this in place you will have an OAuth twitter client that is capable of doing any type of interaction with Twitter. You can find the source for the project here. Please post any questions you have and happy coding!

Follow me on Twitter at @cruffenach

The ZumoDrive folks are at it again, but this time, they’re taking the cloud storage to your home computer so you can stream media files right to an Apple iPad using ZumoCast. The new ZumoCast service is a take on my “personal cloud” thought — instead of storing data on a third-party web server, ZumoCast shares the files already on your PC or Mac. You just tell ZumoCast which files or folders you want remote access to and the software does the rest. The company is wise to go after the iPad market since the device makes for a great mobile media player.

DRM-protected files won’t play on an iPad or iPhone using ZumoCast, but that’s about the only major limitation aside from requiring your home computer to be powered on. However, you can sync media files with ZumoCast for offline playback on a mobile device — in that case, the home computer can be sleeping peacefully. The ZumoCast desktop software handles all file-sharing aspects and it supports adaptive transcoding. That means the audio and video quality will adjust on the fly to offer the best experience based on your web connection.

Initially for iPad and iPhone, ZumoCast is planned for additional mobile platforms. That makes sense as ZumoDrive, the cloud storage service, is also supported on Google Android and Palm webOS handsets. The company also says that “video sharing and enhanced music and photo interfaces” are in the works. ZumoCast is in an open beta, so you can sign up to try it. At this time, no pricing has been announced for the media streaming service.

Related research on GigaOM Pro (sub req’d):

• Who Will Design Your Private Cloud?
• Forget Syncing, Let’s Put Music in the Cloud!