Getting your iOS app to talk to web services and APIs

January 5, 2011 By 1 Comment

Many iOS apps connect to HTTP-based APIs, which may be RESTful but are often just XML and JSON responses to various URLs with various methods (usually a GET or POST, but also PUT and DELETE).  There’s no one methodology for talking to these types of APIs in an iOS app, but here’s the basic process I use.

If the web service happens to be a Ruby on Rails application and follows the standard RESTful practices, then Objective Resource is a great tool.

If not, then what I tend to do is use ASIHTTPRequest which provides a nice network layer. Depending on the API, I might use ASI objects directly, or else I’ll subclass an existing ASI class to add per-request functionality (such as authentication or response parsing).

You usually want to run web requests in the background, so that the UI isn’t blocked while waiting for the request to finish. There’s always the background thread route, but a nice “Objective C” style approach that ASIHTTPRequest provides is to instead provide a delegate which is called when the request finishes (see also “Creating an asynchronous request” at http://allseeing-i.com/ASIHTTPRequest/How-to-use). In many cases the request delegate is the view controller that initiates the request.

The model layer depends on the complexity, and also what format the data comes in. Most of the APIs I’ve worked with use JSON, for which json-framework or yajl-objc are good for parsing. These usually give the data parsed into base classes like NSString, NSArray and NSDictionary. Sometimes that’s sufficient, or if I want the models to exist as their own classes, then I have the models inherit from a base class that takes care of turning the NSDictionary/NSArray into properties.

Finally for caching, Core Data provides a good way to persist to disk. For caching in memory, I have the requests occur in a separate “manager” class that is shared between controllers. These managers use the Singleton design pattern as described here.

Filed Under: iOS Development Tagged With:

Why Email Confirmations Are Bad

May 7, 2010 By Leave a Comment

When designing a web application it’s common to see the following user registration process:

  1. User fills out the registration form, including their email and password.
  2. After submitting, the user is told to check their email for a confirmation link.
  3. After waiting for the email, they click the link and are marked as “activated” on the site.
  4. The user can now start using the site.

The thinking behind this is that you need to make sure the user has provided a valid email address, and one that is actually theirs.

However, there are a number of problems with confirming email addresses this way. It breaks up the user’s flow; if I’m signing up on a site I’m eager to start using it. Needing to wait for an email breaks that flow.

Second, email is a notoriously unreliable delivery mechanism. Because of the huge amount of spam prevalent nowadays, email providers are especially quick to err on the side of spam, if they even deliver the email at all. Confirmation emails in particular can often appear spammy, as they usually have a long link with a lot of random characters, and often contain only the user’s email address without their real name.

The last thing you want is someone choosing to sign up for your site, only to never start using it because they got distracted waiting for an email, or move on to something else because the email never comes.

Rather than blocking all functionality until the email address is validating, instead consider allowing as much use of the site as possible. When they get to a point where it’s necessary to know that the email they signed up with is correct, you can say something like “We need to verify your email address before you can proceed. Click here to re-send”. This also has the benefit of giving people a chance to re-send the emails if it was missed the first time.

Most functionality doesn’t require a verified email address. The main exception is that you don’t want to send out too many emails without knowing a user’s address. Otherwise, I could signup with someone else’s address and cause them to be spammed. This means you might want to wait on things like notifications (friend requests, direct messages, etc). Other than that, there’s little that’s truly required.

It can be tempting to require a verified email address for all functionality. However, the added complexity is worth the improved user experience.

Filed Under: user experience Tagged With: , , ,

How to Use a Blog to Increase Organic Traffic

May 4, 2010 By Leave a Comment

There are many great reasons for businesses to blog but one clearly stands out, increasing your keyword rankings and growing your organic search traffic.

via How to Use a Blog to Increase Organic Traffic.

Both on-page and off-page factors are important in building traffic from search engines.  Obviously there’s more you can do immediately about on page factors. Here HubSpot discusses how to optimize blog posts for keywords for which you’d like to rank well.  Selection is important, because you don’t want keywords that are overly competitive, but neither do you want keywords no one will search for.  The route advocated here is to think “long tail” and grow a large set of optimized pages that slowly bring in traffic.

Filed Under: Online business Tagged With: , ,

How Online Businesses Make Money

May 3, 2010 By 1 Comment

The majority of people online aren’t on the Internet to make money. Instead, they use the Internet for things like entertainment, news, games, and keeping up with friends and family.

However, for those who want to want to start a business, the Internet is a great place to look. It’s a relatively new, growing area that still has tons of potential. Because of its newness, there are almost certainly new sources of revenue still to be discovered and explored. It’s never been easier or cheaper to start a business.

With that said, there are a number of common models that have developed. Each have their tradeoffs with regards to risk and reward, which we’ll compare below.

1. Advertising

Advertising was one of the first business models to develop on the Internet, given it’s long history on paper, radio and television. In the early days, ads were sold like they are on television. They were generally sold on highly popular destination sites, with the goal of being in front of as many eyes as possible.

Google was one of the first to really take advertising to a new place on the Internet. By using peoples’ search queries they were able to target ads better than ever before, while simultaneously reducing the barrier of entry for companies looking to advertise by only charging an advertiser when a user clicked on their ad.

You don’t need to be a search engine to make money from advertising. Indeed, in many cases advertising is the de-facto model for converting a large number of users into revenue. Be careful though: part of Google’s success was that people come to a search engine looking for something, and if an ad gives them what they want, they’ll click it. On many sites, users aren’t necessarily looking for anything, and click-thru rates can be notoriously low.

Investment: Medium. Building a website, hosting it and marketing it requires some capital. However, the idea is to start making money soon after you launch, and hopefully make a return on your investment within a short amount of time.

Odds of success: Medium. As shown in the Google example, there is the potential for a lot of revenue in advertising, but it’s also a notoriously difficult market for websites. Getting a lot of traffic is key here. It also requires you to essentially become an advertising company, which means your real customers are your advertisers, not your users.

Potential return: Medium. It’s very difficult see huge profits from advertising. You’re basically a middleman between other companies and their potential customers, and there’s a limit to how much companies will spend on adveritising. Companies that depend on advertising are also very prone to swings in revenue, as advertising budgets are often the first thing to be cut when times get tough.

2. Promoting an existing product or service

In this case, you already have a business with a source of revenue, be it a restaurant or a law firm. Creating a presence online can be a great way to dramatically expand your customer base.

What’s great about this is that if you’re a profitable business, then you have a proven track record. On the other hand, if you don’t already have a business, starting an offline business can be very expensive (buying property, getting licenses, etc).

Investment: Medium. Again, the main investment is building and marketing the site. However, if you already have a profitable product or service, then you should already have the capital to create an online presence.

Odds of success: Medium to High. What’s key is marketing properly. Simply putting up a webpage doesn’t guarantee new business. On the other hand, keen marketing can make your revenues explode. A great example of this is Wine Library, which started as a New Jersey liquor store and came a $50 million dollar business thanks to the marketing of Gary Vaynerchuck.

Potential return: Low to Medium. While there are certainly cases where a small but successful company can go on the Internet and exponentially increase their revenue by going from local to global, you’re also opening yourself up to a lot more competition. But if your competition isn’t online yet (or isn’t competing effectively online), it’s a great way to get some new customers.

3. Selling an online product or service

The difference here is that you’re creating something new, and usually something that only exists on the Internet. An example of an online product is an eBook, while an online service might be a dating site.

There’s a lot of money changing hands on the Internet these days, and the more businesses and individuals depend on the Internet, the more need they have for other services and products. Subscription models are popular here, where customers keep paying as long as they get the desired service.

Investment: Medium to High. All the costs that exist in the cases above exist here, but multiplied. Not only do you need to create a compelling website, it needs to be so compelling that people will actually give you their money. Similarly, your marketing needs to be good enough to actually convince people to buy your product instead of just going to your site.

Odds of success: Low to Medium. Certain kinds of online businesses can do quite well for themselves. In particular, doing business with other businesses (B2B) is a growing online market. 37signals is a pioneer and great example of this kind of company. Be careful though, as consumers are traditionally loathe to part ways with their hard earned money for an online service.

Potential return: Medium to High. A successful online business can easily make tens or hundreds of millions of dollars a year. The key is to be scalable. In other words, being able to grow from 100 customers to 10,000 customers while remaining profitable. One of the nice things about the Internet is that there’s less friction holding back your growth (you don’t need to spend $10 million on a new factory, for example)

4. Be acquired by another company, or go public

This a trend that’s been exemplified by some high profile acquisitions made a few companies including Google, Yahoo and Microsoft. Since the dot-com era, Internet IPOs are much less common, and there are a lot startups whose main goal is to be bought out by a bigger company. It doesn’t always have to be a billion dollar acquisition by Google; there are many small (under $1 million) acquisitions made by medium sized companies.

This is a risky model to say the least. There are many factors that cause an acquisition to take place, most of which are out of the control of a small business. While Google might acquire your company because it creates synergy with their products, they also might purchase a competitor or just build your product themselves.

Investment: Very High. It’s very unlikely that you will be acquired without having a large number of existing users and/or a proven track record. This means not only building your business and marketing it, but sustaining it and growing it to the point where another company finds value in what you’re doing. You almost certainly need outside investments to get you to this point, which means angel funding or more likely venture funding. This opens up a new set of challenges as you now need to market your business to an investor.

Odds of success: Very Low. For every very public example like YouTube (which Google acquired for $1.2 billion) there are countless unseen examples of failed companies who never see the big payday and run out of money trying.

Potential return: Very High. If you’re one of the lucky examples, you can easily make tens of millions (or more). But remember the odds of this happening are low. Make sure you’re willing to take a big risk for a potentially big reward.

5. Get traffic/users, then choose one or more of the above

This is a bit of a side case that doesn’t exactly compare to the examples above, but is worth mentioning nonetheless. There are a growing number of companies that launch without figuring out how they will make money.

The idea is to focus on getting a large number of users, and that when that happens, making money from those users is comparatively “easy”. Twitter is a high profile example of this, having only recently starting to announce a business model. When the time comes, any of the above models can be considered.

Investment: High. Outside funding (angel or venture) is almost certainly required.

Odds of success: This is hard to say, as the market hasn’t really played itself out for this one. My personal opinion is that the odds are still very low, because outside funding means that investors will want a big return, and it’s unlikely advertising will do that. This means one of two things. Either you come up a really great paid service, and even then you’re at a disadvantage as you now have to either convince people to pay for something that used to be free, or create a really good new idea that people will pay for. The other option is to look for an acquisition, which is also risky as discussed above.

Potential return: High. If you’re able to get a large number of users, you get to start with a big customer base. Or if you sell the company, you can possibly get a nice payday.

If you want help building a business, or just want to discuss a potential business, please contact us — online business is our passion!

Filed Under: Online business, Startups Tagged With: , ,

The Secondary Twitter Stream: New Applications You Can Expect Thanks To User Streams

April 19, 2010 By Leave a Comment

At Twitter’s recent Chirp conference, they announced a new “user streams” feature that allows users to receive a real-time stream relevant to them. Today they opened it up for everyone to play with.  They’re very quick to point out that the service is still in development, so we shouldn’t expect any new applications in the near future.

Even if you’re not a developer, there are a few neat things in user streams, which you can expect to start seeing once this functionality goes into production. There are a lot of actions that Twitter users take beyond actually posting tweets. The user streams function opens all of this up in real-time:

  • See who your friends follow. In real-time, you can see who you’re friends are following and unfollowing.  Sometimes, you see people follow a bunch of users in bulk (I’m guessing they’re using a script to automatically follow back their new followers).
  • See favorites and retweets in real-time. Currently, favorites aren’t very widely used, but I could see this growing over time.  A real-time look at what your followers find interesting could be a great way to stay up to date.
  • See all your friends’ replies. Last year Twitter had a minor controversy when they disallowed users from seeing every reply their followers sent.  Instead, you could either turn off all replies, or only see replies when you also followed the replied user.  In user streams, all replies appear to be open again.  I could see this being a great way to find new people to follow, by seeing who your friends are talking to who you don’t follow yet.

All together, I see this creating an entire secondary sort of twitter stream in addition to your main friends timeline. The combination of following, favoriting, retweeting and reply events in real-time can provide a very interesting look at what’s happening by-the-minute in your circle. Tools to aggregate this data can provide a different service, by showing you trends that you might have missed among users who are gaining followers, engaging in conversations, and being favorited.

Filed Under: Twitter Tagged With: , , ,

Twitter: Firehose will be not be made public, available only to "small group of trusted partners"

January 27, 2009 By 1 Comment

Ever since Twitter disabled access to their firehose last year, many users have been waiting with baited breath for its return.  The “firehose” refers to the stream of all public Twitter posts.  Currently, it’s only possible to get a small subset of all public posts, and many types of Twitter applications aren’t possible without access to the firehose, such as real-time track and trend analysis.

For a time, Twitter planned to allow firehose access through a service called Gnip, but in October stated that they would instead work on providing access themselves.  Since then, details have been sparse on the timeline or methods for which access will be given.

Last week however, some more information has been quietly released by means of an FAQ on the Twitter API website.  Here’s the question and answer in full (emphasis theirs):

When will the firehose be ready?

By late January, early February 2009. For at least Q1 2009, the “firehose” (the near-realtime stream of all public status updates on Twitter) will only be available to a small group of trusted partners. The firehose is a stream HTTP solution; a client connects to it and the stream begins, ceasing only when the client disconnects. Once we’re confident in the stability of the service, we’ll add partners on a case-by-case basis. We may allow a wider selection of clients to consume subsets of the public stream (that is, updates from a collection of user IDs or matching specific search terms). We do not intend to allow anonymous, unregulated public access to this stream for any number of legal, financial, and technical reasons.

There’s a few pieces of new information here.  First, that some kind of beta group will be given firehose access within a few weeks, using HTTP streams.  This sounds similar to the solution provided by Gnip to their users.

Perhaps more important though is the news that a full public stream of the type previously provided will not be returning.  While providing subsets of the public stream could be useful for things like groups, without the full firehose it’s very difficult (if not impossible) to provide a feature like real-time tracking, which has been eagerly awaited.

The three pieces of rationale for not making the firehose public (“legal, financial, and technical”) each bring up additional questions in turn.  Legally, is there a difference between providing public tweets in a full stream and providing tweets publicly by user (which requires knowing the username ahead of time)?  Do the financial motivations refer to saving money on servers and bandwidth, or by making money in providing access for a fee?  And technically, are the existing solutions (such as HTTP streams or XMPP) insufficient for the task, and if so, how?

Filed Under: News, Web 2.0

Highlights from 37signals Live

December 4, 2008 By Leave a Comment

Earlier this afternoon David Heinemeier Hansson and Jason Fried from 37signals did a live webcast in which they answered questions and talked about some of their upcoming projects.  They spoke about their upcoming book, plans for integrating across all their products, and how they feel about the iPhone and Android. Architectural Changes 37signals has been trying out Amazon’s EC2.  Rather than implementing it across all their products (a big decision to make, and time consuming to implement) they’ve started by trying it out on Tadalist, which is their smallest and simplest product.  This exemplifies one of the methodologies they use: avoiding huge decisions by first trying small implementations. They also did this with regards to translations.  Translating all 37signals products into multiple languages is a scary idea.  So instead, DHH tried translating only Basecamp to Danish, the other language he speaks. New Features and Designs One of the larger developments 37signals has been working on is a “37 ID”.  This is a global namespace across all of their products, in which users won’t have to login multiple times as they switch products.  It also will aid in product integration, which has been a common question among users.  In the past, they didn’t have a good way to determine which users were the same person across their products.  For example, they wouldn’t know if “dhh” on Basecamp was the same as “dhh” on Campfire.  It will also allow them to start selling their products in a suite, whereby customers could sign up for some or all of the products at once, perhaps with a bulk discount.  37 ID will be rolled out in phases, starting early next year. 37signals has also been working on redesigning the marketing of their sites, and has hired a new designer to work on the visual look-and-feel of their sites.  They’ve started with Highrise.  Below are a few screenshots I took of some of the designs they’ve been working with: The last picture is what they’re currently going with, and it should come out within the next week or two. Upcoming Book A few days ago 37signals announced an upcoming book, with the working title “Unconform”.  The announcement was sparse on details, but today they gave some more information on what to expect. Whereas their first book, the popular “Getting Real”, focused on software development and engineering, “Unconform” is more about business: team structure, hiring, competition, and getting the word out. One of the main themes of the book will be “small isn’t a stepping stone”. Companies should consider stopping at a small size, and not all businesses need to be massive to be successful.  DHH also described the book as pushing against the “lifestyle-business” idea, that small businesses like 37signals aren’t in the “real world”, or don’t have a “real business”. Mobile Jason and David got a few questions regarding their thoughts on the mobile environment, specifically the iPhone and Google’s G1 phone.  They stated that they’ve had an internal debate on whether or not to develop “official” iPhone apps, with the consensus being that they should work on making improvements to their API, and allow third parties to develop applications. They referred to the Twitter model of providing the best API they can, and letting developers work on creating clients on various platforms. When asked his opinion about the G1 phone, Jason Fried described it as more of a “me-too” device, not having many truly new features like the iPhone. For those who missed 37signals Live but would like to watch it, you can watch it on Justin.tv.

Filed Under: News, Web 2.0

What We Do Here (And, We're Looking for Work!)

December 2, 2008 By Leave a Comment

I’m not sure if all of you are aware of exactly what we do here at Draconis Software.  I thought now would be a good time to let everyone know, since we’ve got some availability for new work.

Here are the three main types of work we do, and why we do them:

  1. Web (Rails, Grails, et al): Our bread-and-butter remains in doing web development.  Despite the complexity that HTTP brings you when trying to build an application, there’s still something exciting about the dichotomies that web development brings: web framework and database, server-side and client-side, function and design.  And clearly web companies aren’t going away anytime soon.  For a while now (probably over a year) most of our clients have tended towards Rails, and it’s also our defacto suggestion for new clients.  Lately though, we’ve been doing a bit more work with Grails, which I think is becoming an exciting framework.  We’re also open to some of the older web technologies, like Java or PHP.
  2. Mobile (iPhone): Our decision to branch into mobile development was influenced by one main factor: we’re in love with the iPhone!  Luckily, the iPhone is also a pretty good platform in which to develop, and many of the methodologies from web development can carry over.  Our most recent iPhone project was creating an iPhone interface for Invotrak, which shows how web and mobile development can be bridged.
  3. New Things!: We pride ourselves on being able to tackle new technologies (see #2 above).  For example, as much as we love Rails, we’d jump at the chance to play more with one of the other Ruby web frameworks, like Merb.  I don’t know what the Next Big Thing will be in a year or two, but I hope that we’ll be playing with it when the time comes!

We don’t limit ourselves to any one type of client.  We’ve worked with public companies, pre-venture startups, individuals, and everything in between.

For anyone interested in talking to us, there’s plenty of ways to contact us, including our website, email, or just leave a comment on this post.

Also, I’m curious if anyone reading this has consulting firms of their own (and/or does freelancing)? Let us know in the comments!

Filed Under: Draconis News

How Apple Can Support True Background Applications on the iPhone

October 24, 2008 By Leave a Comment

At the WWDC in June, Apple announced their Push Notifications system, which will give iPhone applications a way to display messages to the user even when their app isn’t running. While this will give chat, microblogging and feed reading applications some semblance of running in the “background”, many users (including myself) haven’t been thrilled with this solution (and not just because it’s still not out yet!), as it doesn’t allow for cases like music streaming, or background location polling.

At the SDK event, Apple gave a number of reasons why they didn’t want to support true background processes for iPhone applications:

  1. Having lots of applications running could quickly use up the limited resources and battery on the iPhone, causing performance problems.
  2. They didn’t want the user to have to worry about managing active programs with some kind of complicated “Task Manager” interface.
  3. If applications could continue to run in the background without any visual cues to the user, it would be that much easier for apps to perform unintended/unrequested operations.

I think there’s a way for the iPhone to provide better support for background applications, without breaking the requirements listed above. Think about what happens when you’re on a call, and you tap the Home button. You can launch applications, and pretty much do whatever you like while still on the call. Here’s what this looks like:

You’re aware that you’re still on a call because of the bar at the top of the display, and you can tap to return to the call if you wish. I think background applications could work the same way, and in so doing wouldn’t break any of Apple’s requirements:

  1. Only one app could be in the background at a time, so you wouldn’t have lots of apps hogging the resources of the phone. Yes, you’d have another process using resources in addition to the foreground application, but it wouldn’t need to use any of the graphics framework, and in my experience the iPhone would be powerful enough to handle this kind of limited processing.
  2. Nothing is hidden from the user. They know exactly what’s happening in the background because they’re being told at the top of the screen, and can tap that bar to return to the app. Another nice benefit here is that perhaps the application could customize what gets displayed in this line, so an app like Pandora could have the row say “Now Playing: Enter Sandman by Metallica”.
  3. No Task Manager is necessary. The way users interact with the background app is intuitive because background phone calls already work the same way.

Of course, this isn’t a perfect solution since only one app is running in the background at once. If you want something to run 100% of the time, then you’d never be able to run an additional background app on top of that. However, I think a system like this in addition to the Notifications framework solves most of the desired use cases for background apps: music playing/streaming, location polling, real-time text updates, and so on.

What do you think? Would this kind of system solve the problems you have with background apps on the iPhone?

Filed Under: Apple Tagged With: ,

A Rails Developer's Thoughts On Using Grails

May 15, 2008 By Leave a Comment

We strongly believe in using the right tool for the job.  While we currently think of Rails as the de facto choice when it comes to writing webapps, we’ll always consider other options, such as one of the many other Ruby web frameworks, or going with another language such as Python.

Lately I’ve been looking for a chance to play with Grails.  Briefly, for those who aren’t familiar, Grails is a web framework that uses the Groovy language – an agile, dynamic language designed for the Java Platform.  Grails was meant to use some of the main tenets of Rails (convention over configuration, “Don’t Repeat Yourself”, et al) while using Java web technologies like Spring and Hibernate.

Fortunately, I was finally able to find a chance to play around with Grails – as a simple way of “porting” an existing Java web application to a dynamic language and framework.  My reasons were the following, which I’d imagine are true for many other Grails developers:

  1. The ability to include straight Java code in the project meant being able to re-use existing code, especially if it was not directly related to the webapp.  For example, I was able to take a terse image generation function and drop it right into the project.
  2. Having the framework based on Spring, Hibernate, Acegi and Sitemesh meant there were fewer conceptual changes moving from the old code-base.  Working on the code I often felt that I was maintaining the original ideas while reducing the inherent verbosity of Java.
  3. The previous point applies to the interface code as well – the views in Grails use GSP, which is very similar to JSP and made porting the views almost trivial.
  4. Moving from another Java framework to Grails requires less of a “sell”.  A Grails project packages as a WAR file no different from any Java project.  It will have all the positives (and negatives) of a Java app.

So, having used Grails a for a while now, how does it stack up to Rails?  Here a few of the things I enjoyed about Grails:

  • The GSP tags have the power of JSPs, along with a few features that make them simpler.  They’ve also added some tags that don’t have equivalents in JSP, and are quite nice.  In particular, I liked using the “sortableColumn” tag, which generates columns in tables that handling sorting.  This is something I would like to use in Rails.
  • Grails does not currently use migrations (schemas are generated from field declarations in model objects), and while for some projects this could be an issue, it made development that much faster to add a few fields and have the database automatically be updated.
  • By default Grails uses a messages.properties file that contains message codes like validation errors and other generic error messages.  In some ways it’s nice having all these messages in one place. Also, the validation errors use a default message per constraint type, which can then be overridden.

 As well as some caveats (I won’t go so far as to say “problems”):

  • Grails uses some different terminology than Rails.  Models are “domain classes”, validations are “constraints”, and so on.  Not much of an issue, but it may take some getting used to.
  • The form helpers in views are not as sophisticated as Rails.  Less boilerplate code is generated for you, and more thought has to be put in to maintaining states and values of form elements.

Of course, there’s nothing that Grails does that couldn’t be done in Rails with a bit of extra code or a plugin, and I’d imagine for the most part this is true for Grails as well, so it’s really more about simplicity and core conventions.  I’m still working on the port, so I’ll be sure add updates as I get more experience.

Filed Under: Rails
« Older Posts