Guava's EventBus and Android's async tasks

Android requires that you do all network processing on non-UI threads. This is good business as it means unexpected exceptions aren't going to crash your app. It can be a little problematic when you need to be notified of the different outcomes of your various network activity. You need to notify an activity, it needs to notify one of it's components.

The Callback Approach

This is essentially like handing a reference to the caller of the process. The process then calls an appropriate method on the caller, depending on the outcome.

The Guava EventBus Approach

This approach decouples the caller from the process. The caller can register for different events on the event bus after which, any process can put that event on the event bus. The registered processes with get notified.

You have to define those events but they can be empty or you can wrap anything you need in them.
Then all you have to do is subscribe for the event from the activity. It doesn't matter what you call the method... what matters is the parameter must match an event that will be put on the message bus.

Why is the event bus better? 

Well it decouples the method responding to the outcome of the network activity or whatever from the task doing this. You don't have to pass a reference of the thing doing the responding to the task. Another benefit here is that anything can register to respond to this event. Be it the activity, or one of it's fragments, it's action bar, or whatever. Nice!

iOS development - Writing an app - Pt 2 - Choosing data storage

This is the 2nd in a series of posts concerning iOS development. I want to begin my app by choosing a data storage technique. I'm leaning towards Core Data because I want to hook it up with my models using xCode's for iOS 5 storyboards... but I realize I need to do my due diligence and research all the options. So, here they are with an outline of my needs.

The vision for my app will definitely involve some robust storage capability. Without saying too much, the foundation for my app will be a users ability to build, track, and share recipes. I'd like to investigate my options for this. My research has concluded that in iOS development you have a number of on-device data storage techniques as your disposal.

Property Lists - These are sort of key-value pair storage techniques. You define them programmatically and they're loaded when the app starts. I suppose this is the simplest, most basic option. It's limitation would be you don't get any relational capabilities.

SQLite - With this option you get the relational thing at least in your database because it's SQL. It's my understanding that the support for this comes from some C libraries included into the iOS framework. Since SQLite works off a single file, you can seed this with your data and load it into your application. I plan to investigate this further in another post. It appears this option involves the requirement of writing your own sql queries. Boo.

Core Data - This is sort of the Maserati option. Core Data is provided and customized to work with xcode development. You get your relational structure. You hook it to your data models via xcode. You don't have to deal with database connections or schemas. It's basically the only option where you get an ORM feeling.

My decision is to move forward with Core Data. Not only will it satisfy the curiosity of how storyboards work with it, but it's the ORM option. And I love ORMs. Don't get me wrong, I can write my fair share of SQL, but if there's something out there that does all this for you... why not use it?

iOS development - Let's write an App - Pt 1

This will be the first in a series of posts where I document the process of writing an iOS 5 app using Xcode. I've been playing around here and there for about a year. I want to take it to the next level though. I'm going to write an app around storing, tracking and sharing home-brewing recipes.

As I write my app, I'm going to move through the decision-making process, high-lighting what I'm thinking about and why I'm making the decisions I'm making.

I've obviously already made a couple decisions so I'll go ahead and document those here.

1. Why a home-brewing app? Because I love home-brewing. :-) (Even though I don't do it anymore.... see: the size of my NYC apartment.) I also think there's a gap in the market here... be it a somewhat niche market.
2. Why native iOS? Well, my current 9-6 job is native Android development. I want to explore something outside of this. I thought about doing an HTML5 or jquery-based mobile website. And, I appreciate the fact that you reach more users this way. It's just that I'm less interested in exploring these right now. I want to play around with Xcode, especially some of the latest features.  

So, off we go!