In this post I want to outline the most important features of the iOS Twitter and Accounts APIs and explain how to use them to write a decent Twitter client for your next app in very few lines of code. The full source code is available on Github for your convenience.

The Accounts and Twitter frameworks perform much of the heavy lifting required when talking to Twitter, such as

• Providing a secure local storage for user accounts, including their credentials
• Providing an easy way to sign API requests you send to Twitter. You no longer have to include code to handle OAuth or xAuth in your app - this has all been done by Apple for you
• Providing a basic UI for composing tweets, including switching the user account you tweet from, uploading images in a tweet and including your current location

Lots of free stuff, so let's have a look at how much (or little) code we actually need to write to tap this source of awesomeness.

Using the Accounts Framework to fetch the list of accounts

The Accounts Framework provides access to all Twitter accounts the user has added to their iPhone using the settings app. Currently, the Accounts Framework only supports Twitter accounts, but you'll soon realize it has been build so that it basically can be used to access any other kind of account in future releases. Maybe the next version of iOS will easy access to Google+ and Facebook accounts - we'll see.

To use the Accounts and Twitter frameworks, we need to add them to the project:

Add Accounts and Twitter frameworks to the project

Once that's done, we can use the Accounts framework to fetch the list of Twitter accounts on the device.

- (void)fetchData
{
  if (_accounts == nil) {
    if (_accountStore == nil) {
      self.accountStore = [[ACAccountStore alloc] init];
    }
    ACAccountType *accountTypeTwitter =
      [self.accountStore
        accountTypeWithAccountTypeIdentifier:ACAccountTypeIdentifierTwitter];
    [self.accountStore requestAccessToAccountsWithType:accountTypeTwitter
      withCompletionHandler:^(BOOL granted, NSError *error) {
      if(granted) {
        dispatch_sync(dispatch_get_main_queue(), ^{
          self.accounts = [self.accountStore
            accountsWithAccountType:accountTypeTwitter];
          [self.tableView reloadData];
        });
      }
    }];
  }
}

As many other new APIs that perform potentially blocking I/O, the Accounts framework uses blocks to execute your code as soon as the data you requested is available. When querying the accounts database, we can specify the kind of accounts we're interested in - ACAccountTypeIdentifierTwitter in our case. If we're granted access to the accounts database, we fetch the list of accounts using accountsWithAccountType:. As soon as we've got this list, we want to save it in a ivar / property and update the UI. Since there is no guarantee we're on the UI thread when our completion handler is run, we use dispatch_sync to ensure assigning the list of accounts and updating the UI is run on the UI thread (dispatch_get_main_queue() returns the GCD queue of the UI thread). For more information on blocks and Grand Central Dispatch (GCD) check out this excellent blog post.

Displaying the accounts in a UITableViewController is straightforward:

- (UITableViewCell *)tableView:(UITableView *)tableView
                          cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
  static NSString *CellIdent = @"Cell";
 
  UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdent];
  if (cell == nil) {
    cell = [[UITableViewCell alloc]
      initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdent];
  }
 
  // Configure the cell...
  ACAccount *account = [self.accounts objectAtIndex:[indexPath row]];
  cell.textLabel.text = account.username;
  cell.detailTextLabel.text = account.accountDescription;
  cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;
  return cell;
}

Displaying the public timeline of the selected user

When the user selects one of the accounts, we want to display a list of recent tweets for this selected account. We'll use TWRequest to fetch the list of recent tweets.

TWRequest is the centerpiece of the iOS Twitter Framework and relieves us of the burden of having to perform OAuth authentication and request signing on our own. In order for it to do this, we need to provide a reference to the account whose timeline we want to read. We also need to provide the URL of the Twitter API endpoint we want to access. While this might seem a little bit cumbersome at first, this allows us to access not only current API calls but also any new APIs Twitter might come up with in the future without requiring Apple to update the API. Pretty nifty.

- (void)fetchData
{
  TWRequest *postRequest = [[TWRequest alloc]
    initWithURL:
      [NSURL URLWithString:@"https://api.twitter.com/1/statuses/home_timeline.json"]
    parameters:nil
    requestMethod:TWRequestMethodGET];
 
  [postRequest setAccount:self.account];
  [postRequest performRequestWithHandler:^(NSData *responseData,
                                           NSHTTPURLResponse *urlResponse,
                                           NSError *error) {
    if ([urlResponse statusCode] == 200) {
      NSError *jsonError = nil;
      self.timeline = [NSJSONSerialization JSONObjectWithData:responseData
                                                      options:0
                                                        error:&jsonError];
      dispatch_sync(dispatch_get_main_queue(), ^{
        [self.tableView reloadData];
      });
    }
  }];
}

Again, we need to provide a completion handler which will be invoked as soon as the call to Twitter returns. As you can also see, we're using the same approach as before to make sure we update the UI from the UI thread. It's also interesting to see Apple provides us with their own JSON parsing framework - no longer do we need to integrate third party libraries to serialize / deserialize JSON data.

Sending Tweets

So far, we can choose a Twitter account from the list of Twitter accounts on our iPhone and display the home timeline of this particular user. But how about sending a tweet?

Sending tweets is really easy: you just have to instantiate a new TWTweetComposeViewController and display it - iOS will take care of the rest:

- (void)composeTweet
{
  TWTweetComposeViewController *tweetComposeViewController =
    [[TWTweetComposeViewController alloc] init];
  [tweetComposeViewController setCompletionHandler:
    ^(TWTweetComposeViewControllerResult result) {
    [self dismissModalViewControllerAnimated:YES];
  }];
  [self presentModalViewController:tweetComposeViewController animated:YES];
}

The completion handler is merely needed to dismiss the tweet composition view after the tweet has been sent.

Conclusion

Integrating Twitter in your own apps has never been easier. With just a few lines of code, we implemented a basic version of a Twitter client that you can use to display a user's home timeline and send tweets. Elaborating this code base is left as an exercise to you - feel free to fork the code on Github and send me pull requests as you add interesting features!

Here's an impression of the current state of the application:

Quite a number of my colleagues at itemis have been busy preparing for this conference in the past few weeks. Besides working hard to hit the Eclipse Release Train milestone for Indigo on June 22nd, the Xtext team brushed up their hands-on sessions "Xtext Take I: Creating Code Generators with Xtend2" and "Xtext Take II: Crafting Domain Specific Languages with Xtext and Xbase". If you've been using Xtext, you're well aware of the power you have at your disposal with this tool. Xbase and Xtend2, however, take this experience to a whole new level. So make sure to mark your calendar for these two sessions!

But not only the Xtext team will share their expertise at CG2011 - Markus and Karsten will be also be in town to give hands-on tutorials and report from their experience:

• Type Systems for DSLs (Markus Völter)
• Graphiti + Xtext: mixing graphical and textual DSLs for sprayers/designers (Karsten Thoms / Bernhard Merkle)
• Introduction to JetBrains Meta Programming System (MPS) (Markus Völter)

The finale of the conference will be a panel discussion hosted by Markus on the topic of "Models, DSLs, Transformations: The Next 5 years" - this should be a very interesting and lively discussion!

Heiko and I will present "Cross-Platform Mobile Development with DSLs" - a fast-paced and fun mixture of slides, live coding (or modeling, if you will), videos and audience interaction. Yes, that's right - the audience will be part of the show. Make sure to bring your web-enabled mobile phone and get the chance to win a price!

To keep track of the conference program(me), we at itemis mobile have been busy to create a conference planner for your iOS and Android powered mobile phones. Here are the download links:

• Apple App Store: Code Generation 2011
• Android Market Place: Code Generation 2011

Code Generation 2011 Apps for iPhone and Android

If you like the apps, please use the feedback feature of the respective store. Got comments or suggestions for improvement? Drop us a note or track us down at the conference (best chance to see us: come to our talk ).

In this post, I am going to focus on ways to filter data. We won't be looking at the UI side of things - this is something I'll do in a subsequent blog post.

Old-skool filtering

If you look at an arbitrary code base, chances are you'll sooner or later run into a piece of code similar to this one:

NSMutableArray *oldSkoolFiltered = [[NSMutableArray alloc] init];
for (Book *book in bookshelf) {
    if ([book.publisher isEqualToString:@"Apress"]) {
        [oldSkoolFiltered addObject:book];
    }
}

It's a straight-forward approach to filtering an array of items (in this case, we're talking about books) using a rather simple if-statement. Nothing wrong with this, but despite the fact we're using a fairly simple expression here, the code is rather verbose. We can easily imagine what will happen in case we need to use more complicated selection criteria or a combination of filtering criteria.

Simple filtering with NSPredicate

Thanks to Cocoa, we can simplify the code by using NSPredicate. NSPredicate is the object representation of an if-statement, or, more formally, a predicate.

Predicates are expressions that evaluate to a truth value, i.e. true or false. We can use them to perform validation and filtering. In Cocoa, we can use NSPredicate to evaluate single objects, filter arrays and perform queries against Core Data data sets.

Let's have a look at how our example looks like when using NSPredicate:

NSPredicate *predicate =
  [NSPredicate predicateWithFormat:@"publisher == %@", @"Apress" ];
NSArray *filtered  = [bookshelf filteredArrayUsingPredicate:predicate];

Much shorter and better readable!

Filtering with Regular Expressions

Regular Expressions can be used to solve almost any problem so it's good to know you can use them in NSPredicates as well. To use regular expressions in your NSPredicate, you need to use the MATCHES operator.

Let's filter all books that are about iPad or iPhone programming:

predicate = [NSPredicate predicateWithFormat:@"title MATCHES '.*(iPhone|iPad).*'"];
filtered = [bookshelf filteredArrayUsingPredicate:predicate];
dumpBookshelf(@"Books that contain 'iPad' or 'iPhone' in their title", filtered);

You need to obey some rules when using regular expressions in NSPredicate: most importantly, you cannot use regular expression metacharacters inside a pattern set.

Filtering using set operations

Let's for a moment assume you want to filter all books that have been published by your favorite publishers. Using the IN operator, this is rather simple: first, we need to set up a set containing the publishers we're interested in. Then, we can create the predicate and finally perform the filtering operation:

NSArray *favoritePublishers = [NSArray arrayWithObjects:@"Apress", @"O'Reilly", nil];
predicate = [NSPredicate predicateWithFormat:@"publisher IN %@", favoritePublishers];
filtered  = [bookshelf filteredArrayUsingPredicate:predicate];
dumpBookshelf(@"Books published by my favorite publishers", filtered);

Advanced filtering thanks to KVC goodness

NSPredicate relies on key-value coding to achieve its magic. On one hand this means your classes need to be KVC compliant in order to be queried using NSPredicate (at least the attributes you want to query). On the other hand, this allows us to perform some very interesting things with very little lines of code.

Let's for example retrieve a list of books written by authors with the name "Mark":

predicate =
  [NSPredicate predicateWithFormat:@"authors.lastName CONTAINS %@", @"Mark" ];
filtered  = [bookshelf filteredArrayUsingPredicate:predicate];

In case we'd want to return the value of one of the aggregate functions, we don't need to use NSPredicate itself, but instead use KVC directly. Let's retrieve the average price of all books on our shelf:

NSNumber *average = [bookshelf valueForKeyPath:@"@avg.price"];

Conclusion

The Cocoa libraries provide some very powerful abstractions which can make your life and that of the people reading your code much easier. It pays off to know about them, so go ahead and browse the Cocoa documentation and hunt for those gems!

Apple's NSPredicate programming guide provides an in-depth documentation for NSPredicate containing all the things I didn't cover in this post.

NSPredicate also plays an important role when querying data in Core Data, something we will need to have a look at in one of the next blog posts. Stay tuned!

Code

The code for this post is available on my github page: get forking!

All apps allow you to browse the program, select your favorite talks and get to know the speakers (with headshots so you recognise them in the hallways). We also have included maps of the convention center as well as Santa Clara.

For a first glimpse, watch our video:

As of today, both iPhone and Android users can download the apps from the Apple App Store respectively the Android Marketplace. Here are the links:

1. EclipseCon 2011 iPhone App
2. EclipseCon 2011 Android App

If you don't own an iPhone or Android, you can always use the HTML-only version of the conference program available at http://bit.ly/econ2011html.

The iPad and BlackBerry apps will be available soon, so stay tuned!

By the way, if you run a conference and are interested in having an app like this, get in touch with us.

What's wrong with this map?

Maybe you can better see what's wrong when I show you another screenshot, this time obeying the TOS:

With logo: well done!

Can you spot the difference? It's the Google logo!

The reason why it is not shown in the first screenshot is that the bounds for the map are not set correctly. In the offending version of my app, I used a piece of code similar to this one:

 
- (void)viewDidLoad {
  [super viewDidLoad];
  mapView = [[MKMapView alloc] initWithFrame:self.view.bounds];
 
  mapView.showsUserLocation=TRUE;
  mapView.mapType=MKMapTypeStandard;
  [self.view addSubview:mapView];
}
 

Nothing wrong with it, but it lacks one essential line:

 
- (void)viewDidLoad {
  [super viewDidLoad];
  mapView = [[MKMapView alloc] initWithFrame:self.view.bounds];
 
  mapView.autoresizingMask =
    (UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight);	
 
  mapView.showsUserLocation=TRUE;
  mapView.mapType=MKMapTypeStandard;
  [self.view addSubview:mapView];
}
 

So, next time you write an app that contains Google Maps, make sure the Google logo is visible. You can get the full source code for this example on my GitHub page.

The Unique Device IDentifier is a 40-digit number that uniquely identifies your iPhone or iPad. It's tied to your device, not to a SIM card you might (or might not, depending on the type of device) have inserted.

Here's how you can find this number and send it to your developer:

1. Connect your iPhone / iPad to your computer using the white USB connection cable.
2. Wait for iTunes to start up. If it doesn't start automatically, start it manually (Windows users will find it in the depths of the Start Menu, Mac users can use Spotlight to search for it).
3. Click on the name of your iPhone / iPad on the left-hand side of the iTunes Window:
4. Details about your device will be displayed in the main area of the iTunes window.
5. Find the label titled Serial Number. The serial number IS NOT the UDID!
6. Holding down the CMD (on the Mac) or the CTRL (on Windows) key, click on the label Serial Number
7. The label's title will change to Identifier (UDID:
8. Press CMD+C (on Mac) or CTRL+C (on Windows) to copy the UDID to your clipboard
9. Open a new mail, insert the UDID and a friendly message and send it to your developer.

Easy, isn't it?

Oh, and please do NOT send a screenshot of the UDID. You should know better now.

Until now, web developers didn't have access to the accelerometer sensor and the gyroscope sensor. With this week's release of iOS 4.2, this has changed and we can now use DeviceMotionEvent and DeviceOrientationEvent to determine the acceleration and orientation data of the phone.

Let's first determine whether the current browser supports device orientation sensing:

if (window.DeviceMotionEvent==undefined) {
}

We can then read the sensor data by registering the respective callbacks. Here's how you read the accelerometer's data:

window.ondevicemotion = function(event) {
  ax = event.accelerationIncludingGravity.x
  ay = event.accelerationIncludingGravity.y
  az = event.accelerationIncludingGravity.z
  rotation = event.rotationRate;
  if (rotation != null) {
    arAlpha = Math.round(rotation.alpha);
    arBeta = Math.round(rotation.beta);
    arGamma = Math.round(rotation.gamma);
  }
}

The gyroscope's data can be read like this:

window.ondeviceorientation = function(event) {
  alpha = Math.round(event.alpha);
  beta = Math.round(event.beta);
  gamma = Math.round(event.gamma);
}

I've put together a little demo that uses the sensor data to color some boxes on the phone's screen. Here's a short video showing it in action:

If you want to take it for a spin, open this URL in mobile safari on your phone: http://demos.peterfriese.de/gyro/gyro.html.

(image of Gyroscope by stop that pigeon! taken from http://www.flickr.com/photos/25312309@N05/2651042796/)

In April 2010, together with the release of iOS 4, Apple changed the terms of the iOS Developer Program License in a way which basically prohibited creating software for iOS using languages other than Objective-C, C, C++ or JavaScript:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Back then, pretty much everyone was sure this update to section 3.3.1 of the license really was just one strike in Apple's crusade against Flash. Adobe had been working on a tool called Flash Packager, which allows Flash designers to cross-compile their applications for the iPhone. While this must have been bad news for Adobe (they effectively needed to write off development costs for the entire development team working on Flash Packager), it posed a serious threat to companies whose business model relied upon creating iPhone apps using tools and languages other than Xcode and Objective-C. The future for Novell's Mono Touch, Appcelerator Titanium, PhoneGap and XMLVM/iPhone didn't look very bright.

No need to say there was quite an uproar and people came up with all sorts of creative interpretations of the terms stated in section 3.3.1 to avoid being rejected from the App Store.

Of course, if a monopolist starts endangering other, dependent companies, this soon will call the Federal Trade Commission to action. It doesn't come that much of a surprise Apple published a new, very relaxed version of the iOS Developer Program Agreement just a few days ago. The new version (which is publicly available at http://developer.apple.com/programs/terms/ios/standard/ios_standard_agreement_20100909.pdf does not limit the programming languages you may use to create applications for the iOS platform any more. In particular, section 3.3.1 now reads:

3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

You might think that a small paragraph in a license agreement doesn't mean that much, but I think the new section will fundamentally change the way we write software for the iPhone in the next few years. Let me explain:

The new section 3.3.1 means you may write iOS software using any language you like. Yes, ANY language - there is no if and when. This means you will not only be able to write iOS software in Objective-C (which is a great language as soon as you come to grips with it), but you will be able to use language like Java, Scala, Haskell, Ruby, etc. Some people are even dreaming of using REALBasic for iOS apps.

Vendors of tools such as Mono Touch, Titanium and PhoneGap will be glad, as their business models now have a solid foundation (well, Apple may of course change the license again but I doubt they'll ever restrict the usage of other languages again). Given the announcement on Adobe Labs, I guess we will very soon see Adobe release their highly acclaimed Flash Packager for iPhone (I don't think people will seriously use this tool to create data-driven applications, but it's probably a great tool to develop games. If you're a Flash designer / developer, that is).

For the development community at large, this is great news: freedom to choose the language that fits your needs best has always been a cornerstone of successfully creating great software. People have expressed their desire to use languages such as Haskell and Ruby to build iPhone apps. Rumor has it Apple engineers have even been working on a version of MacRuby for iPhone - there you go.

At itemis, we're very much into programming languages. We're even building our own language development toolkit to support development of programming languages - Xtext. With this toolkit, it is very easy to create your own domain specific programming languages (DSLs). In the past, we've mainly been using it to create languages for enterprise and web applications. We're also helping others to (re-)build languages such as SQL. Of course, Xtext is being used to build itself - isn't that nice? About one year ago, we started implementing a programming language tailored towards creating data-driven mobile applications for the iOS platform. We're not aiming at creating a language you can use to build arbitrary iOS applications. Instead, we're focussing on data-driven applications with a drill-down metaphor. Something you can find in many applications such as FaceBook, LinkedIn, Kayak and the like. Watch the following video to see it in action:

If you're interested in learning more about APPlause, get in touch with us by mail [heiko.behrens|peter.friese]@itemis.de, subscribe to our blogs and follow us on Twitter (@peterfriese, @HBehrens, @APPlauseDSL).

In a few years, I guess, Objective-C will be just one language among many others you can choose from if you want to build iOS applications.

But why would you want to write iOS applications in languages other than Objective-C? There are many reasons:

• Use the language you feel most comfortable with. Maybe Objective-C's square brackets look scary to you?
• Use the language you have most experience with. Maybe you're a company and have a tight schedule. Writing your application using the language your developers have the most skills in helps you to meet your deadline. In fact, a friend just recently told me they used Appcelerator "because we've got JavaScript and HTML knowledge in-house, but none of our developers had experience with Objective-C"!
• use the language you use for developing your backend system. So you've got this huge backend system written C#, running on the .NT platform. Why not write all the front-end code in C# as well?
• Maybe you're a start-up in the social media realm and your website is written all in Ruby and Ruby on Rails. So why not write the iPhone app in Ruby as well?

It all boils down to being more productive and ensuring better sustainability. Using the right tool for the job helps you to achieve a faster time to market. If you're able to use the same language on the frontend and the backend, this will help you to secure your investment in this technology.

Please note that I'm not saying you should by all means write your frontend and your backend using the same technology and language. The first and foremost question you need to answer is, "what's the right tool for this job". Being able to make a real choice will help you to give a better answer to this question.

Looking back on my experience with the various drawbacks and benefits of each of those development modes, I hereby recommend your next app be open sourced.
Here is why:

Reasons pro Open Source

We all heard it before, "Open Source will make the world a better place" - but why? Well, let me give you a few reasons:

First, by open sourcing your code, your code will become better. If everybody can see what your code looks like, you will do your best to make sure it's clean code. Jeff LaMarche calls this "coding as if everybody is watching". Clean code has less errors than quick-and-dirty code, so that's a good thing.

Enabling others to contribute will further improve your code. Should you decide to invite other developers to your project, you'll want to add some documentation to make it easier for them to get a jump start. Writing documentation will force you to think through your code and its overall structure. You might find you want to perform some refactorings before you actually let other developers work on your code. This will improve the quality of your code even more.

Enabling others to participate will make your app more attractive. Didn't you experience this before: the app you just downloaded is almost perfect - if it only had this one missing feature. For example, I really love TweetDeck for iPhone, but I'm dearly missing an Instapaper integration. If TweetDeck was open source, I would've added Instapaper integration to the code and submitted a patch to the creators of TweetDeck for the benefit of the entire user base. But unfortunately, TweetDeck is not open source - what a pity.

By building a team of skilled people, you'll be able to deliver more features in a shorter amount of time than you can ever hope to achieve if you work alone. Successful open source projects are made up of a bunch of gifted individuals with diverse skills. This is even more important for mobile applications, as you not only have to develop the code that makes your app work. You also have to create a great looking UI, so might need a great designer. If you want to promote your app on a website, you might also consider teaming up with a web designer.

Speaking of contributions, you might be a bit hesitant to let other people work on your code. That's alright. Usually, contributors do not get commit rights right away. Instead, you ask them to contribute to the project by submitting patches via your bug tracker (you do use a bug tracker, don't you?). This enables you to review their code before actually committing it to the code base. If you're not satisfied, let them know (in a friendly way) what you would like them to improve. If a contributor delivers a number of great patches in a row, you can consider to promote him/her to be a committer.

Reasons against Open Source

There are a few reasons why your next app maybe should not be open sourced:

Others might steal your ideas! I keep hearing this argument over and over again. Yes, if you open source your app, other developers might check out the code, re-brand it and sell it on the app store as their invention. Well, they can steal your ideas anyway - just by looking at your app and building an app that looks and feels the same. Granted, re-writing an app consumes considerably more time than re-branding an existing code base. But I doubt anybody dares to submit a blatant 1:1 copy of an app to the app store. At the very least, you should choose a suitable license for your code. There are a number of great open source licenses you might consider check out the Rob Rhyne even had his brother (who is a lawyer) create a new app-store compatible license for his app, Briefs. Read his blog post "Selling Open Source" for the rationale behind this step.

Even if other people don't copy your entire app, they still might copy some cool UI tricks you do. Maybe you've gone to great lengths to create some really cool frameworks that make your life easier or make your app behave in a very cool and new way. You might not want other apps to look as cool as your app does. Well, it's your right. In my opinion, the app store contains way too many badly designed apps. You would do the world a favour by releasing your great library to the public. Really.

And finally, you might not be able to open source your next app because your client or the company you're working for is against open source. Maybe they have good reasons for it, maybe they just don't know enough about open source. If the latter is the case, let them read this blog post or drop me a line - I'm available for consulting.

Business Models for Open Source Apps

You might have a different point of view (and if you do, please leave a comment - I'm eager to hear your thoughts), but in my opinion open source is not a threat but a chance for your app. If we take this for granted, the question remains, how can you make money with an open sourced app? Here are some suggestions:

Sell it on the App Store. Yes, this might sound a little strange after all my raving about open source. If something is open source, how can you sell it? Well, it turns out selling apps on the App Store is a great idea, especially for open source apps. The app store is the only way how your clients can get hold of your application. Of course - they might check out your code, compile it and upload it to their iPhone. But to do so, they'd need to be registered iPhone developers, meaning they'd need to buy an iPhone developer certificate. Don't you think it is cheaper to just buy your app than shelling out 99 USD for the developer certificate?

If you're developing a library or framework, you might consider getting funding on Kickstarter. Kickstarter is a great way to get funding for your project: you define the deliverable and how much funds you want to raise and people can back your project by pledging a variable amount of money. This way, John Wain of Glyphish fame managed to raise more than 27.000 USD for developing an iPhone 4 compatible version of his great Glyphish icon set. His original goal was to raise 2.000 USD, by the way.

I hope I could encourage you to try open source as a strategy for your next application or framework. If I did, let me know! Chances are I might want to submit a patch to add that tiny little feature I think your app is lacking

At first, I came up with a solution that would allow me to watch DVDs without re-encoding them - I just streamed them from my Mac. Actually, this is very easy with the help of some great open source tools, some of which are already installed on your Mac. But I guess this is a story for another blog post.

If you want to take your DVDs with you on your iPad, streaming them from your Mac isn't an option. So I browsed the web to see if I could find an affordable ripper. If you google for "dvd ipad", you'll be given an enormous list of hits linking to commercial tools - obviously encoding DVDs for the iPad isn't that simple, so companies can make a good business with selling tools. But I didn't want to buy any of those tools, so I looked for a solution involving freely available open source tools.

So, if you want to encode your DVDs for your iPad, here are the steps you need to take. It's very simple and doesn't cost you a single dime:

1. Download and install Handbrake.
2. In order to encode for the iPad, you need to use an adjusted profile: iPad.plist.
3. Install this profile into Handbrake (Preset -> Import... on the main menu)
4. Insert a DVD into your optical drive
5. Click the Source button in Handbrake and select your DVD
6. Handbrake will now scan the DVD for what it thinks is the main feature - you might need to verif this.
7. Select one of the profiles in the profile selection dialog (on the Mac, press the Toggle Presets button on the toolbar). iPad full worked fine for me.
8. You can now fine-tune the settings. For example, the audio tab allows you to add multiple audio tracks to your video
9. Once you're done, press Start
10. Now it's time to go for a walk or having a chat with your friends - ripping the DVD will take some time, depending on your computer
11. When Handbrake is done encoding the video, just double-click the resulting .m4v file to import it to iTunes.
12. As soon as the video shows up in iTunes, you can sync it to your iPad (the iPhone plays the video fine, too)

Most DVDs do not take up more than 1GB after encoding for the iPad, so you can load quite a number of films even onto small iPads.

Enjoy! Oh, and should I have made your life easier, feel free to flattr me!