SQLite Database Caching On iPhone Simulator

As I was doing some development on my iPhone app yesterday night and this morning I ran into an issue that I figured I would blog about and hopefully it may be of use to some stray Googler in the future.

In a nutshell, the issue is that the iPhone Simulator caches the SQLite database in a local Mac OS X directory to improve performance, so I was getting runtime errors about tables not existing from the Xcode Console, which of course was driving me absolutely mad since the SQL file itself in the project bundle showed the database table being there!

After double and triple checking my models and controllers, and verifying that everything was hooked properly in my NIB files, I set out to do some Googling to see if I could determine what could possibly be wrong. As mentioned above, I knew the table in question was in the database, because if you opened the .sql file you could see it plain as day. But at the end of the day it seems that deleting your old database file from Xcode and adding the new one simply may not be enough, as in my case I had to actually go to the directory on my Mac where the iPhone Simulator stores all the files it uses to build the apps and delete the directory of the app I am building. Then, upon re-building, it pulled a fresh copy of my files (with my new database) and voila!

So, where is this mystical iPhone Simulator directory? It’s a bit of a hike but to get there just follow this path:

/Macintosh HD/Users/<username>/Library/Application Support/iPhone Simulator/User/Applications/

Once you’re in there you’ll see a bunch of directories with some cryptic directory names. Just browse around each one until you find the application in question and then delete the one you need to.

That should do it. Once done go back to Xcode and Build/Run and your updated SQLite database should be brought into your project. Hope this information helps someone. Any questions feel free to ask in the comments.

Read More

First Impressions on Objective-C and Developing with the iPhone SDK

One of my New Year’s resolutions for 2009 was to get off my arse and write an iPhone app and get it published in the App Store. Not much progress was made in the way of attaining this goal during January and early February of this year, as the 60-70 hour work weeks have steadily continued from last year into this year. However, in mid-February I finally got the motivation to get started on this endeavor. I ordered an Objective-C book and an iPhone SDK Programming book from Amazon and eagerly awaited their arrival.

A few weeks later they arrived in the mail and I began to dive into iPhone programming. I recall big Steve saying back in the day that for anyone wanting to program on the Mac (and thereby iPhone since it runs Mac OS X) they ought to learn Objective-C, as that is the main language that Mac applications are written in. So I started off with the Objective-C book, reading the first hundred pages or so.

Most of the high-level concepts of the language are very similar to what I already know. My first real programming class (html doesn’t count) was back in the fall semester of 2002 at community college in California, an Introduction to C++ class. At the time I loved that class, I was using Red Hat 7 and writing everything in EMACS and compiling via the command line with gcc. It was great and I had serious aspirations about being a computer science major. Alas, the advanced mathematics requirements and me didn’t mesh well so that was the end of my computer science experience in college. After college I was heavily involved with a friend’s nightlife web site called Partybody and over the course of 6 months to a year taught myself PHP. Over the past few years since then I have become fairly knowledgeable in PHP and have started branching out into other languages like Python and Ruby. The reason I mention all this is because in my experiences with Objective-C so far, the fundamentals seem to be pretty similar (variables, loops, function, etc.), albeit the syntax is a bit different, which is where the real learning curve comes into play.

Despite using a completely new language, I’m utterly thrilled at the amount of progress I’ve been able to make so far in the little time I’ve had to devote to iPhone programming. Apple’s IDE Xcode is shaping up to be the best programming tool I’ve ever used — which says a lot because I absolutely love Coda. Fact is the CodeSense built into Xcode is phenomenal!

Additionally, I must say thank you to Stephan Kochan, author of Objective-C 2.0, and Dave Mark & Jeff LaMarche, authors of Beginning iPhone Development, their two books are very easy to follow and unlike most programming books I read, they’re actually teaching me something!

As I said before I read about 100 pages in the Objective-C book before switching over to the Beginning iPhone Development book, of which I am currently on Chapter 8. But already I have been using Xcode and Interface Builder extensively, and Apple’s iPhone Simulator software is truly remarkable.

After only a few hours of programming I’m starting to churn out real-world type applications that I feel I can later reuse the code base into developing my own apps to submit to the app store. I haven’t had this much fun developing in ages!

iPhone App Slot Machine

Now if only I just had some more free time to code….I can’t wait to see the results.

Read More

My First Linux Shell Script

Last week I wrote about my Ubuntu installation. At the end of that post I promised some Linux-related posts in the future, and here is my first one.

In my opinion one of the things about Linux that makes it so powerful is the shell. And as powerful as the shell can be, it becomes even more powerful when you create a shell script to execute a multitude of commands. Nobody wants to type ten commands in a row in order to achieve a desired result. Further, nobody wants to type the same ten commands in a row every single day. Enter the shell script.

My first shell script started out as a bit of experimenting but has evolved into quite a useful utility. The end result is a script that automatically backs up the development area of partybody.com at a specified time each night, stores a copy locally on the server, and emails a copy to the relevant administrators.

Let’s take a look at the code (some values have been changed for security reasons):

1 #!/bin/bash
3 # “scriptname” – copies all contents of a directory into time stamped tar.gz file in /path/to/backup/file
5 TD=$(date +%T-%d_%m_%Y)
6 FILE=”/home/user/web/cms/backup-$TD.tar.gz”
7 DIR=”/home/user/web/dev/”
9 # Create the gzipped archive file
10 tar -zcvf $FILE $DIR
12 # Send successful backup notification email
13 DEST=”/web/cms”
14 FILENAME=”backup-$TD.tar.gz”
16 echo “Automated backup ran successfully at $TD and created file: $FILENAME in FTP location: $DEST.” | mutt -s “Daily Automated Backup Complete” -a $FILE -c cc_email@yoursite.com to_email@yoursite.com

To get an idea of what’s going on here let’s examine this code line-by-line.

Line 1 is simply telling the script to use the BASH shell environment. Certain shell environments allow for different scripting capabilities than other shell environments, so it’s necessary to declare which one you’re using on the first line of your script. Note: BASH is the default for most Linux distributions.

Line 3 is a comment. The # character at the beginning of the line tells the shell to ignore all content on that particular line. In this case we’re just using the comment to identify the name of the script and a description of what it is intending to perform.

Line 5 creates our first variable, TD, and gives it the value of $(date +%T-%d_%m_%Y). In this instance we are accessing the built-in date function of the BASH shell and pulling out some values like time, day, month and year in order to create a time stamp.

Line 6 creates a variable called FILE and gives is the value of the backup file to be created. In other words, we’re specifying the filename we want to create and the location where we want to put it.

Line 7 creates a variable called DIR and gives it the value of the directory that we want to backup.

Line 9 is a comment declaring the action that we want to take next, in this case, creating the actual gzipped file.

Line 10 creates the archive file and gzips it taking the $DIR variable as input and the creating the $FILE variable as output.

Line 12 is another comment declaring the final action the script will take, sending the email to relevant administrators.

Lines 13 and 14 are variables that contain values to include as descriptors in the notification email, and have no effect on the execution of the script.

Line 16 echo’s the notification message into the email as the body content. The program Mutt is used to send the email. It accepts the piped input from echo and we specify a subject using the -s flag, an attachment using the -a flag, and a cc address using the -c flag. All that together sends an email to the “to” and “cc” email addresses with the subject of “Daily Automated Backup Complete” and attachment of the $FILE (”/home/user/web/cms/backup-$TD.tar.gz”) the script created.

And that’s it. Only 16 lines to backup any directory (including sub-directories), store a copy on your server, and email to whomever you wish.

There is still one problem with this script, though. As it stands it must be manually executed in order to run, and who wants to have to ssh into their server every time they want to run a backup. Therefore, we must auto-schedule the script using cron.

Cron is a time-based scheduling service driven by a crontab, a configuration file that specifies shell commands to run periodically on a schedule. Basically, we just need to add a line to this crontab file telling the shell to execute our backup script at a time of our choosing.

In this case, I added the following line to my crontab file to execute the script every day at 3 a.m.:

0 3 * * * /path/to/script/scriptname

Also, one final note, be sure to make your script executable or else it will not run. We can do this by using chmod +x as follows:

chmod +x /path/to/script/scriptname

That’s all for now. You should be able to adapt this code into a backup script of your own. Feel free to ask any questions in the comments section below.

Read More

Bobbles WordPress Theme Similiar Topics Bug Fix

As you may or may not know, I recently switched to the Bobbles WordPress Theme from Dezzain.com. It truly is a gorgeous theme and has a very “Web 2.0″ feel to it with a lot of social web integration. In using and exploring Bobbles I came across a bug that I informed the creator of, but I decided to take matters into my own hands and come up with a fix.

The bug is small but nevertheless needed to get fixed. If you were looking at a single post — therefore in the single.php file of the theme — you would see a “Similiar Topics” section with related entries to what you were looking at, but when hovering the mouse over a link you would get the_excerpt() from the current post you were reading. So the solution was to change the code to pull the_excerpt() that corresponds to the title of the related post.

After a few hours of hacking away at it here is the code (in single.php) that I changed to get it working:


Essentially there are three things that need to be done: 1) add the getWords() function between lines 52 and 61 — make sure it’s not inside the foreach loop or else you will get errors as you can only declare a function once; 2) add the variables between lines 63 and 65 — these will go inside the foreach loop because they need to get done for every related post; and 3) change the value of the anchor tag title attribute in accordance with line 67 so that it outputs the final variable $a_title.

If you want to show more than the first 15 words change the number on line 64 to however many words you want to show, and if you don’t want show the three dots (…) after the excerpt just take out . “…” from line 65.

Let me know if you have any questions or experience any problems.

Read More

How to Customize Your Sidekick 3 Background

Here is a quick and dirty tutorial about how to customize your Sidekick 3 background in 10 easy steps, which is ever so necessary as the default ones from T-Mobile are atrocious.

Step 1 ) Plug the USB cable that came with your Sidekick 3 into your computer and into your Sidekick.

Step 2 ) Navigate to the drive where your Sidekick was mounted. (In most cases your computer will auto-detect and you may choose to browse the files in the folder, however you may need to double-click My Computer and then access the letter drive the Sidekick was assigned to)

Step 3 ) Once on the Sidekick drive on your computer, make a new folder called Themes

Step 4 ) Now make another new folder inside of the newly created Themes folder, calling it whatever you want the name of your custom theme to be.

Step 5 ) Select the main picture you want to use for your theme, this image should be a PNG or JPG file and must have dimensions of 240×138.

Step 6 ) Select the picture that you want to use for your sub-categories. (For example when you click Instant Messaging or Organizer on your Sidekick 3) Again, this image should be a PNG or JPG file and must have dimensions of 240×138.

Step 7 ) Open any text editor program, Notepad will do just nicely, and copy and paste the following into a blank file:

ThemeName #
string Name(en_US) ThemeName
bitmap ring-background FileNumberOne.png
bitmap ring-folder-background FileNumberTwo.png

  • Substitute the name of the folder you created in Step 4 with ThemeName
  • Change FileNumberOne to the name of the image you selected in Step 5
  • Change FileNumberTwo to the name of the image you selected in Step 6
  • Save this file as Theme.txt

Step 8 ) Copy all of the files (2 images and Theme.txt) into the folder created in Step 4

Step 9 ) Make sure all of the files transferred to the folder and unplug your Sidekick 3 from the USB cable

Step 10 ) Go to backgrounds on your Sidekick 3 and select your newly created one and enjoy!

Example of my Sidekick 3 background:


Read More