bookmark_borderPlaying Animated GIFs on the iPhone

Following on from my Animated images on the iPhone post, I thought i’d take things a step further.

To re-cap, I pretty much summarised the available options for playing back simple animations on the iphone in this nice table:

Method Problem
Use UIImageView It doesn’t scale
Re-draw a UIView every frame Far too slow
Use GLES Beyond the scope of the last article, but not this one!
Transform a clipped UIView each frame We did that last time

To take things further, OpenGLES needs to be used. Specifically, you need to upload and draw a texture for every frame of your animation.

Now while this sounds like a great idea, there is a slight problem: uploading textures on the iPhone is hideously slow. Excluding the requirements of a video decoder, you only have enough time per frame to be able to playback a small stop motion video in RGB format.

All is not lost though. The iPhone supports two rather interesting texture formats: GL_COMPRESSED_RGB_PVRTC_* which is the native format, and GL_PALETTE* which is, as the name implies is a texture with a palette.

The fastest format to upload is PVR, but unfortunately there aren’t many native video codecs or animation formats about that decode to PVR format. Which leaves us with the palette format, which is just about fast enough to playback something more substantial…

Now which animation format uses a palette and is widely supported? Animated gif!

So to cut a long story short, I ended up writing a fairly elaborate library to decode and playback animated gifs on the iPhone, all in realtime.

Provided the gif is not gigantic (since the bigger the gif, the slower the decode + upload), it’s actually quite useable.

anim8gif

In fact, as a proof of concept I ended up writing an app using this library to playback animated gifs from any website in fullscreen (similar to the youtube app). Feel free to check it out – anim8gif.

The code

The code for this gif animation library, glgif, is located on github. As always, feel free to fork!

bookmark_borderDouble Entry Accounting with Invoicing in Rails

You may remember a little post I made ages ago about Double Entry Accounting in Rails, in which I went over what one needed in order to make a simple double entry accounting system within the confines of the Ruby on Rails web development framework.

After a few requests by readers, I have decided to write the sequel. Double Entry Accounting with Invoicing in Rails.

To recap…

Last time I identified the following core tables you needed in your database:

  • Account (has many Postings)
  • Asset Type (e.g. £, $, monkeys)
  • Batch (has many Journals, links them into a group of transactions – though not really needed)
  • Journal (has many Postings, links them into a transaction)
  • Posting (associates with Account, Journal, and Asset Type)

Though I failed to elaborate on what you really needed to store in these tables. In truth, it can be as complicated or as simple as you’d like. No need for Batches? Then don’t include them.

As long as you at least store amounts in Posting’s, and practice the art of double entry accounting, you should be fine.

The next major point of note was how does one calculate the balances in the accounts? Well it turned out the solution was rather simple:

credit_amount = postings.sum(:value, :conditions => "amount < 0")
debit_amount = postings.sum(:value, :conditions => "amount > 0")

Coupled in with the balances were the amounts in the Postings, which had to be flipped depending on the type of account they resided in:

def real_amount
  return [:asset, :expense].include?(self.account.account_type) ? self.value : -self.value
end

def real_amount=(val)
  self.value = [:asset, :expense].include?(self.account.account_type) ? val : -val
end

In simpler terms: if an account is an asset or expense account, a positive value = a positive amount. Otherwise, a positive value = a negative amount. Vice versa.

So how do we factor invoicing into this?

There are two ways in which invoicing can be linked into a double entry accounting system:

  1. Link the payment of each invoice to transactions in the system
  2. Link the amount owed by each client for each invoice to transactions in the system

Realistically though, #1 is a fairly stupid idea as in the real world, clients don’t always pay on time. Or with the correct amount or order. Not only that, they can also pay off multiple invoices at once!

Which brings us to #2 – linking the amount owed by each client for each invoice into the system.

How do we do this? Well to summarise:

  • Have a revenue account which tracks how much you make.
  • Have a checking account which tracks what is in the bank.
  • Make an asset account for each client.
  • When you make out an invoice, record a transaction which transfers the total amount of the invoice from your revenue account into the client account.
  • Link any transaction(s) generated by the invoice to the invoice (so you can revert them later if required)
  • When the client pays, record a transaction which transfers the paid amount from the client account into your checking account.

Which might look like this in the system:

Account Debit Credit
Checking Accounts
Bank 100 0
Invoice Accounts
Microsoft 50 0
Apple 50 0
Revenue Accounts
Revenue 0 200

So…

  • For tax purposes, your revenue account will at least sum up to the total amount in all of your invoices.
  • If the client’s account has a positive balance, they owe you money for any one of your invoices.
  • If the client’s account has a negative balance, they’ve obviously overpaid you. So go party!!

… which more or less concludes this article. Happy accounting!