Saturday, May 15, 2010

Twitter Integration

I previously wrote about Facebook Connect. However, Facebook is not the only social network out there. Twitter is another popular network.

The implementation process is similar to Facebook Connect. I will list the steps:
  1. Register your app with Twitter.
  2. Download and copy MGTwitterEngine into your source code.
  3. Create an MGTwitterEngineDelegate and an MGTwitterEngine object.
  4. Create your own login page for Twitter.
  5. Pass the user’s credentials to MGTwitterEngine.
  6. Authenticate the user’s credentials.
  7. Start tweeting!
To start, you will need to register your app with Twitter. This can be done at http://dev.twitter.com/. This is also where you will find all of the API documentation and other information. Unlike Facebook, only one user can be a developer for a particular app. So, you may want to create a Twitter account specific to your app or company to handle the development of your Twitter features.

Another point to note is that after June 30, 2010 your app will have to use OAuth (or xAuth) for authentication. I won’t go into the details here. Consult the Twitter documentation for details.

Now you can start implementing Twitter into your app. Unfortunately, Twitter doesn’t have a convenient Xcode project to use. This will require using some third-party software. I used MGTwitterEngine. It is produced by @mattgemmell. His code can be found at http://mattgemmell.com/.

MGTwitterEngine revolves around the use of the MGTwitterEngine object. This isn’t nearly as advanced as Facebook Connect. You will have to handle the login dialog and automatic re-login on your own. A user’s credentials can be securely stored in the iPhone’s keychain. Details on the keychain can be found in the iPhone API.

Logging in takes several steps. You will first need to create an MGTwitterEngineDelegate before creating an MGTwitterEngine object. Once you have prompted the user for their user name and password, this can be passed on to MGTwitterEngine by the following method:
[twitterEngine setUsername:(NSString *)name password:(NSString *)password];
However, this does not authenticate the user name and password. It simply stores them in the MGTwitterEngine. Verification can be received by calling:
[twitterEngine checkUserCredentials];
This will make a call to the API to verify the user’s credentials. This method does not wait for the verification to return. Instead, one of two MGTwitterEngineDelegate methods will be called when the verification returns. These two delegate methods are:
- (void) requestSucceeded:(NSString *)requestIdentifier
- (void) requestFailed:(NSString *)requestIdentifier withError:(NSError *)error

Since these calls occur asynchronously, you will need to handle this accordingly. Some options include blocks, GCD, and/or how ever else you want to handle it.

From here you are ready to start using Twitter from your app. MGTwitterEngine provides several methods for doing various actions. One you will likely use is
[twitterEngine sendUpdate:@“Hello World!”];
This will send a tweet as you would expect. Remember to keep tweets to 140 characters.

Your now ready to make Twitter a part of your apps. Happy Tweeting!

Friday, May 14, 2010

Facebook Connect

UPDATE: This post was written for the Facebook REST API. The REST API is now deprecated and you should use the Graph API instead. I may write a new post on the Graph API in the future.

This time I’m returning to a topic I learned months ago - Facebook Connect. However, I need a refresher on it. One of the great luxuries of programming is adding functionality without writing the code personally. Fortunately, Facebook has created an API that works well on a multitude of platforms. With this API, an iPhone app can become more interactive as users share with others what they are doing with it. This also results in an app receiving greater visibility to the public.

Anyway, several months ago I added Facebook and Twitter support to Police Scanner 2. My biggest struggle with implementing Facebook support was that the iPhone documentation is very minimal and not as explicit as I would like. I figured out almost everything simply by trial and error. Hopefully this blog post will shed more light on the subject.

This tutorial is lengthy, so I will start with an overview of the steps:
  1. Create a Facebook app.
  2. Download and copy Facebook Connect into your source code.
  3. Create an FBSession with your API key and secret key.
  4. Login to Facebook via a FBLoginButton or FBLoginDialog.
  5. Enable auto re-login.
  6. Create delegate(s) that conform to the FBSessionDelegate and FBRequestDelegate protocols.
  7. Request the permissions you need.
  8. Perform actions with FBRequest.
One of the first steps to take in implementing Facebook Connect is creating a Facebook app on Facebook itself. To do this, you must add the Facebook Developer app to your profile. Finding the app is near impossible. I found it through a link on the developers page. The URL to the app is http://www.facebook.com/developers/. From there a Facebook version of your app can be created. Even though you are creating an “app,” you won’t be using it as an app. Instead, this will be the channel through which your iPhone app will interact with Facebook. This also provides some basic analytic information and creates a Facebook page for your app. I won’t go into any of the details of how to set everything up. That could be a lengthy topic by itself. Personally, I found the basics to be straightforward enough. There are many advanced capabilities that can be explored if you so desire.

With your Facebook app in place, you can now start adding the functionality to your iPhone app. You will need the Facebook Connect Xcode project. You can Google it or find it here. I found it easiest to copy the Facebook Connect project code into your own project. The greatest part of Facebook Connect is that almost everything is done for you.

Once the code is copied into your project, just #import “FBConnect.h”. Next, create a FBSession object. You should retain this object for the lifetime of your application. This is where you will need your previously created Facebook app. On the application settings editor page there is an API key and app secret key. These are necessary for creating your session object. They can be stored as string constants and passed in as parameters. the following gives an example of this.
session = [[FBSession sessionForApplication:FBAPIKey secret:FBSecretKey delegate:self] retain];

Next, to login to Facebook. This can be two different ways. The easiest is to create a FBDialogButton and add it wherever you please. If my memory serves me well, there are three different sizes of buttons that can be used. Alternately, you can create a FBLoginDialog and call that however you like. This can be done as follows:
FBLoginDialog * dialog = [[[FBLoginDialog] alloc] initWithSession:session] autorelease];
[dialog show];
Either way, a nice login dialog pops up and takes care of everything.

Facebook Connect handles automatic re-login. All you need to do is call [session resume]; when your app starts. If a user has never logged in or explicitly logged out, then this will do nothing. Also, sessions automatically expire if they are left idle for two hours.

I failed to mention earlier that you will need an object that conforms to the FBSessionDelegate protocol in order to create a session. It has a single required method:
- (void)session:(FBSession *)session didLogin:(FBUID)uid;
You can use this method as an opportunity to set a flag in your app that the user has logged into Facebook. This is also a great opportunity to request any permissions you will need later.

While on the topic of permissions, I will expound some more. FBPermissionDialog is used to request different permissions. This has two delegate methods as defined in FBRequestDelegate.
- (void)dialogDidSucceed:(FBDialog *)dialog;
- (void)dialogDidCancel:(FBDialog *)dialog;
It should be clear which does what and when it is called. The following is an example of requesting permission to publish to a user’s stream:
if (!FBPermissionsGranted) {
        FBPermissionDialog * dialog = [[[FBPermissionDialog alloc] init] autorelease];
        dialog.delegate = self;
        dialog.permission = @"publish_stream";
        [dialog show];
}

There are several different permissions that can be requested. Consult the Facebook documentation for the specifics. The only change that needs to be made to the following code is the string representing the desired permission.

One important note, Facebook remembers if a permission was previously granted. So if you request the permission a second time, the dialog window pops up and immediately closes. This quick flash is annoying and should be avoided. This can be done by saving the state of permissions granted and/or making an API call that requests the user’s granted permissions.

Now that you’ve got a user to login and granted the necessary permissions, let’s have your app do something. This is done through FBRequest. A request will look something like this:
[[FBRequest requestWithDelegate:self] call:@“some action here...” params:params];
The string is the API call to use. For example, to publish to a user’s stream call @“facebook.stream.publish” or update a user’s status with @“facebook.Users.setStatus”. The params is an NSDictionary that contains the parameters specific to that API call. Consult the Facebook API for the details. Some parameters are optional whereas others are required. If we were to publish something to the user’s stream we could set up the parameter like this:
NSDictionary *params = [NSDictionary dictionaryWithObject:@“Hello World!” forKey:@"message"];

FBRequests are where the action of Facebook Connect comes in. With the proper permissions you can do anything with a FBRequest. For example, you can upload videos, check if a user is a fan of a particular page, create events, etc. Basically, anything you can do on the Facebook website, you can do from the API. Just call the desired method, such as “video.upload,” “page.isFan,” or “events.create,” then pass in the necessary parameters. Facebook even has their own query language (FQL). This is comparable to SQL. Another point to note is that Facebook also provides a test console with each API call to test if a call works and what exactly it is returning.

I hope this lengthy tutorial is beneficial. I provided only simple examples, but really your imagination is the limit. Most of the process is very implement. The challenge comes in when making requests. Getting the parameters and return values right can take some trial and error. Making use of the Facebook test console makes life much easier.

Monday, May 10, 2010

UITableViewCell Reuse Cautions

Here’s a problem that perplexed me for quite some time today. I was making an options page for an iPhone app. I set up a UITableView with a few different sections. Each section contained different kinds of options such as dates, times, and switches. Due to the variations in options, some cells were set up differently from others. For the switches, I added a UISwitch as a subview to the content view of a cell. For dates and times, I was displaying the date or time as a detailed text label. Everything looked nice, that is until I scrolled. When scrolling, the cells had a mix of UISwitches and text labels mixed together. It was a mess. After several hours of reading documentation I uncovered the source of the problem. Ironically, it was something small and simple. When a cell scrolls off the screen it is reused as one of the cells scrolling onto the screen. Normally there are no problems with cell reuse because the cells of a table are usually uniform in use and layout. When a cell is recycled, all of the old values are usually overwritten by the new values. In my case, I wasn’t using all of the properties for all of the cells. This lead to the conflicts that left me bewildered for so long.

Removing the detailed text label was easy. All I need to do was set the it to an empty string. Removing the UISwitch wasn’t as easy. Fortunately, I found a piece of code on stackoverflow.com that helped me out. What I did was get all of the subviews from the cell’s content view and release them. It looks like this:

NSArray * subviews = [[NSArray alloc] initWithArray: cell.contentView.subviews];
        
for (UIView * subview in subviews)
        [subview removeFromSuperview];
        
[subviews release];

It was a small change but made all the difference. With those changes in place, my options page was flawless. I never cease to be amazed by all the bugs that result from simple mistakes.

Saturday, May 8, 2010

Deleting cstrings

While working on a URL resolver project, I came across a curious aspect of the nature of cstrings. To start out, I was creating a URL object with a string constant as an input. Example: URL * url = new URL(“http://www.google.com/“); In my URL object, I was simply pointing to whatever string was passed in. I should have known better than to do that. Java has made some bad habits in me. Aside from that error, I noticed that I would always get a segfault when trying to delete the cstring the URL was stored in. Later I found that this error was eliminated by copying the string input rather than simply pointing to it. After looking through some memory dumps I have concluded that the reason for the segfault was due to attempting to delete memory that I didn’t have permission to access. In this case the string constant I was passing in was part of my program. I could really make a mess of things if I had been permitted to overwrite that memory.

EDIT:

Since writing this post, I have learned that string constants are stored in the static data area of the memory model. This is separate from where the code is stored in the memory model.

Saturday, May 1, 2010

Makefile Exploration

In my preparation for CS 240 this upcoming summer term, I delved into the C++ and Makefiles. For one of the class projects we will be making some basic data structures. I got a great start one them. There’s really not much to linked lists and such anyway. Not far into the project I grew tired of compiling everything by hand. Plus, one requirement of the project is to create a makefile. I had some previous experience with makefiles from CS 124. I looked up my old makefiles and had a good makefile up and going in no time.

Of course, as a good developer, I wanted to make the most out of code reuse. I wanted to create makefiles for following projects with little or no effort. A quick Google search revealed exactly what I was looking for. I found a short, simple makefile example that I could customize to my needs by changing only a couple lines.

After reading through more of the requirements for the projects, I soon discovered that the overall structure of the project was more complicated than I anticipated. All of the source files were to be in one directory, the header files in their own, the unit tests in another, and so on. My simple makefile only worked when all of the files were in the same directory. This time, not even Google could find results that worked for my particular wants.

I consulted the GNU make documentation directly. After a couple hours of thorough studying, deep thought, and many errors, I arrived at a solution. My first difficulty came with accessing the different files. I had a variables for each of the directories and a variable containing all of the source file names. The problem was combining the two so that directory didn’t have to be specified for each source file name. It turns out that make has a foreach function. That easily fixed the first problem.

Once the file access problem was resolved only one more problem stood in the way. This one stumped me for a while. My rule that compiled .cpp files to .o files didn’t seem to be working. The target name was .cpp.o: (this is shorthand for %.o: %.cpp). Even the GNU make manual didn’t supply a sufficient answer to this puzzle. The answer came while poking around stackoverflow.com. Someone else had a related question. From some sample code provided I changed my target to $(OBJ_DIR)/%.o: $(SRC_DIR)/%.cpp. OBJ_DIR is a variable containing the name of the directory to where .o files are stored and SRC_DIR is where the source files are kept. What I came to realize is that although the % operator for all intents and purposes is a wildcard, it stays within the directory. Basically, my rule was telling the makefile to look for any .o and .cpp files in the root directory of my project. What I really wanted was the makefile to look in the respective directories for the files. As always, it’s the simple mistakes that trips up a program.

In addition to creating the basic targets, I created a few others for convenience. Some include clean, test, run, etc. I haven’t done anything yet with building unit tests and library files. That will come in due time as I find out more of what my professor expects.

I would post my source code, but I won’t so that my fellow students won’t be tempted to copy and use it without first learning how everything works by themselves. However, my source code is available at request.

Intro

The purpose behind creating this blog is twofold. First, I am documenting what I learn as I dive into various topics of programming. I often find I learn something new or discover a solution to a bug just to forget and relearn it at a later time. Second, I hope that what I document may be insightful to others who are learning for the first time or have encountered similar difficulties.