Even the fact that i dont have a lot of time lately, i’ve been working on it and I plan to release a prototype version to interested alpha testers soon.

What has been done:

• Completely “in house” CoreFoundation based download engine.
• Queues, downloads and segments are GCD (Grand Central Dispatch) driven now.
• No more libCurl.
• Custom “.thingy” container format for storage and sharing of file downloads (and some other things).

Keep an eye to this blog if you are interested to try this application or email me directly at diego (at sign here) massanti.com.

Cheers!

You can get the binary build (3 way universal binary with PowerPC, i386 and x86_64 architectures) here:

enhAacPlusEnc for Mac OS X Leopard, Binary build with 3 architectures.

Xcode project (3.2 or newer) can be downloaded here:

enhAacPlusEnc Xcode project (3.2 or newer)

For more info visit the original post here.

What is done so far.

• A certainly modern multi-threaded Cocoa Framework implementation around libCurl‘s C API, which allows me to get my hands on the whole power of Curl, but without leaving the beauty of Objective-C and the Cocoa API’s at any moment.
• A pretty basic prorotype kind of UI which allows simple segmented download of files for the time being.
  

  Download Thingy, the prototype UI

• A custom (and open, XML, standards based) file format baptized (you guessed) “.thingy” which takes care of storing partial download segments, some basic (for now) binary and redundancy checking, and of course, the ability to reconstruct itself into the original file.
  

  A standard .thingy container.

• Main Launch Services integartion is partially done too.
• Some basic implementation of automatic mirror discovering.

What needs to be done.

• I have to write the foundation for a proper queue management system.
• Network Usage / Bandwidth Limiting logics are in the “to do” list too.
• A proper User Interface.
• A public alpha version with basic usability that people can start to use and report so i can accelerate the development based on actual user’s requests.
• A Safari / WebKit plugin.

So far, this is looking pretty nice and i think it will become a pretty interesting utility for the Mac community.

After some searches, i finished at this interesting post by Chris Hanson, but this was not exactly what i wanted to do, again, i wanted a simple approach to increase the build number with every build.

So this is what i did.

First I created a new configuration settings file in xCode, as shown below.

Creating a new Configuration Settings File in xCode

After this, i ended up with an empty configuration file, so i added the following inside it:

CURRENT_PROJECT_VERSION = 1

xCode uses this variable to store your application’s build number, so we are going to tell it to use this file in order to get the value for the CURRENT_PROJECT_VERSION variable.

Go to your target’s properties, be sure to select All configurations and All Settings, then base your target’s config in your newly created version.xcconfig file, and set the version variable to our new version variable as shown below:

Configuring the Target to use the new variable in the version.xcconfig file.

After all this is done, all you have to do is create a new “Run Script” build phase, and place the following inside it:

NEW_VERSION=`cat "$SRCROOT/version.xcconfig" | awk '/CURRENT_PROJECT_VERSION/ { print $3 + 1 }'`
sed -i '' "s/CURRENT_PROJECT_VERSION = .*/CURRENT_PROJECT_VERSION = $NEW_VERSION/" "$SRCROOT/version.xcconfig"
CURRENT_PROJECT_VERSION=$NEW_VERSION
touch "$SRCROOT/version.xcconfig"

Obviously, if you changed the file or variable names, you will have to adapt the script as needed.
Now, every time you build the app, the build number is automatically increased by one, and included in your application’s plist file as shown below:

Build number being shown in the built app.

A whole thanks goes to the guys at #macdev on freenode Diabolik and KonaBlend who helped with the bash scripting!