Cross platform Objective-C Strategy

1,268 views
1,183 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,268
On SlideShare
0
From Embeds
0
Number of Embeds
123
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • Page 6: NeXT. Look for Rhapsody in 1997, Cheetah in 2001, iPhone OS in 2007\n
  • This is about managing change, both change over time (different versions of an OS have different features/bugs) but over space (different environments exist in different places).\n
  • This is about managing change, both change over time (different versions of an OS have different features/bugs) but over space (different environments exist in different places).\n
  • This is about managing change, both change over time (different versions of an OS have different features/bugs) but over space (different environments exist in different places).\n
  • This is about managing change, both change over time (different versions of an OS have different features/bugs) but over space (different environments exist in different places).\n
  • This is about managing change, both change over time (different versions of an OS have different features/bugs) but over space (different environments exist in different places).\n
  • This is about managing change, both change over time (different versions of an OS have different features/bugs) but over space (different environments exist in different places).\n
  • This is about managing change, both change over time (different versions of an OS have different features/bugs) but over space (different environments exist in different places).\n
  • First place to start is object design: the behaviour of our app shouldn’t depend on how the libraries we’re using implement their features. Encapsulate the varying (i.e. version/platform specific) behaviour behind an interface. Useful patterns: class cluster, strategy.\n
  • First place to start is object design: the behaviour of our app shouldn’t depend on how the libraries we’re using implement their features. Encapsulate the varying (i.e. version/platform specific) behaviour behind an interface. Useful patterns: class cluster, strategy.\n
  • First place to start is object design: the behaviour of our app shouldn’t depend on how the libraries we’re using implement their features. Encapsulate the varying (i.e. version/platform specific) behaviour behind an interface. Useful patterns: class cluster, strategy.\n
  • First place to start is object design: the behaviour of our app shouldn’t depend on how the libraries we’re using implement their features. Encapsulate the varying (i.e. version/platform specific) behaviour behind an interface. Useful patterns: class cluster, strategy.\n
  • First place to start is object design: the behaviour of our app shouldn’t depend on how the libraries we’re using implement their features. Encapsulate the varying (i.e. version/platform specific) behaviour behind an interface. Useful patterns: class cluster, strategy.\n
  • First place to start is object design: the behaviour of our app shouldn’t depend on how the libraries we’re using implement their features. Encapsulate the varying (i.e. version/platform specific) behaviour behind an interface. Useful patterns: class cluster, strategy.\n
  • First place to start is object design: the behaviour of our app shouldn’t depend on how the libraries we’re using implement their features. Encapsulate the varying (i.e. version/platform specific) behaviour behind an interface. Useful patterns: class cluster, strategy.\n
  • First place to start is object design: the behaviour of our app shouldn’t depend on how the libraries we’re using implement their features. Encapsulate the varying (i.e. version/platform specific) behaviour behind an interface. Useful patterns: class cluster, strategy.\n
  • First place to start is object design: the behaviour of our app shouldn’t depend on how the libraries we’re using implement their features. Encapsulate the varying (i.e. version/platform specific) behaviour behind an interface. Useful patterns: class cluster, strategy.\n
  • Where possible, test for features rather than platforms (notice that in the address book example, Mac OS X and iOS offer the same frameworks and functions but they work differently so we have to test for platforms). Weak linking frameworks and libraries lets you test for their existence at runtime. It’s best to restrict use of these tests as much as possible, hence the encapsulation. Abstract Factory is a great pattern here. Autoconf is a useful tool for creating preprocessor tests for different features: though obviously it is done at build-time so think about where you’re building.\n
  • Where possible, test for features rather than platforms (notice that in the address book example, Mac OS X and iOS offer the same frameworks and functions but they work differently so we have to test for platforms). Weak linking frameworks and libraries lets you test for their existence at runtime. It’s best to restrict use of these tests as much as possible, hence the encapsulation. Abstract Factory is a great pattern here. Autoconf is a useful tool for creating preprocessor tests for different features: though obviously it is done at build-time so think about where you’re building.\n
  • Where possible, test for features rather than platforms (notice that in the address book example, Mac OS X and iOS offer the same frameworks and functions but they work differently so we have to test for platforms). Weak linking frameworks and libraries lets you test for their existence at runtime. It’s best to restrict use of these tests as much as possible, hence the encapsulation. Abstract Factory is a great pattern here. Autoconf is a useful tool for creating preprocessor tests for different features: though obviously it is done at build-time so think about where you’re building.\n
  • Where possible, test for features rather than platforms (notice that in the address book example, Mac OS X and iOS offer the same frameworks and functions but they work differently so we have to test for platforms). Weak linking frameworks and libraries lets you test for their existence at runtime. It’s best to restrict use of these tests as much as possible, hence the encapsulation. Abstract Factory is a great pattern here. Autoconf is a useful tool for creating preprocessor tests for different features: though obviously it is done at build-time so think about where you’re building.\n
  • Where possible, test for features rather than platforms (notice that in the address book example, Mac OS X and iOS offer the same frameworks and functions but they work differently so we have to test for platforms). Weak linking frameworks and libraries lets you test for their existence at runtime. It’s best to restrict use of these tests as much as possible, hence the encapsulation. Abstract Factory is a great pattern here. Autoconf is a useful tool for creating preprocessor tests for different features: though obviously it is done at build-time so think about where you’re building.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • GNUstep: build with makefiles that encapsulate all the complexity of configuring for the target platform, can be native or cross-compiled. \n
  • GNUstep: build with makefiles that encapsulate all the complexity of configuring for the target platform, can be native or cross-compiled. \n
  • GNUstep: build with makefiles that encapsulate all the complexity of configuring for the target platform, can be native or cross-compiled. \n
  • GNUstep: build with makefiles that encapsulate all the complexity of configuring for the target platform, can be native or cross-compiled. \n
  • GNUstep: build with makefiles that encapsulate all the complexity of configuring for the target platform, can be native or cross-compiled. \n
  • GNUstep: build with makefiles that encapsulate all the complexity of configuring for the target platform, can be native or cross-compiled. \n
  • GNUstep: build with makefiles that encapsulate all the complexity of configuring for the target platform, can be native or cross-compiled. \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Give people what they expect to see on whatever platform they’re using. That may mean writing custom UIs for each platform, but that’s OK: it’s not repetition because each is adding something useful to the app.\n
  • \n
  • \n
  • Cross platform Objective-C Strategy

    1. 1. Patterns & Techniques For Cross-Platform Objective-C Code Graham Lee Smartphone Security Boffin, O2 @iamleeg
    2. 2. http://www.levenez.com/unix
    3. 3. http://www.levenez.com/unix
    4. 4. @interface O2LPerson : NSObject- (id)init;- (NSString *)name;- (NSArray *)phoneNumbers;// …@end
    5. 5. @interface O2LPerson : NSObject - (id)init; - (NSString *)name; - (NSArray *)phoneNumbers; // … @end@implementation O2LPerson {@privateO2LPersonStrategy *personStrategy;}- (NSString *)name {return [personStrategy name];}- (NSArray *)phoneNumbers {return [personStrategyphoneNumbers];}// …@end
    6. 6. @interface O2LPerson : NSObject - (id)init; - (NSString *)name; - (NSArray *)phoneNumbers; // … @end@implementation O2LPerson {@privateO2LPersonStrategy *personStrategy;}- (NSString *)name {return [personStrategy name];}- (NSArray *)phoneNumbers {return [personStrategyphoneNumbers];}// …@end@interface O2LPersonStrategyMac@interface O2LPersonStrategyiOS
    7. 7. @interface O2LPerson : NSObject - (id)init; - (NSString *)name; - (NSArray *)phoneNumbers; // … @end@implementation O2LPerson {@privateO2LPersonStrategy *personStrategy;}- (NSString *)name {return [personStrategy name];}- (NSArray *)phoneNumbers {return [personStrategyphoneNumbers];}// …@end@interface O2LPersonStrategyMac@interface O2LPersonStrategyiOS@interface O2LPersonStrategyLiveConnect
    8. 8. @interface O2LPerson : NSObject - (id)init; - (NSString *)name; - (NSArray *)phoneNumbers; // … @end@implementation O2LPerson- (id)init { [self release]; self = nil; if (iOS) return [[O2LPersoniOS alloc] init]; else if (mac) return [[O2LPersonMac alloc] init]; //…}- (NSString *)name {[self subclassResponsibility: _cmd];}// …@end
    9. 9. [frameworkObject hasShinyFeature][frameworkObject respondsToSelector:]
    10. 10. [frameworkObject hasShinyFeature][frameworkObject respondsToSelector:]NSClassFromString(@”ShinyClass”)
    11. 11. [frameworkObject hasShinyFeature][frameworkObject respondsToSelector:]NSClassFromString(@”ShinyClass”)[ShinyClass class] != nil
    12. 12. [frameworkObject hasShinyFeature][frameworkObject respondsToSelector:]NSClassFromString(@”ShinyClass”)[ShinyClass class] != nildlopen(”shiny.dylib”, RTLD_LAZY) != NULL
    13. 13. [frameworkObject hasShinyFeature][frameworkObject respondsToSelector:]NSClassFromString(@”ShinyClass”)[ShinyClass class] != nildlopen(”shiny.dylib”, RTLD_LAZY) != NULL#ifdef SHINYFEATURE
    14. 14.
    15. 15. …include $(GNUSTEP_MAKEFILES)/common.makePACKAGE_NAME = GFractalVERSION = 0.1# The application to be compiledAPP_NAME = GFractal# The Objective-C source files to be compiledGFractal_OBJC_FILES = main.m Controller.m FractalView.m FractalWindow.m # The Resource files to be copied into the apps resources directoryGFractal_RESOURCE_FILES = Icons/*include $(GNUSTEP_MAKEFILES)/application.make
    16. 16. “Be excellent to each other” Graham Lee Smartphone Security Boffin, O2 @iamleeg

    ×