We just launched the Retail Evolved Developer Blog – it will have information specifically targeted towards developers. It’s located at http://blog.retailevolved.com/developers-blog.html.

Creating your first iPhone app can be a challenging experience. For me, it made developing fun again, but only after coming to terms with some concepts that were strange to the Microsoft-wired, C# spewing machine that I call my brain.

1) Memory Management 101

You’ll see that a few of these points deal with memory management. It’s a potentially confusing concept to those of us who have never had to deal with it before. This single concept added probably 20 hours of mind-numbingly tedious debugging to my first app.

Most developers don’t have to worry about managing memory. C#, Java, PHP, Rails, and many more all manage memory for you. What does this even mean? It means that magical memory gnomes automatically “garbage collect” objects that aren’t needed any more. The iPhone SDK doesn’t offer this luxury – you get to play the role of garbage collector.

Let me tell you what will happen if you ignore this concept. Your app will be chugging along nicely until you start watching that embedded YouTube video of your grandma juggling chainsaws when suddenly…crash!

“No biggy”, you say, “I’ll just re-create it and pay close attention to the debugger. It will tell me what I need to do!” So, you start up your debugger, access the video, but nothing happens – it works as expected. “Must be a fluke”, you think to yourself. You continue testing, when …. crash! Out of the blue, the app crashes while testing your tilt-to-scroll functionality. Again, you attempt to re-create, but it’s a no go. Your debugger reads “EXC_BAD_ACCESS” – wow, thanks for the help.

This is a classic case of memory management gone bad. The unfortunate thing with that scenario is that it often won’t start happening until you start testing on devices (the iPhone Simulator is pretty tolerant of unreleased memory – lots more RAM to eat). And when it starts happening, it feels like the gnomes that you used to have working for you are now working against you. Plus, the debugger’s not much help – at least, it won’t tell you where the leaks are happening. You should know, however, that EXC_BAD_ACCESS indicates that you tried to access some memory that has already been released. This either happens because a) You released it and then attempted to access it again, or b) In an attempt to reclaim its quickly depleting memory, the iPhone OS started releasing your views (that’s the default behavior of a memory warning received by a controller).

I could write pages and pages regarding the finer points of memory management, but Apple already has here. You should (must, really) read the entirety of that document. It may sound a bit technical at first, but keep it handy. It will save you hours.

I’ll run down some of the basics as a bit of a primer:

• Every object has a property called “retainCount” – this is the number of references that have been made in code to the address of your object. This is accessed via [myObject retainCount].
• As long as this number is greater than 0, that memory stays reserved.
• A retain count is increased when a “retain” message is sent or when an object is initially allocated.
• The retain count is decreased by sending a “release” message to your object – [myObject release].
• When the retain count hits 0, the “dealloc” method of the object gets called and the memory is released (assuming that the “dealloc” method does its job right).
• A “leak” occurs when an object goes out of scope without being released. You now have no way of releasing that memory…. These are bad and are likely the cause of most major power outages (not really).

Here are some basic rules:

• Every alloc needs a corresponding release. Make this second nature. Personally, I like to write in the release message at the same time as the alloc message so that I don’t forget. It’s kind of like opening and closing parentheses…
• In your own class definitions, your dealloc method should release all of the objects it has references to. This includes properties and local variables.
• When you add an object to an array or dictionary, release it before the original reference goes out of scope. Adding an object to an array or dictionary increases the retain count by 1. This makes sense – the array is taking ownership of the object and retains it so that it doesn’t lose the reference. Later on, when the array is released, all of its objects will be released with it.

So, be a responsible memory manager. It’s not that hard once you get the hang of it. At first, you just need to keep a close eye on your retain counts and use Instruments to help you identify leaks (more on that in a later post).

2) NSAutoReleasePool – Just When Memory Management Was Starting to Make Sense

The points we talked about in Memory Management 101 doesn’t apply 100% of the time. It only applies to objects that are explicitly retained or allocated. So, what happens to everything else? For example:

[NSString stringWithString:@"Hello World"]

There’s no alloc or retain message anywhere in sight, so we don’t have to release it. Yes! You’re off the hook right? Wrong (well, sort of).

See, when an object is created using a class method (as in the above example), it is assumed that the method adds the created object to the most recently created NSAutoReleasePool (on the current thread). “Wait a minute,” you may be thinking, “I didn’t create one of those”. You don’t have to. The application, by default, creates one NSAutoReleasePool on the main thread. When the application exits, it sends a release message to the NSAutoReleasePool, which in turn sends a release message to all of the objects in the pool. Pretty nifty, right?

Most of the time, it’s okay to let small objects such as strings get handled this way. Personally, I still prefer to explicitly allocate and release my strings, just to keep myself in the habit. When should you use NSAutoReleasePool explicitly?

1. Any time you are performing an action on thread other than the main thread. Threads that get spun off (say, a selector that gets triggered by NSTimer), do not have access to the NSAutoReleasePool on the main thread. Objects that are sent the autorelease message are essentially leaked – there’s no pool to add them to. That is, unless you explicitly create one. Which you should. Just make sure you release it before the method is finished.
2. Because you prefer to release your objects this way – it’s your style. There’s no problem with creating an NSAutoReleasePool at the beginning of a method and then releasing it before the method ends. In between you can have all manner of autoreleased objects, either because you told them to autorelease or because you used a convenient class method. Just make sure you don’t explicitly release an autoreleased object – you’ll pay later when you attempt to release NSAutoReleasePool.

3) [UIImage imageNamed:@"memoryHog.png"]

Chances are that you’ll need to work with images at some point in the course of your iPhone development. If so, you’ll likely look for the easiest way to grab an image from your application resources. [UIImage imageNamed:] is that method. It’s short, sweet, and you don’t have to figure out the path to your image. Programming bliss…. until you use this method to access a dozen high-res, full-screen images and your app starts crashing (I speak from painful experience).

This method is extremely convenient. And you should use it – sometimes. What isn’t immediately clear about this method is that it loads the image and then caches it in memory in case you need it again. The catch? You don’t have access to the cache where it’s stored – meaning you can’t purge it from memory. It stays there until the application is released.

What should you do instead? It depends, but this is usually a safe bet and gives you finer-tuned control over the release of the image:

UIImage *myImage = [[UIImage alloc] initWithContentsOfFile: @"path/to/my/file"];

The above isn’t a perfect example as you would want to get the path to your resource directory first, but I’ll leave that for you to discover for now. You could alter that method by tacking on an autorelease if you want to use an NSAutoReleasePool.

4) Alt+Double-Click = Enlightenment

Most of the time, SDK documentation is a twisted maze of technical writing. Apple has done a great job of making their documentation easy to access and surprisingly readable. To quickly access the documentation, simply use Alt+Double-Click on a method or class type from XCode.

The documentation will save you many hours of research. Refer to it. Often. If I were smart I would have used it to look up the implications of [UIImage imageNamed] before I learned the hard way.

5) NSLog, a Trusted Friend

In debugging, you will undoubtedly need to output something to the debugger at some point. You can use NSLog to do this. It’s particularly helpful for tracking retain counts and the like. Here’s a simple example:

NSLog(@"%d", [myObject retainCount]);

The first argument is a string format (which you should learn to love), and the following arguments are used to populate the formatted string.

Next Time…

That wraps up part one. Next time, we’ll take a look at instruments and some AppStore tips that will make your distribution easier.

Note: This is an update to a post that was originally called “Break Even Turns”. After comments from industry experts, I have updated the post to reflect the relationship between inventory turns and GMROII (Gross Margin Return on Inventory Investment). For most locations, a GMROII of between $2.50 and $3.20 is required to truly break even.

Managing cash flow is one of the greatest challenges of retailing. To compete, retailers need to focus on stocking shelves with the right amount of the right product. Too much product and inventory becomes bloated, tying up much needed cash. Too little product and valuable sales are lost.

Lots of retailers focus on turns, the number of times their inventory is bought and sold. Mathematically, a turn is the average inventory of a product divided sales. For example, if you keep 10 widgets on a shelf at all times and you sell 100 widgets, you have just turned that product 10 times. A product that turns frequently is sometimes referred to as a “fast-moving” product – it leaves the shelf faster than most.

Turns play an important role in product selection and product pricing. A higher markup on a product means you will need fewer turns to break even on your investment. Conversely, a lower markup means more turns are required to break even.

To break even, most locations require a GMROII of between $2.50 and $3.20. This depends on factors like rent, wages, utilities, etc. – expenses that are not typically included in cost of a product when analyzing margins.

I recently decided to spend some time researching the relationship between GMROII and turns for the purpose of optimizing the purchasing of a local retailer. I wanted to answer the question: “Given a certain mark up, how many turns will it take to for a product to reach a target GMROII”?

Surprisingly, it’s fairly simple. Mathematically, the target GMROII divided by the Cost Markup Percentage (Markup / Cost) equals the number of turns required. Consider a widget that you purchase for $1.00 and sell for $1.50. The cost markup percentage is 50% ($.50 / $1.00). With a target GMROII of $2.50, we can determine that the widget needs to turn 5 times to reach that goal.

Why is this even important? Because now you (or your buyers) can determine how many widgets to stock on your shelf to get your desired return on investment, especially if you have some sales history to base your decision on.

For example, assume you are selling a widget with a Cost Markup Percentage of 75% (purchased for $1, sold for $1.75). Based on the GMROII Turns formula, you know that you have to turn 3.33 times to post a $2.50 GMROII. Last year, you sold 20 of these widgets. If you expect demand to stay the same (if only it were that simple), then you know that your average inventory needs to be under 6 (20 units sold divided by 3.33 needed turns) to reach your GMROII goal.

The above example is overly simplified, but the message still holds. The GMROII Turns formula should be applied at an annual level to accommodate for seasonality. If a widget triples in sells during fourth quarter, then you should adjust what you stock to meet that demand.

Appolicious, an iPhone app community and review site, gave Pocket Retailer 5 out of 5 bars.

“…this is an absolute must-have for anyone involved in the finances of a retail store”

See the full review here.

Last night, Pocket Retailer moved into position as the #1 Paid Business App in the app store. We are extremely excited about the app’s momentum and are always looking for ways to improve it.

If you haven’t downloaded it yet, you can pick it up here for $0.99: http://bit.ly/7v6Z5A.

Please contact us with any suggestions or comments.

Pocket Retailer got an unexpected boost today when it appeared on Apple’s “New and Noteworthy” list of apps.

It is also quickly climbing the “charts”, currently sitting at #14 in the Business section.

It’s official. Pocket Retailer has finally hit the App Store and is now available for your iPhone or iPod Touch. Download it here for $0.99 (opens in iTunes).

What is it? A collection of 14 micro-apps designed to help you increase your bottom line. Micro-apps include calculators for: Turns, Break-Even Turns, GMROI, Sale Pricing, and much more.

I know this has nothing to do with retailing, but it’s a good cause. Drew Carey has agreed to give $1 to LIVESTRONG for every follower (up to 1 million) that he has on Twitter by the end of the year. Today, I launched DrewVsCancer.com so that you can watch his followers add up in real time. Why? It’s easier than constantly hitting refresh. Plus, people are going to get a whole lot more interested as his follower count gets close to the 1,000,000 mark.

I am currently developing an iPhone application that will consist of common retail calculators such as sale price, break-even turns, open-to-buy, and others. Which formulas do you use from day-to-day?

A website and blog can be one of the most direct and effective ways to connect with your customers. To maximize your return on this investment, you need to be able to collect and analyze data about where your website views are coming from, how your users interact with your website, and how many times each page (or blog entry) in your site is being viewed.

Google offers a free service called Google Analytics to make website analytics simple for websites large and small. Configuring Google Analytics for your website does not take much time and has a huge payoff. Here is how to get started (pass this on to whoever manages your website):

• Go to http://www.google.com/analytics
• Go through the sign up process – if you don’t have a Google account, you will need to set on up; note that Google allows anybody to sign up, regardless of your e-mail address
• During the sign up, you will need to provide some basic information regarding your website; if you have multiple websites, you can add more later
• At the end of the sign-up process, you will be given instructions on how to add the tracking code to your page; simply copy and paste the code right before the “</body>” tag of each page on your website

If you operate a blog, the instructions above may be slightly different. WordPress has plug-ins that can be installed to enable Google Analytics. For BlogSpot, you will need to edit the layout HTML.

Google Analytics includes additional tools for eCommerce sites that are also incredibly useful.

No matter the size and scope of your web presence, you should be taking advantage of Google Analytics. If you have a blog, I strongly recommend implementing Google Analytics there as well.

If you would like additional information or help in implementing Google Analytics, please Contact Us.