Core Data + Passwords in Keychain

In an iPhone app project I’ve been working on recently, we needed to store sensitive information in a Core Data database. Without going into too much detail, let’s say we wanted to fill an Account table with usernames and passwords, but, of course, we couldn’t just store the passwords in clear text in the database.

Researching about best practices to do this, I came across this little great article. According to the author, “the keychain is about the only place that an iPhone application can safely store data”, referring to the Keychain Services in iOS. The author also provides some useful methods to make accessing the Keychain less of a pain.

Based on that article, I’ll show you an example of how to combine both Core Data with the Keychain to store passwords securely and seamlessly in NSManagedObject classes.

Continue reading

Fire.fm

Fire.fm

This post is about Fire.fm and how it came to be. I no longer support it, unfortunately. Happy reading 😀

“What if you could play music using Firefox and nothing more?” That was the question that sparked the creation of Fire.fm.

Back in March 2008, my friend Jorge Villalobos spotted the announcement of the Extend Firefox 3 contest, sponsored by Mozilla to promote the launch of Firefox 3. This is usually an annual event, but at the time I personally had never heard of it. Me and Jorge, we both already had considerable experience in Firefox development, so he asked me if I were interested in participating together. I was definitely interested, yet we had no concrete ideas. Normally, the contest has two categories: best new add-on and best updated add-on; this time, however, they had opened two additional categories: best shopping add-on and best music add-on. We were both immediately drawn to the latter, since we both love music (well, who doesn’t?). We saw this as a great opportunity to develop something both useful and cool.

First we did our homework. A quick search for existing music related add-ons yielded almost nothing. FoxyTunes was the most popular music add-on at that time; it inserted a few buttons and controls in Firefox to let you control iTunes remotely. I remember I liked the idea of having the integrated playback controls in Firefox, but I didn’t like the dependency of having iTunes running in the background for it to work.

One of the contest sponsors, specifically of the music category, was Last.fm, an Internet radio station and music community website. At the time, I had never really used their site, but because of the contest and our research, I started using it a lot and ended up loving it. In Last.fm, you start by typing in the name of an artist you like; it then plays music from that artist and from similar artists you may or may not know of. This is a great way of discovering new music, but one grievance was that you had to have the Last.fm website opened all the while you were listening to the music. It all fell quickly into place: “What if we can do something like FoxyTunes, but using Last.fm instead of iTunes?”, we thought. The idea of listening to music without the need of anything other than Firefox was very exciting for us.

And so we began. But before we could though, we had to overcome two major potential showstoppers. First, we had to come up with a way of playing music; HTML5 was not coming to Firefox until a couple of years later, so Flash was our only alternative. Second, we had to find out if we could, somehow, mimic what the Last.fm in-site Flash player was doing, i.e. how it was requesting the music files from the Last.fm servers. In retrospective, this was, without a doubt, the most complex part of the whole implementation of the add-on; once we got those out of the way, the rest was pretty straightforward.

We put much emphasis in the design of the user interface, as we were convinced we wanted it to be as minimal and unobtrusive as possible. We also wanted to make sure it complied with accessibility standards and with each operating system’s look and feel. And we also wanted the interface to feel easy and intuitive to use.

After a month and a half of development (in our spare time!), and half a month of debugging, we submitted our add-on to the Extend Firefox 3 contest. We waited for the results anxiously, since we really felt our add-on was a serious contender. Finally, on August 21st, 2008, the winners were announced, and Fire.fm won the best music add-on category. As part of the competition prize, we flew to London and met with the nice folks at the Last.fm headquarters.

Initially a world-wide free service, Last.fm is now only free in the US, UK and Germany, and a paid subscription service everywhere else. This, unfortunately, might change even further in the near future. Fire.fm, as an add-on itself, is and always will be completely free; we only accept donations, which allow us to continue supporting it. We add new features from time to time, and we try to help out all users who have trouble with the add-on in a timely manner.

Fire.fm had seen almost a whopping 4 million downloads, and had an active user base of ~300,000 users during its peak.

Destroy the Web add-on for Firefox

Destroy the Web

Destroy the Web is an add-on for Firefox which turns any website into a shoot-em up video game. You have 30 seconds to destroy a website as much as possible. It was awarded Best Game & Entertainment add-on in Mozilla’s Extend Firefox 3.5 contest in 2009, and had an active and growing community of players around the world. In the next few lines I reminisce over how I came upon the idea for it, and the process of its creation. The project itself is now abandoned.

The idea behind Destroy the Web came out when… hmmm… I don’t think I exactly remember!

It was June 2009, and Mozilla announced another edition of the Extend Firefox contest. The concept was the same as in previous editions: create an awesome add-on for Firefox; but this time with a couple of new categories: Best Shopping Add-on and Best Game & Entertainment Add-on.

Now, this is the part where I tell you I’m sort of a video game nerd.

I was born in the 80’s, so video games are second nature to me; and I’ve been playing since I can remember. I was hooked since the first time I played Pitfall II on my older brother’s Atari 2600. Ever since then, I’ve been lucky enough to have had at least one gaming console per generation, always favoring Nintendo. Come to think of it, video games were probably the reason I chose this career path.

Back to the Extend Firefox 3.5 contest. I was excited about the possibility of participating, and I was convinced I wanted to do something for the game & entertainment category. Having won the past year with Fire.fm though, I became worried I could not come up with something particularly interesting or useful enough twice in a row.

The one thing I was sure of was that a game add-on for Firefox had to fit within Firefox. For me, if the game had nothing to do with the actual web browsing, then it had no real reason to be an add-on; it would be just another game in a pop-up window. Since I wanted the game to be related with the browser, I thought it would be an advantage if the game (whatever it would be) was played by doing something in the current page; in other words, the web pages would be the stages. This gave the game two advantages: one, since two websites are never the same, the game immediately obtained a random factor to it; and two, since websites are common domain and public, people could compete to obtain the best score in any given site.

With this idea in mind, I set up my development environment for a new, blank add-on project (unnamed at the moment), and started toying around. One of the first things I tried doing was painting over the current page, but I quickly tossed that idea out of the way when, almost by accident, I added code to remove HTML elements from the page by clicking on them. It seemed funny to me how the page began to fall apart when its elements were removed, so I decided to make a game where you had a certain amount of time to destroy websites. Since I wanted to have some kind of high score system and a sense of competition between players, I constrained each play session to 30 seconds: enough time to play but not too much that it could become tedious. The game quickly took shape and, well, just basically developed itself into what it finally became.

I was aware that animation and sound effects could either make or break the game. The contest encouraged participants to take advantage of the new features of Firefox 3.5, which was about to be released at the time. This was actually great because it added features to the HTML canvas element and introduced support for the HTML audio element, which allowed me to implement the animation and sound, respectively. This presented a nice challenge though: I could handle the animations on my own using canvases and javascript, but I had to look for the sound effects. Luckily, I found a great collection of 8-bit explosion sounds and some great music at http://www.freesound.org.

Once the add-on was ready, I created a quick website where players could submit their scores, and submitted my entry in the contest. A few months passed, and Mozilla announced the winners, awarding Destroy the Web the prize for Best Game & Entertainment add-on.

Dismissing MPMoviePlayerViewController the right way

If you have used the MPMoviePlayerViewController to play videos in iOS, chances are you have gotten a little frustrated by its rigidness. A couple of issues I personally encountered were:

  • When presented modally, the view controller did not respect the modal transition style I had chosen for it.
  • When the video finished playing, the view controller dismissed itself automatically. I wanted it to remain visible until the user pressed the Done button.

A couple of hours of browsing for the solution to no avail, I decided to try out sort of a hack, which turned out to work great.

Continue reading

Overlaying the iPhone camera without blocking its controls

While developing FaceMerge, an iPhone/iPod app that lets you take pictures of people and merge them into funny faces, I came across a problem while overlaying the camera. I wanted to provide the user with just a bit of guidance while taking pictures within my app.

Since iOS 3.1, the UIImagePickerController class has a property named cameraOverlayView; setting a UIView of your own to this property causes it to appear on top of the camera when the picker is displayed.

I did just that: I created a custom UIView named CameraView, which had no background color and only one label on it; and then I set it to the picker. When the picker showed up, everything looked OK, but the camera controls did not respond to any touch event.

Continue reading