I recently wrote a guest post for the RubyLearning blog entitled “How do I build DSLs with yield and instance_eval?”. It gives a brief overview of how to use Ruby to build simple internal DSLs. Enjoy!
The web application landscape has changed drastically in the past year or two. Where once every site was a silo unto itself and could reasonably expect users to create a unique login and password for each site, it is now a different story. I sigh every time I have to fill out yet another registration form, wishing instead for a simple "Connect with Facebook", "Sign in with Twitter", or "Log in with OpenID". At the same time, services are more interconnected than ever. One of the best ways to increase the popularity and viability of a new service is by piggybacking it onto the existing user bases of apps such as Twitter, Facebook, and Foursquare.
There are lots of authentication solutions out there for Rails. Many of them even have ways to connect to services such as Facebook or Twitter. But as I used these in project after project I noticed an emerging pattern: they all make too many assumptions about how I want to handle authentication in my application. Sure that makes it a quick start for the vanilla use case, but I honestly can't think of a time when I've dropped in an authentication solution and I was good to go. It's time for a change in perspective.
Today is the public release of OmniAuth. OmniAuth is a Rack-based authentication system that abstracts away the gritty, difficult parts of external authentication without assuming anything about what you actually want to do with that authentication information.
What does this mean for you? This means that you can make your app authenticate through Twitter, Facebook, LinkedIn, Google Apps, GitHub, Foursquare, and more and then have complete control from there.
OmniAuth is available as a gem:
gem install omniauth
Using OmniAuth is as simple as using any other Rack middleware. Of course, that's because OmniAuth is simply a Rack middleware. No complicated framework-specific configuration, just a collection of middleware to take the pain out of external authentication. Let's say I have a Sinatra app that I want to be able to authenticate via Twitter or Facebook. Here's what's required:
require 'omniauth' use Rack::Session::Cookie # OmniAuth requires sessions. use OmniAuth::Builder do provider :twitter, "CONSUMER_KEY", "CONSUMER_SECRET" provider :facebook, "APP_ID", "APP_SECRET" end
That's it! Now if I want to send my user to authenticate via Twitter, I send them to the URL /auth/twitter. For Facebook, /auth/facebook. The user will automatically be redirected to the appropriate site where they will be able to authenticate. Once authentication is complete, they will be redirected back to /auth/providername/callback and OmniAuth will automatically fill the omniauth.auth environment key with information about the user, so for my Sinatra client I just need to add:
get '/auth/:provider/callback' do
auth = request.env['omniauth.auth']
"Hello, #{auth['user_info']['name']}, you logged in via #{params['provider']}."
end
Of course, I could do a lot more than just print out the user's name. I could also:
uid key of the auth hash and log them in if one exists.uid and information from the user_info hash.The point here is that OmniAuth doesn't assume that you simply want to log a user in. It lets you make that judgment call and gives you all the information you need to do just about anything you need to do.
OmniAuth works right now for a wide variety of providers, and this list will continue to grow. OmniAuth today supports:
OmniAuth has been my worst-kept secret library for some time now. I've been using it as the go-to authentication strategy for new projects big and small for the last few months, and it feels really refreshing to have so much control over authentication without losing the drop-in ease of use. If you need external authentication but have found existing solutions to lack flexibility, please take a look!
OmniAuth is on GitHub with a growing set of documentation on the GitHub wiki and I have also set up a Google Group to handle any questions that might arise.
In the past week I’ve jumped head-first into Android development for a new Intridea project. This is my first time doing any real Android development as well as my first jump back to Java since I graduated from college. I thought it might be interesting to catalog some of my experiences developing for the platform, so here they are:
Intents: Android is built on an “Intents” system. When you want the user to perform some kind of common action, you create an intent for it and activate that intent. Different applications can hook into the same intents, allowing the user to completely customize how they handle a given action.
Wow, what a brilliant system. Android is built from the ground up for insane levels of interoperability between applications. It took no time at all to get a basic QR code scanning process flowing thanks to intents, and the same went for composing e-mails and opening web pages. Literally couldn’t be simpler.
Activities: The base unit of an Android application is an activity. An Activity class is what holds the context for your application as well as manages on-screen events and more. One application may have many activities, divided up logically based on user actions.
Once I was able to wrap my head around the idea that any given “screen” is really more like an “activity” that the user performs, the logic of the application design really fell into place. I think this is a perfect level of abstraction for a mobile platform, and it really made it easy to figure out where to draw the line between one screen and the next.
On-Phone Debugging: My mouth actually dropped open the first time I plugged my Nexus One in and hit “Run” in Eclipse. In just 5-10 seconds my app was launching natively on my phone for me to test. Not only that, but I was still able to see logs and uncaught exceptions as the program ran. Running on the phone is also lots faster than running in the emulator.
Resources and NineScale: Google has come up with a very elegant solution to the idea of handling binary and other resources in Android projects. All of the resources in a directory are pre-compiled into a big reference file called R.java that simply contains access to every menu, image, string, and view that you’ve created for the application. This makes it so easy to transition between referencing resources in the XML and the code, because it all uses a similar syntax. Great stuff.
When designing views, you will often want to have image-based backgrounds that intelligently stretch to fit their contents. This is called various things in different platforms and tools (NinePatch, NineScale, 9-Slice, etc.). Google’s implementation is very simple and can be done without extra plugins from any image editor (it’s just a 1px border around an ordinary .png file). Once again, very cleverly designed.
The Overall Architecture: Android overall just feels like it was really put together with a lot of thought and care. Everything fits together really well and even people without hardly any desktop or previous mobile application development experience can pick it up relatively quickly. Also, the documentation is pretty extensive (though it would be great to have an even more exhaustive list of code examples of various aspects of the API).
Compiling: When you’re used to viewing changes to your application just by clicking “Refresh” it can definitely feel like a waste of time to have to compile and run the app. There’s absolutely nothing that can really be done about this (it is a native app, after all) and Google has gone out of their way to make the process feel as responsive as possible, but it’s still an unwelcome break in the development cycle for someone used to working on web apps.
Where’s My CSS? I’m guessing that some people will disagree with me here, but wow did I ever miss CSS when building an Android application. CSS makes it so easy to rapidly and iteratively style things. Android has a few ways to style things that definitely help over repetitive copy and paste XML attributes, but the expressiveness and power of CSS is sorely missing from building interfaces in Android.
Exceptions: When running an application in the emulator or on the phone, I really wanted a clear and easy way to view stack traces. The LogCat view on Eclipse is the way to do this, but I found a few problems with it:
Java: OK, OK, could take some flak for this one, but after developing full-time with Ruby for more than three years now, going back to Java feels like an unbearable chore. There’s so much boilerplate code and I found myself really missing the simple, expressive, concise idioms of Ruby. Maybe once Mirah gets a little more mature I can at least ease that part of the Android experience.
SQLite: I know that it’s the go-to solution for small, simple storage, but why on earth do mobile platforms have schema-driven data stores by default? What a ridiculously square peg to pound into the round hole of mobile data persistence. You know what the default data store for mobile ought to look like? Redis. If I had the simple data structure support provided in Redis (key-value, lists, and sets with simple combinatorial commands), I wouldn’t need anything more for 99.9% of the applications I can think of. SQL is an awful, terrible fit for mobile and I hope that one day someone realizes it.
I’m glad to see that CouchDB is trying to disrupt this space a little, and I hope that the disruption continues with more datastores and more choices being available for mobile development.
It was certainly an interesting week and I’ve been learning a lot. Android development is starting to come more naturally (looking things up on the API docs maybe every 5 minutes instead of every 30 seconds) and I’m actually starting to enjoy myself. It’s really satisfying building something that I can immediately run on my Nexus One, and I definitely look forward to working more with the platform in the future.
That being said, I don’t think I would choose to develop for mobile applications as my primary focus. While mobile development is certainly rapid compared to old-school desktop development, I still don’t think anything can match the ease and speed with which web applications can be developed. Since I’m ultimately more interested in ideas and solving the big-picture puzzles of applications than the low-level implementation details, web is still the place to be for me (for now).
And so we’ve reached the end of this rather wordy spiel; hopefully if you’re a web developer you can read this and get some idea of what it would be like to dive into mobile development, and if you’re already a mobile developer maybe you can tell me how I’m all wrong about everything I’ve just written. And maybe, just maybe, if you work for Google you’ll implement Redis as the primary datastore for Android 3.0. Hey, a guy can hope, can’t he?
Google’s Android has seen an incredible rise in popularity since its first handset was launched less than two years ago. Google has worked hard to earn that popularity, regularly releasing fantastic new improvements to the platform in the form of Donut, Eclaire, and now Froyo. Unfortunately, many users of the Android ecosystem won’t see these improvements for years, if at all. The reason? Manufacturers of Android handsets are building custom versions of the OS to add eye-candy and make the UI seem more attractive, at the expense of upgradeability.
HTC has its Sense UI and Motorola has MOTOBLUR. Samsung and Sony have also thrown their hats into the “heavily modified UI” ring. While these packages may serve to help differentiate from the competition, they are hammering the Android ecosystem by causing fragmentation (and yes, I do think that’s the right word). But it isn’t all their fault. One can certainly understand how, when competing against the likes of the iPhone, manufacturers would want to “pretty up” the Android experience. So I’ve got a few words for these OEMs, and Google as well.
I’m really happy that you’re ‘laser focused’ on the user experience for the next release. Now that you’ve got it humming at lightning speed with Froyo, it’s time to add some polish. Fantastic. But making a better stock UI isn’t the only thing that needs to happen to prevent this fragmentation.
You should be doing everything you can to prevent version fragmentation because it’s hurting developers and consumers. When people with G1s see “official Android Twitter client released” but can’t download it, they’ll get frustrated. They don’t know or care about the fact that the G1’s limited internal storage means that it can’t get the next upgrade, they only care that they’re supposed to have an Android but they can’t get the software they want.
Here’s my advice: take the feature lists of Sense and MOTOBLUR et al as a laundry list of areas where your API needs more robustness. If the capabilities of Sense and MOTOBLUR were exposed at an application level, this problem would simply disappear. You’ve built your platform to be backwards-compatible; if HTC wants to build a “Sense UI” app that changes the appearance of the UI and adds a bunch of widgets, and they want to make that only available on their handsets, more power to them. When the next version of Android comes out, it’ll all work seamlessly because they’ve simply built an app, like any other developer.
So keep up the good work on Gingerbread, I’m looking forward to the UI improvements. But also make your UI reachable by applications, provide hooks into the very guts of Android so that manufacturers and developers alike can really “make it their own” without building a custom ROM.
Thank you for making Android handsets. I’m a huge supporter of the platform, and the level of competition and innovation on Android phones has been amazing. Keep it up! But you’re doing yourselves a disservice by building these custom UIs that inhibit the Android version upgrade process.
Google has huge teams of people working to continuously upgrade the Android experience. You get the fruits of this labor 100% for free. I understand that as a handset manufacturer the idea of upgradeable phones isn’t necessarily the most appealing: if people can upgrade the software on their phones, maybe they won’t want a new one in 2 years! But trust me, you’ve shown that you’ll make the hardware good enough that people will want new phones.
Instead of locking down a handset to a specific Android version, create an unbeatable suite of applications that comes pre-loaded on your phone. Work on top of, instead of within, the Android operating system. Then you can leverage all of Google’s work and all of your own work to provide customers with a great experience. Work with Google to add pieces of API that will help you provide all of the value you want to provide; I’m sure Google would be happy to help as best it can.
Also, while I’m at it, can one of you please create a 4.3" handset running the stock Froyo UI sometime before November? I’d love to get a big-screen phone when my contract’s up, but I don’t know that I can handle dealing with these custom UI jobs. It’s just not for me.
I think that Android is a very important project that came along at just the right time. It has applications far beyond mobile handsets and we’ll begin seeing Android in cars, tablets, and more in the very near future. This will mean even more work will be poured into the Android ecosystem creating greater and greater benefits for everyone from consumers to handset manufacturers. All that needs to happen to take advantage of those benefits is for Google to help handset manufacturers free themselves of the idea that they need to “make it their own”.
I’m looking forward to the next 40 Android phones, and the 100 after that. I truly think that Android is going to dominate the mobile market five years from now (Apple will still have about the same piece of the pie, but Android will have displaced RIM and Microsoft entirely). So keep up the good work, but how about we all just get along in the meantime.