Hi, my name is Jonny and I'm the most recent person to join the team at the lab. My background is in games software, but I decided to delve into enterprise software development as I felt the area could learn a thing or two from the world of games from an aesthetic and performance standpoint. When writing games software it is not just important to focus on functional requirements but also the overall experience.
Imagine hitting the fire button on a shooting game, and suddenly a message appears with a big exclamation mark saying, "Error 127888876AB2 - Please contact your system admin", this certainly wouldn't be acceptable to a gamer paying £40+ for a game, so why should it be acceptable in enterprise software where the cost is often much higher?
Many would say that the bugs in the latest release of any enterprise product can just be patched with version 2.0.3.7.1.2.735 and everything will be fine, but you never had to buy a game for your PS2, and subsequently had to patch it with a mass torrent of updates and bug-fixes. This is because the developers knew that if they didn't get it right the first time, then they were screwed, and in a sense the constraint of being unable to patch the software forced the developers to ensure the code was stable, and quality design practices were followed wherever possible.
Getting this level of quality design and bug-free code written for enterprise software isn't as difficult or time consuming as some may imagine if you have developers with the right mind-set. The important thing to realise is that, just because we can release a mass of bug fix patches doesn't mean that this should be used as an excuse to release poor quality software.
Since starting here a few months ago I've been focussing my efforts on mobile software development as the mobile space is fast becoming a very exciting place to be, as it matures into a place for serious developers and equally serious software. My first port of call was iPhone development as it is a nice, clean and aesthetically pleasing platform to develop for, that is currently in vogue within the mobile marketplace. So what better way to improve the user experience our products provide, and bring their powerful functionality to the place a large number of customers will find it most useful.
For our soon to be released product solomon, I have been working hard to produce an iPhone app that makes use of all the features the main CRM provides, but with simplistic design and a good user experience in mind. This will make the app very easy for iPhone users to get to grips with, and will provide a simple yet powerful way to keep in touch with and manage your business contacts whenever-wherever. Here is a sneaky peak into the app, and some of the features it will provide.
Over the coming months I will be developing fixx and solomon apps for iPhone, Blackberry and Android. Developing for this range will provide the majority of our customers with the ability to take full advantage of our products at the times when they are unable to get to a computer. Keep checking back for updates on how development is going, and previews of what is happening with our mobile products.
Tracking down the source of bugs while writing code for any type of computer system can sometimes be one of the most interesting and challenging parts of developing software. It's almost like getting a really awesome puzzle book, but rather than having the answers listed somewhere towards the back, their spread across forum posts or SDK documentation, and in some of the more challenging cases just require you to wade off into the unknown, narrowing down the problem until you finally discover the one line that causing the entire thing to come crashing down.
After spending weeks or even months seeing bugs crop up and cause problems that seem to bare no resemblance to one another, you begin so see patterns forming, and rather than just seeing strange console messages and stack traces, you see the same errors cropping up again and again.
Over the next few weeks, I'm going to talk about some of the more frequently occurring bugs that I find in my code, useful tips I've discovered, and hopefully give any developers new to the iPhone scene, a slight head start.
Throughout the time I've been working with the iPhone SDK I've encountered many problems, some of which are one offs that you'd probably only ever need a fixx for once every blue moon, where as others occur more frequently (almost daily). The most major source of problems tends to stem from the way in which objective-c implements memory management. For those of you unfamiliar with how this works here is a quick rundown...
The most basic way to allocate memory for, and release objects is to use the alloc and release methods that will be inherited from the NSObject base class. Basically when we wish to allocate memory for an object we...
//Allocate memory for, and initialize the object MyClass *aClass = [[MyClass alloc] init];
// When we are finished with the object we release it. [aClass release];
the release method simply reduces the object reference count by 1. If this reference count reaches 0 then the objects dealloc method will be called, purging the object from memory.
Provided we always have matching pairs of alloc and release no memory should be leaked.
The second way of handling memory is to use Autorelease objects. Autorelease objects and convenience constructors are hugely useful when you only need to use a variable temporarily, or need to return an object from a method and need your code to take responsibility for the memory management. The only problem is there are loads of occasions where the pool memory containing my objects is released, and I find myself getting nil pointer exceptions, where my code is trying to message objects that don't exist any more. My remedy for this is to only use convenience constructors in confined blocks of code, where the object isn't likely to go out of scope and be released.
Now enter threading! If you use autorelease or convenience constructors in methods being run on other threads, make sure you initialise an NSAutoreleasePool at the beginning of your code block and release it at the end of your code block. This is because the default pool runs on the main thread only. If you don't do this you'll end up with memory leaking all over the place! Just keep an eye on the console as autorelease objects that have no pool will log messages warning you...
But remember that after releasing the pool you can't return any objects/values that were set to autorelease, although in most cases you won't be able to return objects anyway.
The majority of places I use this are in background syncing methods, or other blocks of code where literally tens, hundreds or even thousands of autorelease objects are created, and obviously if not dealt with properly, just float around taking up valuable resources.
Well thanks for reading guys, I hope this micro-rant has been of help. My next post will be all about singleton objects in Objective-c, and the best way to implement these.
