Friday, May 28, 2010

iPad Friday: May 28, 2010

Happy Friday and for all of those who have a three day weekend followed by a summer vacation - Woohoo!  Today's iPad wallpapers are based on geometric patterns and chaos. Enjoy.

(click image for full size wallpaper)




iPhone Friday: May 28, 2010

Happy Friday and for all of those who have a three day weekend followed by a summer vacation - Woohoo!  Today's iPhone wallpapers are based on geometric patterns and chaos. Enjoy.

(click image for full size wallpaper)




Friday, May 21, 2010

iPad Friday: May 21, 2010

Hello and happy Friday! Today's collection of iPad wallpapers are 3D renderings of bricks and blobs with funky materials.  Enjoy.
(click picture for full size image).



iPhone Friday: May 21, 2010

Hello and happy Friday! Today's collection of iPhone wallpapers are 3D renderings of bricks and blobs with funky materials.  Enjoy.
(click picture for full size image).




Tuesday, May 18, 2010

Objective-C Tuesdays: changing default property names

Last week we looked at declaring atomic and nonatomic properties. I promised to talk about writing a thread safe getter this week, but I'm pressed for time today so I'm going to shoe horn in another short topic instead.

When you declare a property in a class, the getter has the same name as the property, while the setter is the capitalized property name with set prepended. For illustration, here is a User class with a property named active:
@interface User : NSObject {
  BOOL active;
}
@property BOOL active;

@end


@implementation User

@synthesize active;

@end
The compiler will generate a getter method named active and a setter method named setActive. Sometimes the default method names aren't exactly what you want; for instance, it's a common convention that getters for BOOL properties be prefixed with is. In the case of our User class, we would like to have the getter named isActive.

The @property directive has two attributes to do just this: getter=name and setter=name. Just like the other attributes of @property, getter and setter are placed in parentheses after the @property directive and before the property type and name. So the active property in our example would look like:
@interface User : NSObject {
  BOOL active;
}
@property (getter=isActive) BOOL active;

@end

@implementation User

@synthesize active;

@end
And usage the active property now looks like:
// example use of isActive getter
User *user = [[User alloc] init];

// getter/setter called as methods
if ( ! [user isActive] ) {
  [user setActive:YES];
}

// getter/setter called with dot syntax
if (user.isActive) {
  user.active = NO;
}
We'll take a closer look at dot syntax in the near future, but basically when the compiler sees code like this:
if ( user.isActive ) {
  user.active = NO;
}
it translates it into this:
if ( [user isActive] ) {
  [user setActive:NO];
}
Dot syntax is complementary to properties, but is separate and unaware of them. When translating a setter call in dot syntax to the corresponding method call, the compiler always looks for a method beginning with set. If you change your setter name to something different, you'll see a compiler error like
object cannot be set - either readonly property or no setter found
or
request for member 'setter name' in something not a structure or union
if you call it using dot syntax. So if we rename the setter for the active property to makeActive instead of the default setActive:
@interface User : NSObject {
  BOOL active;
}
@property (getter=isActive, setter=makeActive) BOOL active;

@end
then using method call syntax, we can now do this:
if ( [user isActive] ) {
  [user makeActive:NO];
}
but because the compiler expects setters to begin with set, using dot syntax generates an error:
if (user.isActive) {
  user.makeActive = NO; // ERROR: request for member 'makeActive' 
                               // in something not a structure or union
}
In general you should follow the standard conventions and use the default getter and setter names; it's less work for you and your code is easier for others to understand.

Next week, we'll look at the thread safety of getters that return retained objects.

Friday, May 14, 2010

iPad Friday: May 14, 2010

Hello and happy Friday. Todays collection of iPad wallpapers are inspired by bees, Escher and in-camera lens effects.  Enjoy
(click/tap image for full-resolution wallpaper)




iPhone Friday: May 14, 2010

Hello and happy Friday. Todays collection of iPhone wallpapers are inspired by bees, Escher and in-camera lens effects.  Enjoy

(click/tap image for full-resolution wallpaper)




Wednesday, May 12, 2010

iPad & iPhone wallpaper templates for designers and photographers

Following Monday's announcement of our new developer resources, today designers and photographers can download our Adobe Photoshop and Illustrator iPhone and iPad wallpaper templates to easily create and share their design with the world.

The iPad version is 1024px x 1024px and contains guides for both portrait and landscape views as well as “rule of thirds” grids to help layout your masterpiece.

The iPhone version is 320px x 480px and has guides for the status bar, time indicator area and “slide to unlock” area as well as “rule of thirds” grid in the center area.

You can download the zipped Photoshop and Illustrator templates in our new Resources section of our website.

If you use them and like them please let us know.  Comment below with a link to your work.  We are always thinking of better ways to help serve the iPhone and iPad community.  Cheers!

Tuesday, May 11, 2010

Objective-C Tuesdays: atomic and nonatomic properties

Two weeks ago we looked at the @property directive and last week we saw how to use the @synthesize directive to tell the compiler to generate getters and setters for properties. We've covered the most commonly used attributes of the @property directive: readonly/readwrite and assign/retain/copy. Today we'll look at the nonatomic attribute and talk about what it's for and why you should (or should not) use it.

Threads and data
By default, your app's code executes on the main thread of your app's process, along with most Cocoa Touch framework code. Any particular method or function runs uninterrupted from start to finish and as long as that method or function leaves all the data it touches in a good state when it returns, your program runs correctly.

When you have multiple threads in your application, things aren't so easy. One key challenge when using multiple threads is to make sure you only read data when it's in a consistent state. This is similar in concept to using a transaction in a SQL database.

Suppose you have a custom UI object that's defined like this:
@interface MyWidget {
  CGPoint center;
  // ...
}
@property CGPoint center;
// ...
@end

@implementation

@synthesize center;

// ...
@end

If you treat instances of this class as read only when you share them between threads, you're safe. The trouble appears when one or both threads start to make changes to the object. If we were to write the getter and setter for center, it would look like this:
// example assign-type getter and setter
- (CGPoint) center {
  return center;
}
- (void)setCenter:(CGPoint)theCenter {
  center = theCenter;
}
This looks simple enough, but the compiler is helping us out here. The center instance variable is a struct that's defined like this:
// struct CGPoint
struct CGPoint {
  CGFloat x;
  CGFloat y;
};
The setCenter: method is actually doing something like this:
- (void)setCenter:(CGPoint)theCenter {
  center.x = theCenter.x;
  center.y = theCenter.y;
}
Let's look at what happens when one thread calls the setter and a second thread calls the getter. In the simple case, the setter and getter calls don't overlap:
// given MyWidget instance myWidget:

// thread 1 calls setter:
[myWidget setCenter:CGPointMake(1.0f, 2.0f)];

// setCenter method executes:
- (void)setCenter:(CGPoint)theCenter {
  center.x = theCenter.x; // 1.0f
  center.y = theCenter.y; // 2.0f
}
// center is now {1.0f, 2.0f}

// ... thread 1 preempted by thread 2 ...

                    // thread 2 calls getter:
                    CGPoint point = [myWidget center];
                    
                    // center method executes:
                    - (CGPoint) center {
                      return center; // 1.0f, 2.0f
                    }
                    
                    // point is now {1.0f, 2.0f}
In this case, we get the answer we expect. Now suppose we do this again, only thread 1 gets preempted by thread 2 in the middle of the setCenter method:
// myWidget.center is {1.0f, 2.0f}

// thread 1 calls setter:
[myWidget setCenter:CGPointMake(3.0f, 5.0f)];

// setCenter method executes:
- (void)setCenter:(CGPoint)theCenter {
  center.x = theCenter.x; // 3.0f

// ... thread 1 preempted by thread 2 ...

                    // thread 2 calls getter:
                    CGPoint point = [myWidget center];
                    
                    // center method executes:
                    - (CGPoint) center {
                      return center; // 3.0f, 2.0f
                    }
                    
                    // point is now {3.0f, 2.0f}

  center.y = theCenter.y; // 5.0f
}

// myWidget.center is now {3.0f, 5.0f}
// but thread 2 read {3.0f, 2.0f}
Now thread 2 is working off of a corrupt value and things are likely to go haywire. To solve this problem, we need to prevent all threads from reading center until the setCenter: method is finished. Because this is a common problem in multithreaded code, Objective-C has a special directive to accomplish this: @synchronized. We can rewrite our getter and setter for the center property like this:
// adding @synchronized to getter and setter
- (CGPoint) center {
  CGPoint theCenter;
  @synchronized(self) {
    theCenter = center;
  }
  return theCenter;
}
- (void)setCenter:(CGPoint)theCenter {
  @synchronized(self) {
    center = theCenter;
  }
}
Now when we read and write center from two threads, @synchronized causes other threads to pause whenever one thread is inside either of the @synchronized blocks:
// myWidget.center is {1.0f, 2.0f}

// thread 1 calls setter:
[myWidget setCenter:CGPointMake(3.0f, 5.0f)];

// setCenter method executes:
- (void)setCenter:(CGPoint)theCenter {
  @synchronized(self) {
    center.x = theCenter.x; // 3.0f

// ... thread 1 preempted by thread 2 ...

                    // thread 2 calls getter:
                    CGPoint point = [myWidget center];
                    
                    // center method executes:
                    - (CGPoint) center {
                      CGPoint theCenter;
                      @synchronized(self) {
                      // thread 1 is already synchronized on 
                      // self so thread 2 pauses here

// ... thread 2 yields and thread 1 runs again ...

    // still inside @synchronized on thread 1
    center.y = theCenter.y; // 5.0f
  }
}

// ... thread 1 preempted by thread 2 again ...

                      @synchronized(self) {
                        // now thread 2 resumes
                        theCenter = center; // 3.0f, 5.0f
                      }
                      return theCenter; // 3.0f, 5.0f
                    }
                    
                    // point is now {3.0f, 5.0f}
I'm glossing over many of the details of @synchronized here. If you're writing multithreaded code, you should read the Threading Programming Guide. The key concept here is that by default, the @synthesize directive generates this type of synchronization for you.

Atomic or nonatomic
Behind the scenes, the @synchronized directive uses a lock to prevent two threads from accessing a @synchronized block simultaneously. Although acquiring and releasing the lock is very quick, it's not free. Occasionally you have a property that is so frequently accessed that all this locking and unlocking adds up to a noticeable penalty. In these rare cases, you can declare the property to be nonatomic:
@interface MyWidget {
  CGPoint center;
  // ...
}
@property (nonatomic) CGPoint center;
// ...
@end
The compiler omits the synchronization code when generating nonatomic getters and setters. Note that there isn't a corresponding atomic attribute for @property; generated getters and setters are synchronized by default.

Don't prematurely optimize
Acquiring a lock is very fast in the common case where no other thread is holding it. According to Apple's docs, it takes about 0.0000002 seconds (that's 0.2 microseconds) on a modern Mac. Even though the iPhone is much slower, you need to be acquiring locks hundreds of thousands of times before you should consider synchronization overhead as anything significant. For the vast majority of code, you should simply not even worry about nonatomic.

Also, keep in mind that the attributes you set on your @property declarations only apply when you use @synthesize to have the compiler generate the getter and setter methods. If you write the getter or setter yourself, the attributes are ignored. Next week we'll look a little more at synchronization and show you how to write a thread safe getter when returning an Objective-C object.

Monday, May 10, 2010

iPhone OS Developer Network on LinkedIn and Facebook

Today Able Pear Software officially launches the iPhone OS Developer Network on LinkedIn and Facebook.

The goal of iPhone Developer Network is to help each other build, test and market our iPhone, iPod touch and iPad apps, from general idea generations to application planning, into the development and build/test phase then following through with marketing strategies and alliances. We hope to empower and enable every developer to be able to get a piece of the "Apple" pie.

Do you have an iPhone, iPod touch or an iPad or are you interested in developing for iPhone OS?  Join our Facebook group.

Entrepreneurs, developers, and business targeting the iPhone OS join us on LinkedIn.
  We have subgroups focusing on specific levels of interest for developers, product managers and marketing/PR and others.

iPad & iPhone graph paper for designers and developers

Today we are happy to announce the first of our new resources for iPhone and iPad developers.  Designing a new app can be a daunting task; these free PDF templates help you with the UI design stage.

Download the PDF file and print as many sheets as you need, then start sketching out your new app interface, interaction and screen flow.  Both are US standard 8.5” x 11” sheets of paper, complete with grid and guides to help you quickly get your ideas down.

The iPad version is the actual size of the screen area (1024px x 768px) and contains guides for the status bar, navigation bars (both top and bottom) as well as “split view” guide all on a grid making it easy for you to sketch out your ideas.

The iPhone version features six 320px x 480px iPhone screens with guides for the status bar, time indicator area and “slide to unlock” all on a grid for easy layout.

You can download the PDF files from the new Resources section of our website.

If you use them and like them please let us know.  We are always thinking of better ways to help serve the iPhone and iPad community.  Cheers!

Friday, May 7, 2010

iPad Friday: May 7, 2010

Hello and happy Friday.  Today's iPad wallpapers are two renderings and two digital creations (one for the US and one for Mexico) - Happy (late) Cinco de Mayo!  Enjoy!

(Click on image for 1024x1024 wallpaper)




iPhone Friday: May 7, 2010

Hello and happy Friday.  Today's iPhone wallpapers are two renderings and two digital creations (one for the US and one for Mexico) - Happy (late) Cinco de Mayo!  Enjoy!




Thursday, May 6, 2010

“Which programming language should I learn first?”

Sadly, I found myself agreeing with these pithy one line descriptions of various programming languages. And of course, Objective-C isn't spared:

To achieve a magical sense of childlike wonder that you have a hard time differentiating from megalomania: Objective C

Tuesday, May 4, 2010

Objective-C Tuesdays: synthesizing properties

Welcome to another episode of Objective-C Tuesdays. Today we pick up where we left off and dive into the @synthesize directive that tells the compiler to write getters and setters automatically.

We already saw that the @property directive can shrink the boilerplate code in a class @interface declaration somewhat. We started with this:
@interface Person : NSObject {
  int age;
  Address *address;
  NSString *name;
}

- (int)age;
- (void)setAge:(int)anAge;

- (Address *)address;
- (void)setAddress:(Address *)anAddress;

- (NSString *)name;
- (void)setName:(NSString *)aName;

// ...
@end
And by using properties, we end up with this:
@interface Person : NSObject {
  int age;
  Address *address;
  NSString *name;
}

@property int age;
@property (retain) Address *address;
@property (copy) NSString *name;

// ...
@end
It's not a giant difference, but it's an improvement. As well as making the code more compact, it separates the logical properties of the class from the rest of the methods. Where @property really starts to pay off is when we combine it with @synthesize. The @implementation for the Person class looks like this:
// hand written getter and setter methods
@implementation Person

- (int)age {
  return age;
}

// assign-type setter
- (void)setAge:(int)anAge {
  age = anAge;
}

- (Address *)address {
  return address;
}

// retain-type setter
- (void)setAddress:(Address *)anAddress {
  if (address != anAddress) {
    [address release];
    address = [anAddress retain];
  }
}

- (NSString *)name {
  return name;
}

// copy-type setter
- (void)setName:(NSString *)aName {
  if (name != aName) {
    [name release];
    name = [aName copy];
  }
}

// ...

@end
That's a lot of boilerplate code to churn out, and memory management in the retain and copy type setters makes it more error prone than simple assign type setters. It's just begging to be machine generated, so let's do that:
// synthesized getter and setter methods
@implementation Person

@synthesize age, address, name;

// ...
@end
All that onerous code can be deleted, and the compiler now generates the correct type of getters and setters based on the attributes of the corresponding @property directive. Note that to use @synthesize, you must have a corresponding @property in the @interface section. I like to put the property names in a list after @synthesize, but you can have multiple @synthesize lines if you like, with one or several property names per line:
@implementation Person

@synthesize age;
@synthesize address, name;

// ...
@end
If you need to provide a particular getter or setter yourself, but you want the compiler to write the rest of them, you simply add it to your @implementation. The compiler looks first to see what you provided before it generates anything. So if we need to do a check when setting the age of a Person instance, we simply write our own setter:
// synthesized getter and setter methods
// with one custom setter
@implementation Person

@synthesize age, address, name;

- (void)setAge:(int)anAge {
  age = anAge;
  if (age >= 55) {
    [[JunkMailer sharedJunkMailer] addPersonToAARPMailingList:self];
  }
}

// ...
@end
This is great, but sometimes you want the property to have a different name than the instance variable that backs it up. For example, we might call the instance variable ageInYears, but want to call the property age:
@interface Person : NSObject {
  int ageInYears;
  // ...
}

@property int age;

// ...
@end


@implementation Person

@synthesize age, address, name;

// ...
@end
This confuses the compiler and it complains:
synthesized property 'age' must either be named the same as a compatible ivar or must explicitly name an ivar
So how do we tell it to use the instance variable ageInYears when generating the age property? The @synthesize directive has one modifier, which solves our problem:
@implementation Person

@synthesize age = ageInYears, address, name;

// ...
@end

That wraps up normal usage of @synthesize. Next week, we look at one attribute of @property that we've neglected so far: nonatomic.

Monday, May 3, 2010

Setup iPad Wi-Fi + 3G with AT&T Cellular Data Plans

The wonderful new iPad Wi-Fi + 3G are being sold like hotcakes and one question people are still asking is how to set up their magical new device with the not-so-magical AT&T and their cellular data plan.  Here is a brief overview:

To set up your iPad Wi-Fi + 3G to use AT&T’s cellular network, assuming you have already set up the iPad itself, go to your iPad’s Settings app and select Cellular Data from the list to the left (as seen in Image 1).

Image 1:  "View Account" takes you to Image 2 (if you've already set up your account, otherwise it gives you a screen where you choose login info, enter a CC number, and pick an initial plan). The "View Account" is also how you set up your account the first time.



Image 2:  Log in using the credentials you selected when you signed up.



Image 3:  You can see your stats and choose to modify plans. Clicking "Add Data or Change Plan" takes you to image 4.



Image 4:  You can see the plan options.



You can upgrade if you think you need more time or downgrade your plan if you think that you’re not using 250 MB in a month (reset your data stats monthly to track usage).



An important thing to consider with the 250 MB plan is that if you are going to be watching a couple of videos a week or downloading content via 3G and not over the Wi-Fi  you will reach your data cap before your 30 days are up.  You will receive a message from AT&T when you’ve passed 80%, 90% and then at 100% of your data cap.  You can then renew for another 250 MB for 30 days, or which ever comes first.

In Review: Keynote, Pages and Numbers for iPad

When I started this blog entry I was thinking I would present the information in five parts,  Keynote, Pages, Numbers, File Sharing and In Conclusion.  After writing my outline and compiling research I realized that there was already considerable amounts of well done reviews and tutorials written.  Rather than drone on about what has already been said I’ll provide you with a couple of links to sites that caught my eye.

Apple, yes, Apple.  They have an online help specifically for Keynote, Pages and Numbers for the iPad.  In addition, they also have an iPad support portal with information on the three iWork apps, iBooks, Wi-Fi, 3G, Syncing, Mail, Applications, Accessories, Enterprise, Service and Repair along with a Get Started page for new users.

Kevin Purcell over at Notebooks.com has a video on working with iWork.com (beta) and the apps: Hands On: iWork.com for Use with iPad iWork Apps.  He then followed up with: Can iWork Make You More Productive?

I also liked Jeff Smykil’s The keyboardless Office: a review of iWork for iPad review on Ars Technica although I disagree with his final conclusion as to the usability of the product.  I think that it is very useable “in the field” and that once you get used to the differences (and some inconsistencies) between the two apps, you can be quite productive with iPad’s iWork suite.

I will continue to work with the iWork for iPad suite and take notes as I learn tricks and tips to help us be more productive with our time.

If you have a link to a review or tutorials on using the iWork apps for iPad that you wish to share or if you have deep feelings about Keynote, Pages or Numbers (or File Sharing) on the iPad, please comment below.  Let your voices be heard.  Cheers!