Our products

We are passionate about building niche multi-platform products that provide real utility to our customers.

Anfield
Keep up to date with Liverpool FC news from across the web.
Domain Bites
Domain name industry news and resources.
Pub Reviews
Find the best pubs near you. Share your thoughts and photos.
Mmmm
Capture your taste and share it with the world.

Blog

We like to blog about software. Our stack, engineering problems, open source developments.. you will find it all discussed here.

Image caching on iOS with AlamofireImage

We recently released the updated and improved iOS application for Mmmm.com - a user curated visual menu for finding awesome food (and drink) in the city of Leeds, West Yorkshire.

Whilst testing the application it became apparent that the implemented image caching mechanisms were not appropriate for an inherently image heavy application.

I delved back into the source code and noted that for some reason I had attempted to reinvent the wheel - I had implemented my own caching methodology within my UICollectionView adapters (which implement the UICollectionViewDataSource protocol).

The logic was fine. I had opted to cache images in memory using NSCache. The idea was that rather than re-download an image from the server when a user scrolls back to a particular cell we would load the image directly from the cache.

I had also implemented a filesystem cache which would save the last ten displayed photos to the filesystem and would save details of their locations to a SQLite database (interfacing with the SQLite database through the fantastic FMDB library). The intention of this caching layer was that upon reopening the app we could display the last ten photos almost instantaneously prior to sending off a query to the server to request more up to date photos. It was implemented to provide an optimal user experience such that a user sees beautiful pictures of food upon reopening the app as opposed to a boring loading screen.

The problem

There was in fact no problem. The caching worked as expected and it saved on unnecessary server requests. The problem was what my caching mechanism didn't do.

If a user quickly scrolled through the collection of photos cached images would be shown (where appropriate) or requests would be sent off to the server to load each image for each cell. Even the cells that had been scrolled past extremely quickly and were no longer on screen. Not only does this result in unnecessary data usage but it also means that the requests to load the images for the cells that are on screen are at the end of a queue of unnecessary requests.

Fortunately I had noticed this and had implemented the concept of a request queue within my delegate. It essentially tracked ongoing requests and cancelled unnecessary ones.

This in principle should have worked but because of the complexities associated with asynchronous requests in collection views - race conditions, reused cells etc it was resulting in some visual issues such as flickering images and incorrect images on certain cells.

There is an interesting and informative question on StackOverflow which touches on some of these problems. It is well worth a read.

It was this that spurred me to look back at the code and come up with a plan for refactoring it.

AlamofireImage

Developing a plan of attack wasn't difficult. As soon as I looked at the code I was completely bemused as to why I had not used the AlamofireImage extension (of which I was aware). I believe the reason that I hadn't was because at the time the code had been originally written AlamofireImage did not exist. As such I had not reinvented the wheel.. I had created it. Unfortunately (Fortunately?) someone had since created a much better wheel.

My logic had been flawless, and what I had implemented was good. It was simply the case that here in July 2016 we have Alamofire which implements what I had done and much more.

Alamofire is actively developed, and has an active community of top quality developers maintaining it. It is a perfect example of the awesomeness of open source. Alamofire is what I utilise for the network interaction across the Mmmm application and as such it seemed like a logical extension to utilise the AlamofireImage extension for my image needs.

AlamofireImage is well documented and extremely simple to use. It provides various methods for downloading, caching, and manipulating images (transitions, rounded corners etc). In addition to this it specifically provides UIImageView extension methods which utilise these methods to provide simple 'helper' functionality for displaying these images.

The best bit about these UIImageView methods is that they handle a lot of the complexity behind the scenes. One could very easily naively implement them and encounter no issues. For example if I attempt to load an image from a URL into a UIImageView within a UICollectionViewCell utilising the af_setImageWithURL method it will automatically handle the cancellation of unnecessary requests when the containing cell is reused.

N.B. A well written app will take advantage of the abundance of information returned by Alamofire to act on situations like this appropriately. Alamofire will return an appropriate error code when a request is cancelled such that you can adjust the UI or execute any other behind the scenes actions as needed.

For further details on some of the benefits offered by the UIImageView extension methods, see here. It also outlines some of the things that the extension does not cover that you should be aware of.

Takeaways

There a few takeaways from this:

  • Take the time to look back through old code - there may be something from 'back in the day' that is no longer suitable or optimal given the fast paced nature of software development.

  • Open source is great. Alamofire has nearly 18,000 stars on GitHub. It is clear that a lot of people use it. Don't reinvent the wheel. If you want to spend time coding networking and caching mechanisms simply contribute to Alamofire :)

  • Be careful and considerate of your user base. I avoided any issue by catching it in advance. It is patently apparent that users like a good experience within your app, and they (generally) like money. If you are needlessly sending out network requests to load images you would be surprised at how quickly data usage can add up. Users are not going to be very happy if you drain their data caps.

UK Accounting - The P11D

Having written a number of well received blog posts on the intricacies of corporate accounting I figured that I would try and write some more. Hopefully this will help you with your filing requirements, and will also serve as a reference should I ever need to refresh my memory on a particular topic.

This one pertains to the P11D form which you must complete if "you’re an employer and need to report end-of-year expenses and benefits for employees who earned £8,500 or more". The P11D also has an accompanying form - the P11D(b) which is used "to report Class 1A National Insurance contributions due on expenses and benefits, and to declare you have sent forms P11D to HM Revenue and Customs (HMRC)."

What to report.

I find that the best way to answer this question is to simply think logically. If your employer gave you a boat, that is clearly a good thing. It is a benefit. If your employer paid you for the extra costs associated with working from home (lighting etc) then that is not a benefit - you have not gained anything, you have simply covered costs that would not have otherwise existed.

Note I initially got this wrong. As outlined here, limited companies "are more restricted in what can be claimed for use of home" (relative to self employed individuals). A limited company can not use HMRCs 'Simplified expenses' system, and as of the time of writing can only claim £18 per month for 'use of home' (without qualification). This is detailed in this manual.

If you visit this page you can view the paper version of the P11D form. It is short and gives a general overview of the items that must be declared on the form.
These include situations whereby an employer:

  • provides an employee with a company car
  • pays for travelling expenses
  • provides health insurance

A full list of expenses and benefits can be found here. It details exactly what you need to report under specific alphabetically organised categorisations.

A more detailed and complete overview can be found in booklet 480(2016).

Pertinent examples

Some benefits are exempt from being reported (under certain circumstances). The ones that have been particularly relevant to me are:

  • Mobile phones - an employer can provide one mobile phone to each employee to use for private and business calls without needing to report it on the P11D

  • Computers - my computer is exempt from reporting because "the computer is provided for work purposes and the employee doesn’t make ‘significant’ private use of it"

  • Medical expenses - whilst I wasn't initially aware of this, health and safety legislation when working with computers/monitors means that my eye tests and contact lenses would be exempt from reporting.

Deadlines.

The deadline for an employer to file P11D forms for their employees is the 6th July following the end of the tax year. For the 2015-16 tax year the forms must be submitted by the 6th July 2016.

You must pay any Class 1A National Insurance owed on expenses or benefits by the 22nd July.

Reimbursement of expenses

In my case (as a sole director of a limited company) the only expenses that I had personally incurred in relation to the company were for small incidental purchases when for whatever reason I was unable to directly purchase the product with company funds.

In these cases I accounted for the purchases as loans to the company. That is to say I credited my directors loan account for the costs of the purchases.

In relation to the P11D one does not need to report such expenses. Booklet 480 (mentioned above) states (under section 5.19) that:

"Businesses are often run in such a way that employees make payments on their employer’s behalf. For example, an employee may buy stamps,stationery and items of equipment for the employer and be reimbursed the costs incurred from petty cash or by cheque. Such transactions are not providing the employee with either earnings or expenses because the employee has received no money of his own. Accordingly such reimbursements do not feature on the P11D."

This is discussed and alluded to in this post on the Taxation.co.uk forums.

Going back to my initial explanation, there is clearly no benefit being provided when one receives a reimbursement for a £4 USB cable.

Summary

In the case of Double Negative Solutions no P11D needs to be submitted. This is because as a sole director I do not receive any benefits from the company (apart from my salary, and those that are covered by exemptions).

For larger companies the provision of cars, the annual office party, and the payment of travel expenses may be considerations.

The intricacies of the Google Places Web API

The Mmmm.com web and mobile applications provide location functionality based on a complex integration with the Google Places API.

Fortunately their web API is well documented, and given the scale of the data on offer is well covered with integration wrappers for the various appropriate programming languages.

Mmmm.com utilises this PHP wrapper. By taking a look at the source code you can see how simple the API really is.

One API to rule them all

As alluded to above, both the web application and the mobile applications utilise the Google Places API. To reduce complexity however, they all integrate with Googles web API by proxy of the Mmmm.com API. That is to say that the mobile applications call our in-house API which handles calling and returning Google Places data rather than integrating directly with the respective native APIs.

If you want to use the native APIs, they can be found here: Android, and iOS.

Which endpoint?

Google offer a 'nearby search' and a 'text search' API endpoint. They also offer 'autocomplete'.

Nearby search

In principle the 'nearby search' would be ideal, but there is the use case where a user wants to upload a photo taken previously in a location that they are now not near. Previously we had integrated a segmented search control such that users could specify if they wanted to search nearby or anywhere. This was however deemed overly complex and as such we settled on a singular 'search' utilising the 'text search' option.

Text search

Text search allows you to search for string searches like "Pizza in Leeds".
Unfortunately the text search API blows up a little when it comes to partial search terms.

I found from experimenting that searches for 'Mcdon' would return various results for branches of Mcdonalds, but searches for 'Mcdonal' would return completely different branches (even when the same location bias parameters were sent). One search returned a singular result.. for a Nandos..? :S

The issue with this is that one can safely assume that the closest McDonalds branch is of most relevance to the user. If that result is not returned, or it is not given the prominence it deserves, then again the user experience is affected.

Text search does resolve the issue of locations that are no longer nearby. A user can search for 'Macys New York' and return a specific location somewhere complete different.

Autocomplete

In addition to these two 'search' APIs, Google provide an autocomplete API. This allows you to query a partial location name and have suggestions returned as to the location that your user is looking for (like in the Mcdonalds example above). Unfortunately the autocomplete endpoint only returns very basic data - it does not for example return the locations latitude and longitude which in my case meant I could not calculate and display how far the user was from each location.

Additional considerations

Intricacy

Whilst the documentation suggests otherwise, my testing suggests that that 'radius' parameter for a 'nearby search' be specified in meters, whilst for a 'text search' it be specified in kilometres (contrary to the documentation). Well.. when the radius is set at 50 for a search from Leeds, England, I get results from Manchester, England too. Last time I checked Manchester was more than 50 metres from Leeds.

Annoyance

Google have annoyingly deprecated their 'types' functionality. Previously you could specify that you only wanted to return results for locations of specific types - bars, restaurants etc. They have not done this with any (in my opinion) justified or reasonable explanation.

My personal opinion is that people are not taking a lot of photos of food at an accountancy firm, and as such it seems reasonable that I should be able to specify not to return locations of type 'accounting'. Google are forcing a poorer user experience on customers of companies who utilise their APIs.

One work around (if using the nearby endpoint) is to do some post processing of the returned results. Such an API call does return the 'types' in the response array and as such (at the cost of a little additional overhead) one can show only the appropriate types of location.

Companies, Accounting, and Tax - a reference list

This post seeks to provide a list of useful and informative resources that have aided in the development of my own understanding of subject matters pertaining to companies, accounting, and tax.

These links are the basis of the knowledge from which i was able to discern and understand the subject matters outlined within my previous posts:

General resources

Capital

Capital Allowances

Statutory Accounts

Corporation Tax

FreeAgent

Pensions

Misc