Automatic Reference Counting (ARC) in iOS (Part 2)

iOS SDKIn my last blog post, I wrote about ARC and discussed in detailed the __strong and __weak qualifiers, which should cover 80% or more of the use cases out there. In this article, I am going to complete the series by discussing the other two ARC ownership qualifiers __unsafe_unretained and __autoreleasing.

The __unsafe_unretained Qualifier

Variables qualified with __unsafe_unretained are telling the compiler that they do not want to participate in ARC at all. Hence the programmer is responsible for allocating/releasing memory and for handling object lifetimes.

Qualifiers __unsafe_unretained and __weak are actually similar in function. They both claim no ownership of any object that the variables are assigned to (hence “__unretained”) but merely act as a reference the objects. The key difference is that while a __weak variable is assigned to nil after the referenced object is released, a __unsafe_unretained variable to the same object still points to the memory space that was allocated to the object. Because of this, you can’t safely infer if an object has been of disposed with __unsafe_unretained (hence “__unsafe”).

One scenario where you would use __unsafe_unretained is when you declare a data member in a C-struct or union as an Objective-C object like NSString. See below:

struct MyStruct {
  NSString *text; // Won't compile.
}

You will get an error when you compile the code above. Under ARC, NSObject types can’t be members of a C-struct. This is because the compiler can’t manage the lifetime of a C-struct as it can’t determine the lifetime of a struct member. Therefore the developer must manage  the ownership of the Objective-C object manually (usually through CFRetain and CFRelease). Read here for a full explanation on the use of __unsafe_unretained in C-struct and the compiler error “ARC forbids Objective-C objects in structs or unions.”

struct MyStruct {
  NSString __unsafe_unretained *text; // Now it compiles.
};

The __autoreleasing Qualifier

From Apple document Transitioning to ARC Release Notes: “__autoreleasing is used to denote arguments that are passed by reference (id *) and are autoreleased on return.”

The __autoreleasing qualifier is used to track objects created outside the scope of the caller but still be “retained” so that the object can be accessed by the caller. __autoreleasing is typically used in a method (eg. see method doSomething: below) that returns a BOOL to indicate if the method call is successful or not. If the method fails, we can then access the NSError object for details of the failure. The NSError object is created in the method and returned as an __autoreleasing object to the caller.

@interface MyClass : NSObject
- (BOOL)doSomething:(NSError * __autoreleasing *)myError;
@end

// ...

int main(int argc, const char * argv[]) {
  @autoreleasepool {
    MyClass *obj = [[MyClass alloc] init];

    NSError * __autoreleasing error = nil;
    NSError * __autoreleasing * ptrToError = &error;

    [obj doSomething:ptrToError];

    // This following works as well. I used a more complex approach
    // above to illustrate the intricacies of __autoreleasing.
    [obj doSomething:&error];
  }
}

How should we implement doSomething:? If the following won’t work.

- (BOOL) doSomething:(NSError * __autoreleasing *)myError {
  NSError *error = [[NSError alloc] init];
  myError = &error;

  // ...

  return NO;
}

The problem is that the object variable error is declared implicitly as __strong. And when error varialbe goes out of scope after the control flow leaves doSomething, the error object will be disposed. This won’t work if we want to retain error so that it can be passed back to the caller. To make it work, qualify error with __autoreleasing.

NSError __autoreleasing *error = [[NSError alloc] init];
myError = &error;

Or simply do the following:

- (BOOL) doSomething:(NSError * __autoreleasing *)myError {
  *myError = [[NSError alloc] init];

  // ...

  return NO;
}

By qualifying the parameter myError as __autoreleasing, we ensure that the NSError object created in doSomething is assigned to the autorelease pool and can be safely assigned to an object variable when the control flow is returned back to the caller.

Last but not least, note that all id * is implicitly qualified with __autoreleasing.

Reference and Further Reading

Automatic Reference Counting (ARC) in iOS (Part I)

iOS SDKPrior to iOS 5 SDK, memory management in Objective-C is a manual process where developers are solely responsible for handling memory allocation and release, and object lifecycles. Apple introduced Automatic Reference Counting (or ARC) in iOS 5 to simplify memory management and made memory management the job of the new LLVM compiler.

Objective-C Memory Management Policy

The best way to understand memory management in Objective-C is to think of object ownership (see Memrory Management Policy for more info). Here are the rules to memory management prior to ARC:

  • You own any object you create – Method names that include alloc, new, copy, or mutableCopy creates an object
  • You can take ownership of an object using retain – An object can have more than 1 owner
  • When you no longer need it, you must relinquish ownership of an object you own – As long as an object has 1 owner, it continue to exist. Ownership to the object is relinquished by calling release. When an object is no longer owned, it gets disposed by the system
  • You must not relinquish ownership of an object you do not own – This is a conventional rule. Break this rule and the app may crash

These rules still apply to ARC even though retain, release, and autorelease are no longer supported in the new model. In ARC the rules are fulfilled automatically in the background and is primarily handled by the compiler. The key to understanding ARC is to distinguish the difference between an object and an object (pointer) variable referencing that object. As soon as there are no owners (or variables pointing) to an object, the system disposes that object. Also it is important to note that there’s no garbage collection in Objective-C. ARC is a compiler-time feature where the compiler analyzes code and insert code to track the lifecycles of objects.

When an object (NSObject type or its subclass) is created, we can assign the object to a variable. In ARC, an object variable can have one of the following 4 ownership qualifiers:

  • __strong
  • __weak
  • __unsafe_unretained
  • __autoreleasing

In this blog post, we will review the first two qualifiers __strong and __weak in detail and save the latter two in the next blog post.

The __strong Qualifier

__strong is akin to retain in non-ARC and it’s the default qualifier of an object variable if no ownership qualifier is specified. The following code snippets are identical.

- (void)nonARC {
  id obj = [[MyClass alloc] init];
  [obj release];
}

- (void)ARC {
  // Obj has a strong reference to MyClass object so it owns
  // MyClass object.
  id obj = [[MyClass alloc] init];

  // When the object variable goes out of scope, the owner
  // is discarded and consequently relinquishing ownership of
  // MyClass object.
}

For __strong qualifier, we rely on variable assignment and the end of a variable scope to gain and relinquish object ownership respectively.

The __weak Qualifier

The __weak qualifier is akin to the assign keyword in non-ARC and is typically used to reference an object but claims no ownership on that object. A __weak qualified variable is automatically assigned to nil (effectively disposing the pointer variable) after the object it is pointing to is released. We can perform a conditional check on a __weak qualified variable. If the variable is nil, we know that the referenced object has already been disposed.

__weak qualified variable is useful for for referencing up a parent-child object hierarchy ie. a child object should only establish a weak reference to its parent. For example, a table view can be implemented in iOS by creating a UITableView object and assign it to a UIViewController. Both objects reference each other. UIViewController references UITableView via the view property while UITableView references UIViewController via the delegate property. If we qualify all referencing properties as __strong, we will get into a circular reference situation. Under such circumstances, even though the referencing object variables have gone out of scope, the objects themselves are still not properly disposed. Due to the circular strong reference, the system still thinks that the 2 objects are owned, leading to memory leaks. A detailed explanation of circular reference is available here.

Reference reference between UITableView and UIViewController

The best way to handle circular reference especially if there’s a clear parent-child object relationship is to use a strong/weak reference pattern. UIViewController owns the UITableView object, so it makes sense to qualify this reference with a __strong qualifier. On the other hand, the delegate property in UITableView should be qualified as __weak given that UITableView doesn’t own UIViewController but merely referencing it.

We will talk about __unsafe_unretained and __autoreleasing qualifiers in the next blog post.

Reference

Cliff Notes on How We Build Our Frisbee Thrower

Since I uploaded the videos of the frisbee thrower that my team built to YouTube, I have been getting questions about how the machine was constructed. Regretfully, the team dismantled the machine at the end of the project, team members graduated from school and moved across the country/world, and other than the videos, most other notes on the project are now gone.

I still receive plenty of messages and emails from people, especially high-schoolers and teams competing in robotic competitions, asking and requesting for more details on the construction of the frisbee thrower. I haven’t been very helpful since I don’t have all the answers (like the exact technique and parts that we used). I found some notes in my hard drive a year ago and post them to Slideshare.net. I don’t think they are very useful – they are most sketches of prototypes. Nonetheless you can review them here if you want.

The good news is that I do want to help people who want to build their own version of the frisbee thrower. I will try to talk to from other team members and hopefully write a more detailed article on the construction of the frisbee thrower in the next few weeks. Hopefully, someone out there can learn something and build a more kick-ass frisbee thrower machine.

For now, maybe I can shed some light on the frisbee thrower to the people interested in building the machine by highlighting some of the key elements of the machine. The following video demonstrates how the machine is build. Watch carefully…

YouTube Preview Image

I have also extracted and annotated the following still images in the video that I think are important:

Frisbee thrower prototype (cross section)

Frisbee thrower prototype (top view)

Frisbee thrower (bending the metal guide)

Frisbee thrower (turning the shaft)

Frisbee thrower prototype (adjusting speed of the drill)

UI Design – Lessons Learned, Principles, and Best Practices

This is a presentation I gave earlier this summer on user interface (UI) and user experience (UX) in software. I was motivated to share the lessons that I learned from my own projects as well as my observations I made from working with clients. As I reflected on the UX/UI aspects of the projects, I remember a course I sat in at MIT called 6.831 – UI Design and Implementation. While I didn’t end up taking that class, I learned quite a bit from it. And thanks to MIT OpenCourseware, I can now review the course materials again, which I find very useful. Much of the presentation is adapted and referenced from the course materials archived at MIT OpenCourseware.

Here’s the deck on Slideshare.net.

First milestone for my startup and back to a normal routine

It’s been a while since I last blogged. I have been busy the last 2 months developing an photo-based browser and capturing tool of online classifieds for my startup Invantory. The good news is that I have finally released the app to the App Store yesterday and is now waiting for approval from Apple (finger crossed). There are still a lot that I need to do in order to get the product to the form and state we had envisioned. The 2 most pressing tasks at the moment are getting the camera feature incorporated into the app by the end of the month and developing the web application (very basic function) for release next month.

My work/sleep schedule the past month has been pretty messed up because of the project. Each day, I went to bed later than I did the previous day. Apparently, I tend to get in the zone only during the wee hours of the night after my wife has gone to bed. Since visual design and coding require long, uninterrupted time to perform, it was hard to stop working at 1-4am, especially that’s when I am feeling most productive. For this reason and the aggressive deadline, I often end up going to bed after sunrise. Working this way has its benefits. It’s the time of the day when it’s really quiet and best of all, no distractions – no phone calls, no incoming emails, and far fewer tweets and Facebook updates. I actually get very productive during this time. But there are drawbacks. I feel my biorhythm was out-of-sync and find my energy level low. This schedule isn’t really sustainable and not good for my health in the long-run.

Now that the app is released, I am getting back to the normal schedule and have a more balanced routine.

Synthesize not just analyze

I just finished reading this post on Boston.com. The article mentioned systems thinking a few times, but it is the word “synthesize” that strongly resonated with me. When I was writing my master’s thesis, my thesis supervisor ingrained it in me that synthesis is just as important as analysis. I remember whenever we met, I would just report my findings of my research to him. But he would immediately stop me from continuing and ask me to synthesize a pattern, trend, hypothesis, or solution from these findings. He emphasized to his students the principle of first decomposing a system to its constituent elements (reductive) and then combine the separate concerns into a unified, coherent entity (holistic). He stressed that careful analysis without good synthesis is useless, conversely synthesis without analysis is almost worthless and can even be dangerous. Analysis and synthesis are complements of each other.

Since graduating from grad school, I am finding that analysis and synthesis plays an even more important role in decision making. Knowing how to perform a synthesis of any analysis is vital. However, while many organizations are either good at analyzing problems or making irrational decisions, very few are capable of performing both analysis and synthesis. This is why Lex Schroeder, the author of the above article, is spot-on to say that universities, industries, and think tanks should embrace a new approach that enable future leaders to “synthesize information, making something new and useful out of seemingly disparate ideas.” And I couldn’t agree more.

Picture credits: Applied Systems Thinking Institute

What can entrepreneurs learn from Restaurant Impossible

Lately, I am hooked to a reality TV show on the Food Network called Restaurant Impossible. In the show, Chef and Restauranteur Robert Irvine is given the mission of turning a failing restaurant around in 2 days on a $10k budget. Each episode typically starts with Chef Robert coming into the restaurant to assess the situation. Next he creates an improvement plan, which typically includes doing a physical makeover of the restaurant with the help of his interior designer and general contractors, revising the menu, training the staff, cleaning the kitchen, or introducing additional modern dishes. It’s quite a feat to turn a failing restaurant around in 2 days and with $10k budget. To be honest, I do find the show to be dramatized sometimes and still don’t buy the fact that their $10k budget can realistically produce the kind of interior decor that the designer had conceived. That aside, the show is still entertaining and even educational. Entrepreneurs can learn a lot about identifying problems in a business, turning a business around, and running a business. Here are some of the take aways from the show:

  1. Listen to the customer
    Sometimes the restaurant featured in the show is simply out of step with the market. The root cause of this problem is often attributed to the restaurant failing to listen to its customers and continuing with the path of producing the same food or maintaining the same dinning atmosphere. To get a critical sense of what the restaurant is lacking, Chef Irvine often starts his assessment of the restaurant by simply asking the customers for their critique of the restaurant. Establishing customer feedback loop is key for any business. Feedback doesn’t need to explicit like asking customer directly. Sometimes tacit feedback is just as good in finding out what customers want. Body language like smile, cringe, and puzzle can be very telling about what they think of your products and services. So be critical, observant, and engaging with customers.
  2. Know the bottom-line
    It amazes me how many restaurant owners in the show don’t know what their operating costs are. Some owners don’t even know that they are losing money until Chef Irvine reveal it to them after he looked at their books. Business is all about the bottom-line. Understanding cost is a fundamental imperative for any business. Any entrepreneur should know the cost and cost structure of their business like the back of his hand. If there is no mechanism for tracking costs and revenues, they should be established. It doesn’t need to be sophisticated. Tracking financial/performance metrics by pen and paper is still better than not knowing what’s going on in the company.
  3. Set (high) standards
    Chef Irvine is relentless when it comes to food quality. He trains kitchen staff to maintain a high level of standards. Food must be made with fresh ingredients or mostly with fresh ingredients. No compromise. If a dish doesn’t meet the standards, it gets tossed to the trash rather than to have it served to the customer. Chef Irvine is also adamant about service too. Waiters and waitresses must meet and even exceed needs and expectations. Chef Irvine expects the staff at minimum know the menu well and be able to describe and make recommendations as well as being attentive to customers. But you can’t foster an environment of high standards, unless you clarify expected standards with the staff. Chef Irvine is good with setting clear expectations and even giving feedback to articulate how the standard is not met and what needs to be done to address it. Similarly any business should set high yet attainable standards, clarify them to employees, and finally provide constructive feedback to maintain those standards.
  4. Keep it simple
    In the show, Chef Irvine is often seen revising the menu. Not surprising, most restaurants have big menu with multiple pages, which makes it hard for the customers to select the dishes to order. Also, big menu makes food prep difficult due to a large variety of food involved. The message is clear. For any business, it is better to be in the position of doing few things very well, than to doing many things mediocrely.
  5. Creativity
    To turn things around, Chef Irvine would create new dishes to appeal to the customers. He did so not by using more expensive, new ingredients or complex techniques. He uses existing and often run-of-the-mill ingredients that are already found in the kitchen to create those new dishes. Basically the same ingredients, but combined and cooked differently using simple techniques. The moral of the story is that in the face of constraints and fewer resources in a failing restaurant, Chef Irvine is forced to rely only on improvisation and ingenuity to continue using the same ingredients to yield better results. Call it readjustment, improvisation, or recalibration. Sometimes constraints in business can be drivers to creativity and produce good results.

Well, those are my main take aways from the show. The show is not only entertaining, but for those who are running a business, it is also educational.

HackStar Boston 2011 (Part 2)

TechStarsIn the first part of the article, I recount my HackStar experience at TechStars Boston. Today, I am going to talk about the impact of HackStar has on me and my current endeavor of doing a startup.

Before joining the program, I had thought that my time as a HackStar would be spent mostly coding, which is something I was more than happy to do. While being a HackStar is a lot of hard work, the truth is that I found that there is more than just battening down the hatches and code. To my surprise, HackStars are actually treated as participants of the program, just like any of the team members in the program. While Hackstars don’t get the one-on-one mentorship (since we are not founders), we like the teams have access and participate in activities like lectures, talks, and workshops led by mentors and guest lecturers. Of course there are times when I had to skip a few of the classes and events as I needed to spent more time working in tasks that may be time sensitive. However, I found these lectures and workshops extremely valuable (more so than the classes on entrepreneurship that I took in business school). TechStars lectures and workshops have highly relevant, useful content for starting entrepreneurs to take their startup to the next level. I would encourage any HackStar to attend these classes as much as possible. At the end of the day, it is all about time management and balancing between working on a project and attending classes. Nonetheless, HackStars at TechStars Boston really have unprecedental access and opportunities.

As an entrepreneur who recently started a startup called Invantory, I regularly seek veterans who are doing or have done a startup before. Conversation with them often bring new insights and perspectives, which adds tremendous value and clarity to what I am doing. The network that I built at TechStars has been very beneficial in this regards. Since starting Invantory, I have met with mentors and alumni asking them for their help and advice. In fact, many of them were enthusiastic about helping me in my endeavor. I have also found it gratifying to see how the teams grew in maturity and confidence during the course of the program. I am happy for the alumni of TechStars 2011, with whom I still maintain close interpersonal relationship. I really enjoyed the camaraderie of TechStars Boston.

I have had a long career working in big firms. Nonetheless I have always contemplated with starting my own company and struggled in pondering what is best for me. Do I choose job security and stability over starting my own startup with no or little money? The HackStar program provided that opportunity for aspiring entrepreneurs like me to try out the startup life for 3 months and gain skills that they can immediately apply when they can become real entreprneurs. The program has influenced my outlook, identified seeing what is missing, and discovering what are needed to be done in the context of building my startup.

TechStars’s official HackStars webpage provides a pretty comprehensive list of compelling reasons for joining HackStar. But if you are an aspiring entrepreneur and that your objective is to gain more exposure as well as expanding your network in this space, the choice is a no-brainer. Feel free to reach out to me if you have any questions about the program.

HackStar Boston 2011 (Part 1)

TechStarsIn this blog I hope to share my personal insights to TechStars Boston, a startup accelerator program, from the perspective of a HackStar. The term HackStar is a TechStars slang for a hacker (typically a software developer, a UX designer, or any technical contributor) who provides his/her time and technical skills to help companies selected for the program to become viable businesses by the end of the program. I joined TechStars Boston class of 2011 as a Hackstar in March 2011. For me, I didn’t apply for the program directly or formally. In fact the process happened quite impromptu. I first learned about the program from friends Brent and Eric at Everture, one of the incoming teams, two days before the start of the program. As I already know the managing staff at TechStars, I quickly arranged a meeting to meet with them to learn more about the program before being invited to join the program as a HackStar by the end of the day. The opportunity was great timing since I was transitioning from the industry to the freelance consultancy and entrepreneurship space in the software and Internet space. I already had some spare capacity which allowed me to commit to the program full-time. I also can’t pass up the opportunity of working with the incoming TechStars cohort and learning more about doing a startup. So my decision was really a no brainer. I accepted the invitation and joined the program.

TechStars Boston 2011 WorkshopThere were 12 teams that participated in TechStars Boston 2011. The teams brought a diverse background to the program. Geographically, half of the team were from outside of Boston with 3 teams from the UK, Estonia, and Israel. There was also more female representation in the program with 2 female founders and 1 female co-founder. The teams represent a pretty diverse group of businesses ranging from enterprise software to game to even hardware. I just love the diversity of the cohort. One of the important aspects of TechStars Boston has always been the people. The staff, teams, interns, and HackStars at TechStars Boston are all part of a very big, fun family. Everyone learn from each other. It’s an amicable, highly-collaborative environment. Teams and HackStars collaborated with each other. HackStars have as much to receive and learn from the teams as they do in contributing to the teams. Strong relationships extend beyond the program. TechStars also fosters building strong relationships with mentors, investors, and the startup community. The program invited veterans in the startup space to come mentor the teams or run workshops with variety of topics that are pertinent to the success of the companies.

Skill sets and seniority can very considerably among HackStars. However that didn’t distinguish any HackStar from the others. We are all equals despite our age, seniority, and background. HackStars assist anyone (staff and teams) in every way possible. Nonetheless, it is easy to get overwhelmed sometimes. HackStars could be assigned to a team long-term or be allocated to different teams or projects for quick hacks. There were 12 teams in our cohort and every team needed engineering help in some form or capacity. As a result, it was important to coordinate any work with the managing director. Katie Rae, the managing director at TechStars Boston, often asked for our preference in the types of projects we are interested in working. This helps her to coordinate and manage the needs as well as interests between the teams and Hackstars. The first six weeks at TechStars can be overwhelming for everyone. Something that I learned in my former job is that the busier people get, the more important it is for everyone to meet and sync up on a regular basis. One advice I have for any HackStar reading this post is that you should try meeting with the managing director at least once a week to sync up even if it is for 10 minutes. During the meeting, try to provide some feedback of the teams, update him/her what you are doing, and mention any coming tasks (standard stand-up meeting format from the Agile methodology). In general, there is no right or wrong way of doing things. The HackStar program, just like TechStars is constantly evolving. It’s a startup environment, so don’t be afraid to be a self-starter and be creative, while staying professional (always).

There are more I would want to write. But I have babbled enough (for now). I will continue the second part of this article in the next blog post tomorrow.

Blogging (Again)

BloggingI am ashamed of myself. I have not been updating this blog for sometime. So when my business partner Ian wrote a blog post on our company blog about derelict blogging and why it may not be good for everyone, I realize that something need to be done with this blog site. I can’t just leave it untended. So it’s blogging time again.