CODE2K:LABS Blog Archive

Improving an iPhone App

Written on September 23, 2009

As the competition in the iPhone application market is getting more and more intense it is an important challenge for every application developer to build a successful application. First you have to find your niche and provide the perfect application for it and then you have to deal with some of the problems the App Store comes with.

Getting an update to the store can be a very lengthy process. And if you have new features it might be even possible that your App is rejected by Apple. So if you have an critical bug which you can fix in 5 minutes it might be possible that your customers have to wait for weeks to get this fix. There is now a way to contact Apple if you have an important bug-fix but I don’t know how well it works. The only solution for this is to test as best as possible and then test again.

When a crash occurs and the user decides to send the crash report to Apple you can access these reports in your iTunesConnect account. But it is up to Apple when they provide these reports and they only provide the reports for the latest version. That’s why we decided to integrate plcrashreporter into our next application. After a crash the application recognizes it on the next start and provides the user the possibility to send the crash report to our server. Now we have instant access to crash reports and can start fixing the bug. We even have the possibility to provide feedback to the user, for example if the bug is already fixed. For the admin tool and the plcrashreporter integration we used the CrashReporterDemo which provides all the functionality we need.

User feedback is very important for the success of an application. Bad iTunes customer reviews can destroy the sales of an application. The reality is that you will get more bad than good reviews. This is mainly because when the user deletes an application on his iPhone he is invited to rate the application. Most of the times these ratings are one star ratings because the user don’t like your product and removes it. People who are satisfied with your App probably won’t do a review because most of the time people do write reviews only when they want to complain. To achieve more reviews it’s maybe a good idea to ask the user to write a review for the application after a certain time. Let’s say after 4 weeks of application usage the user gets an dialog saying something like “Thanks for using our application! If you like it please rate it in iTunes”. By doing this it would be only one click for the user to get into iTunes where he can rate or review your application.

All those steps can help you to hopefully improve your application success and to build a better product for your customers.

Sync your iPhoto library with rsync

Written on August 16, 2009

Today I wanted to sync my iPhoto (‘08) library to my NAS because I wanted a backup of my photos which I can make accessible on the internet through my NAS. This just looked like a simple task for rsync and I started to look where iPhoto stores my photos.

The first thing I realized was that the Library folder contained a folder named Originals and another one named Modified. The folder Originals contains all photos you have imported into iPhoto. The folder Modified contains only the photos which you have modified through iPhoto.

This means that I would have to merge the modified photos with the originals to have the correct version of every photo in the destination folder. After thinking about the problem and reading the rsync man page I came up with the following shell script:

SRC="/Users/andreas/Pictures/iPhoto Library"
DST="codestore:/volume1/photo"
TMP=~/tmp
EXCLUDE="$TMP/iphoto.exclude"

cd "$SRC"

find ./Modified -type f -print | sed 's!./Modified!!' > $EXCLUDE
rsync -azP --exclude-from="$EXCLUDE" --delete "$SRC/Originals/" "$DST"
rsync -azP "$SRC/Modified/" "$DST"

rm "$EXCLUDE"

Download the script here

The script first generates an exclusion list containing all modified files. Then the originals are synced to the destination folder using the exclusion list. After that the missing modified photos get synced to the destination. And that’s it, you have a folder containing only the latest version of your photos.

Depending on the size of your library The first run will take a while. But due to rsync the following syncs will be very fast.

I don’t know if this script will work with another iPhoto version than iPhoto’08. I also must note that I used rsync version 3.0.6 which is not the original version which comes with Leopard. if you try the script with another version please use the –dry-run option! If it works please leave a comment.

Making a static site more dynamic

Written on August 13, 2009

Since our website now has a brand new blog it’s now time for our first ever blog entry! And what subject would be better than blogging about the development of this new feature.

First of all let me describe some technical backgrounds of this site. Though this site was containing some “dynamic” features like a newsfeeds or a sitemap everything on the server was deployed as a bundle of static HTML pages (this has changed a bit now), CSS style sheets and some JavaScript. So all you needed to run this site was a simple HTTP-Server, no need for a server side language like PHP or ruby.

This was done by using nanoc a ruby site compiler which generates the final pages using some templates and some scripts. It’s a very interesting project and it’s a good content management alternative (I also call it a coders CMS :-)). There is a new version coming soon so it might be good start to give nanoc3 a try.

The good thing by this approach is that as soon you have set up your site you only have to deal with simple Markdown text files for the content creation. For testing you can use the build-in autocompiler which is basically a little webserver which compiles your changes as soon as you reload your browser. When your done you fire the rake build script and our site is build for production and uploaded to the live server.

For the new blog feature this approach would be still enough. But for the comments section of the blog we had to put some code on the server side. As nanoc of course can also generate PHP pages this seemed not like a big deal but as the autocompiler can’t handle php we had to change the development environment drastically.

First of all we had to use another webserver for development. On the Mac the first choice was MAMP which contains a complete Apache, PHP, MySQL setup targeted for development. If you are on another platform you might have a look at XAMPP.

As our site uses a directory for every page (links look like e.g. /blog/) we first had to change the DirectoryIndex to enable apache to load our new PHP index pages. This is done in the conf/apache/httpd.conf file in the MAMP application directory.

        DirectoryIndex index.html index.php index.shtml

The next step was to tell nanoc that index.php is actually an index. This can be done in the site config (_config.yaml_) by changing the index_filenames entry to:

index_filenames: [index.html, index.php]

After this we where able to generate and test PHP pages and started to integrate TalkBack as the comment engine into our site. As we now had to compile the site after each change by hand we wrote some scripts to automate those tasks at least a little bit. First of all we used some AppleScript to automatically refresh the browser:

on run

        tell application "Safari"
                activate
        end tell
        
        tell application "System Events"
                tell process "Safari"
                        keystroke "r" using {command down}
                end tell
        end tell
        
end run

And then we extended our build script with a new task which first compiles the complete site and then refreshes Safari and shows us the changed page:

desc "Compile site and refresh safari"
task :refresh => [ :compile] do
  system 'osascript tasks/refresh.applescript'
end

Of course this is not as elegant as the old autocompile solution but we have to use the new technique only for the blog pages at the moment. All other pages can still be tested the old way.

The good thing is we still have the cool features of a static website like fast page loading, search-engine friendly links (plus many others) and on the other hand we now can include dynamic pages wherever we need them.