Your SlideShare is downloading. ×
Beginning iPhone Development
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Beginning iPhone Development

2,226

Published on

Short presentation talking about Objective C and iPhone development about 6 weeks after I started

Short presentation talking about Objective C and iPhone development about 6 weeks after I started

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,226
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • \n
  • - Barriers to entry:\nObjective C: not a pretty language, message passing, small talk\n- semi-dynamic (responds to, contexts, monkey patching)\n- header files & properties\nDevelopment Tools: developers are second class citizens, testing difficult, TDD/Agile, refactoring\n- get to know the tools\nHobby only: reflected in developer tools, not going for corporate market, no pressure to learn it\n
  • - Objective C 2 autorelease pool (now available on iPhone)\n- memory leaks are much easier to avoid than they are to track down\n- follow conventions for autorelease/retain\n- frameworks: UIKit, CoreGraphics, CoreAnimation, CoreData, Three20/Facebook\n- view lifecycles: - when views are created and destroyed\n- low memory conditions\n- make sure your delegates are still there\n
  • IB - drag and drop\n - probably ok if you’re using the framework exactly as intended\nhand-roller controllers\n- safer option if you want control\n
  • OCUnit, GTM Test (Google Toolbox for Mac)\nGHUnit - can be used with both testing frameworks\n- run unit tests on the device\nOCMock - instance methods only, swizzle for static methods\nInstruments - with XCode 3.2.3 or so, iPad version (on device in iPhone 4)\nUIAutomation - Javascript hooks, device or phone, Jasmine (RSpec/ScrewUnit-like)\nManual Tests - document reproducible steps (Gherkin-like syntax)\n
  • Really for any mobile platform\nPersistence - application lifecycle (multitasking without multitasking)\n- good for users, bad for developers\n- needs to keep track of your state all the time\nPerformance - multiple devices to test on\n- must do device testing (simulator has a lot more resources)\nResolutions - \nDropouts - anyc requests, what to do?\n
  • forward class definition\ntrailing underscore to not clash with frameworks\n+ for class level methods, - for instance level\n\nnonatomic guarantees the whole value is received or set, not thread safety\nOther Property Types:\ncopy - when mutable subclasses\nassign - for primitive types, and delegates\n
  • import - like include with a #ifdef guard for multiple inclusion\nprivate parts in “anonymous” categories, no extra attributes\n(doesn’t mean people can’t use the private methods)\nanonymous vs named categories\n; on methods so the same as header, for copy and paste (not here)\nsuper - needs to be called (returns self, does not set it, so assign)\nuse properties with messaging not . syntax so not confused with C structs\n
  • Call class method on extra class, convention means this is autoreleased\n- anything that wants to keep it needs to call retain, or it will get cleaned up\nrelease any objects that are\nnil - can pass it messages, it just does nothing (clean and readable not equivalent)\n
  • Objective C is not too bad\n- long lines, lots of brackets, after a while see bbrh\n- code actually reads quite nicely\nXCode 4 looks a lot better\nTesting - don’t revert back to old habits\n- new platform, don’t know use in advance, test after?\n
  • \n
  • Transcript

    • 1. An IntroductioniPhone Programming Stewart Gleadow, Thoughtworks
    • 2. Barriers to Entry• Objective C • I can’t see my code for all the square brackets• Development Tools • I survived XCode and lived to tell the tale• Real Software? • Only people that don’t know how to program write iPhone Apps?
    • 3. Learning the Hard Way• Memory Model • Get your memory management right the first time• Frameworks • Don’t fight the framework• View Lifecycles
    • 4. User Interfaces• Interface Builder• Hand-rolled Controllers • NavigationController, TabController • UIViewController subclasses • UIView subclasses
    • 5. Testing• Unit Testing • OCUnit, GTM Test, GHUnit• OCMock • Not on the iPhone?• Functional Testing • Instruments & UIAutomation • Manual Testing
    • 6. iPhone Concerns• Persistence• Performance• Multiple Resolutions• Network Dropouts
    • 7. Header@class ExtraClass;@interface SomeClass : NSObject{ ExtraClass *extraClass_;}+ (NSString *)classLevelMethod;- (id)initWithExtraClass:(ExtraClass *)extraClass;@property (nonatomic, retain) ExtraClass *extraClass;@end
    • 8. Implementation#import “SomeClass.h”#import “ExtraClass.h”@interface SomeClass ()@end@implementation SomeClass- (id)initWithExtraClass:(ExtraClass *)extraClass; { if (self = [super init]) { [self setExtraClass:extraClass]; } return self;}-(void)dealloc; { [extraClass_ release];}@synthesize extraClass = extraClass_;@end
    • 9. Using your ClassExtraClass *extraClass = [ExtraClass defaultExtraClass];SomeClass *someClass = [[SomeClass alloc] initWithExtraClass:extraClass];// do some stuff with your classExtraClass *fromAccessor = [someClass extraClass];[someClass release];someClass = nil;
    • 10. Looking Forward• Barriers to entry are more like hurdles • Objective C is not as bad as I thought • XCode 4 to save the day?• Don’t give up on testing
    • 11. Demo

    ×