Its been about a month now since we released version 1.0 of solomon our small business CRM & contact management software and we've been working harder than ever to get some of the features in that you asked for and we promised.
From 1.1 onwards we are giving you the ability to track your deals. With deals, you and your team can effortlessly track those lucrative deals you've been pitching for. As always we've focused on productivity keeping the user interface tightly focused on your contacts, how you work with them and the information you track against them.
With deals comes better integration with your notes and tasks. Tasks can be created, associated and tracked right there within your deals. Notes too.. ..In fact you can now associate any number of contacts, companies and users with a deal and coordinate your efforts to securing that big contract.
We've also added webCal support Thats right! Now all of your tasks seamlessly integrate with your calendar via the webCal format.
Finally we've had our resident design guru making some awesome design tweaks here and there to generally make the user interface look and feel that little bit slicker and for you techies, we've had our technical boffins, improving on the underlying REST API meaning you have more control over how you get to and work with your solomon data.
We've still got a few more features that we're aching to get in before we make the 1.1 release official but rest assured we'll be working even harder for another week or so to get this update out to you. In the meantime why not tell us what you think about what we're working on or tell us what you'd like to see in up and coming versions of solomon?
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.
We're excited to announce public availability of the Hosted version of our bug tracking product, fixx. This has been the single biggest request we have consistently received over the past year, so we have heard you and acted on it!
Hosted fixx is a great and flexible way to get started with your own instance of fixx without having to set-up your own server and configure it. Despite how painless and easy it is to run your own instance of fixx, we know that many organisations love the ease of having someone else manage their software using a software as a service (SaaS) model. It is also a great way for organisations without IT staff to get started with fixx.
Unlike traditional on-demand/SaaS models, we have gone all out to give you the power of having your own dedicated hosted version of fixx that you have absolute control over. This means, you control when your software is upgraded and which features you want to turn on. We handle all the boring work like configuration, back-ups and upgrades.
fixx Hosted comes with absolutely no restrictions on functionality. You get every feature of the installable version, including unlimited users, projects and issues. Which other hosted bug tracker or project management tool offers that? The only thing that is limited is disk size for attachments but even that is generous with 20GB+ space, which is limitless for most common usage.
This is only the beginning for Hosted services from hedgehog lab. We hear you loud and clear on a hosted solomon and we are working hard on it. For now, we want to start slow and get feedback from our community on how we can improve our hosted offerings. Keep an eye out on our blog as we make constant improvements while delivering advanced functionality in our product roadmap.
