Archive for the ‘Software Development’ Category

Download Thingy, still working on it but getting closer.

Wednesday, October 27th, 2010

Some updates to the status of Download Thingy.

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!

Updated HE-AAC (aacPlus) reference encoder for Mac OS X

Monday, December 7th, 2009

This is an updated build of the 3GPP group AAC Plus (or HE-AAC) reference audio encoder for Mac OS X 10.5 “Leopard” or newer.

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.

Download Thingy, it slowly starts to make sense.

Tuesday, September 22nd, 2009

I have been working for the past days in the foundation for a new Download Manager that I’m writing for the Mac platform, and this is just an “status quo” about how things are evolving.

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

    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.

    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.

Automatic build numbering increase with xCode

Sunday, September 20th, 2009

I had this problem some days ago where i wanted to automatically increase the build number of my Application in xCode, every time that i actually made a new build. xCode comes with a tool called agvtool which is supposed to fill this gap, but the main problem with this is that it needs the project to be actually closed, for some reason that i certainly ignore.

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

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.

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.

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!