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.

Samsung TV App SDK

The part about it that really sucks is the project management. How come tool vendors still think it's good style in 2010 to place the projects under Program Files\Samsung TV Apps SDK\Apps? There's no way to store your project files in a different location. The project open dialog just won't let you navigate to some other place:

Samsung TV App SDK Project Management Dialog

So I wanted to be able to edit my files on the Mac (using TextMate) while still using the good parts of the Samsung TV SDK (i.e., the Emulator).

I'm using VMware Fusion to run Windows 7 and the Samsung SDK (no, there is no version for the Mac). Most virtualization solutions offer a mechanism to share folders between the host and the guest OS. So I quickly set up folder sharing between my Mac and the guest OS, in this case Windows 7.

Now that I can see the project files both on the Mac and on the Windows machine, how can I make sure I can open the project in the Samsung TV SDK IDE? As I mentioned before, there's no way to tell the IDE to open projects form other locations than Program Files\Samsung TV Apps SDK\Apps!

After playing around with some more or less usable folder synchronization utilities, I came up with something most MacOS / Linux users should be familiar with: symbolic links! While symlinks have been around in Unix-like OSes for ages, they have been rarely known to Windows users for most of the time. However, starting with Windows NT, you can create symbolic links, hard links and junctions using a nifty little tool called mklink. Unfortunately, you're not allowed to run mklink if you're not an administrator. Using runas (which is Windows' equivalent of sudo), didn't help as the shared folders weren't visible to the admin user.

To cut a long story short, I found Symlinker, a UI tool that helps in creating symlinks on Windows. As it is a UI tool, you can run it with administrator privileges (by selecting Run as Admin from the context menu). Using a UNC path, you can create a symlink to a VMware shared folder and place this symlink in the location the Samsung IDE expects it to be.

Finally, I can edit my files on the Mac and run the app in Samsung's Emulator on my hosted Windows machine. And as the files on my Mac are mapped to the hosted Windows machine via a symlink, I do not suffer a synchronization lag - all files are updated instantaneously

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/)

We had a nice lineup of four speakers - unfortunately not all of them were able to attend due to a cold, but we were lucky enough to find one additional speaker - thanks Jan!

After a casual meet-and-greet with Fritz Kola and Pretzels, Dalibor Topic opened the official part of the evening with an overview of what's coming up in JDK7 and JDK8. Here's a list of things that sound quite interesting:

• Support for dynamically-typed languages (InvokeDynamic) (project page)
• Small language enhancements (Project Coin) (project page)
• An even newer NIO (project page)

The good news of the day of course was a press release announcing OpenJDK for Mac OSX. Nevertheless, Dalibor demoed a freshly built OpenJDK 7 BSD port on his MacBook.

After a short break, it was Ralf Sternberg's turn to give an overview of RAP and explain what Single Sourcing is. With the help of RAP, it is rather easy to bring Eclipse RCP applications to the web. Of course, you'll have to pay attention to a few things, as Ralf pointed out: usually, RCP applications are single-user apps, whereas web applications are inherently multi-user enabled. Fortunately, RAP comes with a few utilities that cater for this fact.

One thing I was delighted to learn: not only do RAP applications run on the iPad, but also do they support drawing using the SWT API, as you can see in the following video:

In the last sessions, Xtext committer Jan Köhnlein showed us some of the things coming up in Xtext 2.0. Being text-addicted, Jan refrained from using slides and used the IDE instead to deliver his talk:

Jan showed us how Xbase (no, not xBase) can be used to develop DSLs (and even GPLs) that not only describe structural features but also behavior. He also demoed Xdoc, a newly invented documentation language, and the fancy new Xtext syntax view (featuring railroad diagrams).

After the demoes, we had some time for chats and impromptu hack sessions. Given the event took place in a book store (many thanks to Lehmanns for having us!), you could also browse and buy books.

Thanks to the fact we only had about 40 attendees, there were plenty of chances for networking which people really seemed to enjoy.

I'd like to thank everybody who attended the DemoCamp or gave a demo! Follow me on twitter to be informed ahead of time for the next DemoCamp!

I think the program committee have done a great job at putting together an exciting conference program with lots of technical sessions, interactive tutorials and inspiring keynotes.

As a special treat for smart phone users, we're offering a conference schedule app for iPhone, Android and all other smart phones that come with a browser. Besides reviewing the conference schedule and getting to know the speakers you can use the apps to create your very own personal conference schedule. Usually, conference attendees will use the printed conference program to mark their favorite talks - and then leave their personalized copy of the program in their hotel room or elsewhere in the conference halls!

This will probably not happen with the smart phone app, although I can recall somebody lost their iPhone at this year's EclipseCon...

Without further ado, here's a preview of the iPhone app in action:

You can download the iPhone app from the App Store. It is available world-wide and we already have a few downloads from Singapore, Korea and India! For your convenience, here's the link to the app.

We also prepared a version for Android users. Here's how it will look like on your Android device:

Head over to the Android Marketplace and search for "eclipse summit", or use your barcode scanner:

The mobile web app will be available from the Wifi landing page at the conference venue is available via the following URL: http://bit.ly/ese_app_mobile2/.

Rumor has it even BlackBerry users will get a native app. Ekke has created a native app for BlackBerry.

Using these applications, you'll be able to put together your Eclipse Summit Europe 2010 in no time. Enjoy!

The iPhone, Android and mobile web apps have been built by a dedicated team of software engineers at itemis I have the pleasure to work with. If you want to learn how we build applications like these, attend our sessions:

• Tuesday, 14:00 - Mobile Development Symposium
• Thursday 10:30 - Models To Go: How We Built a DSL for Mobile Apps With Tools From the Eclipse

Also, be sure to drop by the new website for our mobile business: http://mobile.itemis.com and follow us on Twitter: @itemismobile.

Enjoy the your conference!

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