In all of these movies, humans can directly communicate with computers using voice commands (“Tea. Earl Grey, hot”) or more elaborate sentences and the computers will talk back to humans as a result. In some of the movies, the computer is a non-bodily entity (like the ship’s main computer in Star Trek), but sometimes it even is humanoid (like Cmdr. Data in Star Trek or the Replicants in Blade Runner).

In a Pecha Kucha presentation I recently delivered at the OOP conference in Munich, I took on this theme and started my talk with a imaginative conversation between two computer programs that most of you might know very well: Eliza and Siri.

Do Androids Dream of Electric Sheep? from Peter Friese on Vimeo.

In this Pecha Kucha session, Siri and Eliza join me live on stage to explain why we do not (yet) use the potential of our smart phones.

Much has been said about Siri, so let’s focus on Eliza.

Eliza started as an experiment in 1964, when Joseph Weizenbaum, then professor of computer sciences at the MIT, wrote it as an early attempt to research natural language communication between man and computer (see his ACM paper “ELIZA – A Computer Program For the Study of Natural Language Communication Between Man And Machine”). At its heart, Eliza is program that reacts to specific key words in sentences entered by a human user and will then respond to those keywords according to a predefined script. It’s the script that basically makes up the “personality” of Eliza, the most famous one being Doctor, simulating a rogerian psychoanalyst.

(Weizenbaum was rather surprised to see how people thought that Eliza had a real personality and a capacity for empathy. In reaction, he started to raise uncomfortable questions about our dependence on computers.)

In my Pecha Kucha, I went on to tell my audience to make better use of the capabilities of our smart phones. Most people have stopped thinking about it, but after all, we’re carrying a super computer in our pockets.

So to set a good example, I decided to create ElizaApp – an app that can listen to what you say and answer in spoken language. This is going to be a great project, because I’ll show several very interesting things:

1. How to analyse spoken language on a mobile device
2. How to synthesize speech on mobile devices
3. How to integrate a JavaScript engine in your mobile app
4. How to create a Siri-look-alike chat UI

Over the course of the next few weeks, I will write several posts covering these topics. If there is anything that interests you in particular, feel free to add a comment.

Of course, in the end Eliza will be available on the App Store. In the mean time, be sure to check out ElizaApp and register for early access!

Over the years, implementing scope providers has become significantly easier, much thanks to the tiny internal scoping DSL provided by org.eclipse.xtext.scoping.Scopes (src). However, collecting the elements that make up a scope can be a very cumbersome task if you have to use Java. Let’s face it – Java has not been built for traversing models.

A language much better suited to traversing models is Xtend, the newest kid on the X block. If you didn’t yet give it a try, you should do so now – even if you’re not writing an Xtext DSL. Xtend directly translates to Java code and allows you to write very concise code by eliminating much of Java’s ceremony. You can use it to write everything you’d write in Java – from Android UIs to web applications – so why not write Eclipse plug-ins with Xtend?

To write the scope provider for your language using Xtend, you need to follow a few very simple steps:

1. Disable generating the scope provider stub. Open Generate<YourDSL>.mwe2 in the DSL project and find the line

   fragment = scoping.ImportNamespacesScopingFragment { }

2. Change this line to

   fragment = scoping.ImportNamespacesScopingFragment { generateStub = false }

3. If you already have a Java-based scope provider, copy the implementation to a safe place and delete the Java file to make room for the new Xtend-based scope provider.

4. Create a new Xtend class <YourDSLPackage>.<YourDSL>ScopeProvider.xtend in the DSL project. Make sure this class inherits from org.eclipse.xtext.scoping.impl.AbstractDeclarativeScopeProvider.

5. Start writing your scope provider using Xtend.

6. Don’t forget to smile

Well, it turns out there finally is a solution for us Cocoa developers – CocoaPods. Getting started with CocoaPods is really easy and once you started using it, you won’t look back again.

Installation

CocoaPods itself is distributed as a Ruby gem, so installing it is as simple as:

[sudo] gem install cocoapods
pod setup

Usage

Using CocoaPods to manage your project’s dependencies is a two-step process:

1. Specify the dependency in you project’s dependency specification file, Podfile
2. Run pod install

Let me illustrate this by way of a simple example. Let’s assume you want to build an application with the awesome RestKit library. If you have used RestKit before, you know that adding it to your project is a rather involved process. Over the years, it has become significantly easier, but it still needs a very detailed installation instruction with lots of screenshots – check out their wiki page.

With CocoaPods, all you need to do is this:

1. Create a new empty project, naming it RestEasyWithCocoaPods
2. In your project folder, create a new file, Podfile
3. Fill in the following information:

   platform :ios dependency 'RestKit' dependency 'RestKit/UI' dependency 'RestKit/Network' dependency 'RestKit/ObjectMapping' dependency 'RestKit/ObjectMapping/CoreData' dependency 'RestKit/ObjectMapping/XML' dependency 'RestKit/ObjectMapping/JSON'

4. Run pod install RestEasyWithCocoaPods.xcodeproj.
5. Open the newly created workspace, RestEasyWithCocoaPods.xcworkspace
6. Add the RestKit headers to RestEasyWithCocoaPods-Prefix.pch:

   #ifdef __OBJC__ #import <UIKit/UIKit.h> #import <Foundation/Foundation.h> #import <RestKit/RestKit.h> #endif

7. Done. Go and build awesome stuff with RestKit (more on this in another post).

Where to go from here

Wasn’t that a lot easier than all the other ways to install third party libraries?

If you are curious which libraries are supported by CocoaPods, go to CocoaPods.org – they have a nice little UI for searching their pod specification repository. If you are more include to using the command line, you are welcome to use pod search <yoursearchterm> to search for a specific library.

If your preferred library is not yet supported, why not help them out and build a pod spec? CocoaPods itself and the pod spec repository are hosted on Github, so adding new pod specifications is really easy. The CocoaPods wiki has a section on creating and publishing new podspec files.

Now go and create awesome stuff!

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:

With all the hoopla around HTML 5, it would be quite a surprise if modern browsers didn’t have something in store with regard to voice recognition. And sure enough, there is a W3C specification for a Speech Input API. Looking at the list of authors might give us a hint as to which browser might support this API…

Using the speech input API is rather easy. All you have to do is to add the x-webkit-speech attribute to any input tag and you’re done. If you’re on a speech-enabled browsers (as of this writing, only Chrome 11 supports this out of the box), you can check it out in the input field below. Just click on the microphone icon and start speaking:

So, the other day I thought, “wouldn’t it be cool if I could use voice recognition to look up my contacts on the social networks I am on?”. Adding voice recognition support to a website you own is rather easy, as you only have to add the x-webkit-speech attribute to the respective input fields. Enhancing foreign sites, however, turns out to be a little bit more involved. Fortunately, Chrome can augment existing websites by way of so-called Content Scripts, which are a part of the Chrome Extensions API.

Writing a Chrome Extension for speech-enabling existing text input fields on just about any website was a matter of minutes, thanks to the good documentation and some jQuery to walk the DOM. Putting on the finishing touches took me some more time, and I am proud to present you Speak to Search – a Chrome Extension that lets you talk with your browser. It works with virtually every website that uses regular HTML input fields. By making some smart assumptions, the extension will automatically submit the current form if the input field is a search field. If it is not, the focus will remain in the field and the form will not be submitted. That way, you can fill out e.g. an address form.

Here is a short video of me using Speak to Search to search for some people on Xing and LinkedIn. Please note that the extension is making sure the speech recognition engine is configured to recognize German names on Xing.

Language makes us human – this is a quote from a video I found during the research for this blog post. I don’t necessarily think voice recognition and speech synthesis will make computers more human, but both technologies certainly can help to create a more immersive experience. I am looking forward to seeing a broader use of the new audio capabilities of modern browsers. Feel free to grab my code from Github and create something new and exciting!

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.

Here’s why I think HP’s TouchPad will score a considerable market share:

1. It’s programmed with web technologies like HTML, CSS and JavaScript. Don’t get me wrong – the iPad can also be programmed with web technologies: when the iPhone was first released and no one but Apple was allowed to write native apps, Steve himself told everyone that “mobile web applications are the future”. And despite the fact Apple has opened it’s SDK and we can now program the iPad / iPhone in Objective-C, many developers are more interested in writing apps with web technologies. Tools like PhoneGap and Appcelerator try to alleviate this situation, basically allowing you to wrap web code in more or less tiny wrapper apps so your web apps can be submitted to the App Store. However, most apps written using web technologies do not feel the same as real native apps on the iOS platform. So why do I think the situation will be better on the TouchPad? Well, because the TouchPad has been built for running web-based apps! It has been optimized for it. Web apps look stunningly great on the TouchPad. Now, every web developer can download the webOS SDK and get started writing apps for the TouchPad. It’s a safe bet to assume there are more web developers out there than Objective-C developers, so it shouldn’t take long until we’ve got a similar amount of apps for the TouchPad as we’ve got for the iPad.
2. The manufacturing process. HP has a very powerful production pipeline, capable of pumping out high volumes of devices. In Q4/2010, they shipped 17.6 million PCs (Apple sold 7.33 million iPads in the same quarter). So if they are serious about it, it should be easy for HP to both produce and distribute high volumes of TouchPads.
3. Security. When it comes to enterprise computing, security becomes a vital feature of your product. CIOs need to make sure to not compromise their company’s security by introducing products and devices that have no proper support for security mechanisms. There have always been security concerns with respect to the iOS platform: for a long time, there hasn’t been a way to nuke a lost iOS device remotely. It wasn’t before iOS 4 that Apple introduced data protection APIs to secure data that apps store on the device. WebOS has several security features built in (not bolted on later) which make it rather attractive for enterprise computing right from the start.

It’s my firm belief that the release of the HP TouchPad is a milestone for the perception of personal computing in the long run. It looks great, we’ll see tons of great apps for it in no time and HP as a major computer vendor has the power to push it to the market.

Good-bye, PC.