Basically the problem was that I had nested my UITextView inside of a UIImageView. This seems innocuous enough but UIImageView does not have the userInteractionEnabled flag set to YES by default. Therefore the event was dispatched up to that view from the main thread and was blocked because the view would not handle and propagate the event.

So the solution was to set the UIImageView’s userInteractionEnabled flag to YES.

    self.userInteractionEnabled = YES;

I think there could be other views that are set up like this as well, although I am not sure which ones they would be. So watch out for this, especially if you are defining your views in code.

I hope that this shows up in someone’s Google search and helps them out.

1. Add your custom font files into your project using XCode as a resource
2. Add a key to your info.plist file called UIAppFonts.
3. Make this key an array
4. For each font you have, enter the full name of your font file (including the extension) as items to the UIAppFonts array
5. Save info.plist
6. Now in your application you can simply call [UIFont fontWithName:@"CustomFontName" size:12] to get the custom font to use with your UILabels and UITextViews, etc…

It’s that simple!

Error Domain=NSCocoaErrorDomain Code=256 UserInfo=0x3baae90 "Operation could not be completed. (Cocoa error 256.)

Talk about not Helpful.

Inside this there was a userInfo dictionary with the following message:

error during SQL execution : constraint failed

Slightly more helpful, but not by very much.

We came across this error message while we were developing our Electrophobe game. We started the debugging process by inserting logging code and pinpointing where the code was failing out. After about 6 hours of work combing through both code and rebuilt databases we finally found the solution.

The trick was that the primary key store for the SQLite3 database that was backing our CoreData NSPersistenceStore had an incorrect value for the Z_MAX column. This column is used, we believe, to house the maximum primary key in order to quickly retrieve it for additional inserts.

As is evident from our escapade however, it is clearly a little vulnerable to tampering when loading the data directly into the SQLite database. To fix the issue, simply update the table with the max(Z_ID) from the referenced table and it should all hook up again.

First I had the need to post multiple files in the same post request up to a web server. The ASI stack has a basic method for attaching an NSData object to your request data. This method simply takes in the data and assigns it “filename” as the default filename for the data that is passed in. Realistically there is no way for ASIFormDataRequest to infer the filename from the binary data. However, this can be quite useful when you are posting binary file data to a web service as the web service is often looking for unique filename identification of each binary part of the posted multipart-form request.

In order to enhance the ASIFormDataRequest to handle this scenario we simply modified the setData: forKey: method to have an override that sets the filename property.

- (void)setData:(NSData *)data forKey:(NSString *)key
{
	[self setData:data forKey:key withFilename:@"file"];
}
 
- (void)setData:(NSData *)data forKey:(NSString *)key withFilename:(NSString *)filename
{
	if (!fileData) {
		fileData = [[NSMutableDictionary alloc] init];
	}
	NSMutableDictionary *file = [[[NSMutableDictionary alloc] init] autorelease];
	[file setObject:data forKey:@"data"];
	[file setObject:filename forKey:@"filename"];
	[fileData setValue:file forKey:key];
	[self setRequestMethod:@"POST"];
}

By adding the override on the method we have maintained the core functionality and extended it to allow for multiple files with multiple file names.

To fix the problem, we’ve come up with a very simple OAuth example using the Twitter Provider. You’ll need the oauth gem for this to work:

#!/usr/bin/env ruby
 
require 'rubygems'
require 'oauth'
 
consumer = OAuth::Consumer.new "twitter_provided_consumer_key",
                     "twitter_provided_secret_key",
                      { :site => 'http://twitter.com/',
                        :request_token_path => '/oauth/request_token',
                        :access_token_path => '/oauth/access_token',
                        :authorize_path => '/oauth/authorize'}
 
request_token = consumer.get_request_token
puts "Place \"#{request_token.authorize_url}\" in your browser"
print "Enter the number they give you: "
pin = STDIN.readline.chomp
 
access_token = request_token.get_access_token(:oauth_verifier => pin)
 
puts access_token.get('/account/verify_credentials.json')

As you can see, the OAuth gem deals with most of the dirty work, as a matter of fact, almost half of the example file is environment, dependencies and user interaction. There is really only three lines that have any real use.

The boys put on a show with the BeefyBoard.

I think the first thing to realize is that when your application is deployed onto your iPhone/iPod/Simulator you are deploying a complete package. This means that the contents, i.e your code, resources, database and anything else that might be part of your deployment bundle are uniquely signed using your developer’s key which verifies that everything you intended to be in there is there and nothing else. This is a very important concept from a security standpoint and it allows the target device to verify the validity of the bundle to ensure that your application has not been compromised. Now that we have stated that, it’s pretty obvious that it will be impossible to change the deployed project. This doesn’t mean that Apple didn’t think of this inevitability.

The first step to looking into this deployment will be looking at the target deployed file system. The easy way to find this is to log the applications bundle path in the applicationDidFinishLoading method on the appDelegate. You can do this with the following code:

The output (in the console) for this will show you where you can find the file system. I usually just copy and paste this into a terminal window and jump right to it (just make sure to wrap the directory name in double quotation marks).

If you navigate tot this directory you will see your application (yourapp.app) which is a directory containing all of your code and resources and a Documents and a Library directory. That Documents directory is where our dynamic content will reside.

This seems straightforward enough, just put what we need in the directory and away we go, right? Well not so quick cowboy, there is no idea of an installer that executes when your application downloads. This means we are going to have to figure out how to copy the files into the Documents directory the first time the application loads.

Over here at BeefyApps, we developed this little snippet of code to handle this initial load of data.

So the code above simply takes a look inside of the bundle, navigated to via the [[NSBundle mainBundle] bundlePath] command. The result of this call will provide you with the string location of the applications executing bundle directory. For the purposes of this code we have a Documents directory which resides inside of the bundle path. We then take the contents of that directory and conditionally copy it file by file into the writable Documents directory.

Pretty simple solution really. I think where this gets interesting is when we start to consider the ramifications for updating your application. I’ll leave that exercise up to the reader at this time though.

This does assume that you are using the default paths.

We are most electrified about the features that you can’t see in the screenshot.

]]> http://blog.beefyapps.com/2009/07/upcoming-new-iphone-game/feed/ 0 http://blog.beefyapps.com/2009/07/upcoming-new-iphone-game/ http://feedproxy.google.com/~r/BeefyappsBlog/~3/tkWSw1Cjjnw/ http://blog.beefyapps.com/2009/06/beefyboard-iphone-soundboard-ready-for-iphone-os-30/#comments Wed, 17 Jun 2009 23:28:01 +0000 Sanjeev http://blog.beefyapps.com/?p=233 With the new iPhone OS 3.0 being released today, we here at BeefyApps have been busy updating BeefyBoard: iPhone Soundboard for use with OS 3.0. We’ve found that some of the sound features that worked in OS 2.2.1 were no longer compatible with OS 3.0, specifically recording a sound to the phone and then switching back to playback.

With a little bit of work we’ve fixed these problems and have submitted the new app for approval. The new version should be available to download early next week if the approval process goes smoothly. We’ve also taken the opportunity to add more features to BeefyBoard that will make it the best iPhone Soundboard out there.

What this means to existing users of BeefyBoard and those that purchase it within the next few days is that if you upgrade to OS 3.0, some of the functionality of the app will be broken until you update to the new version of BeefyBoard (when it becomes available on iTunes).

New Features in Version 1.1

• Added Board Ratings
• Added Board Comments
• Added Skin Ratings
• Added Skin Comments
• Added Skin Affinity
• Added Settings Controls
  • Enable/Disable skin affinity
  • Shake sensitivity
• Added Upload Progress Bar
• Stop Recording By Pressing Any Button
• OS 3.0 Compatibility fixes