Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Andere mochten auch
Ähnlich wie Cross platform Objective-C Strategy
Ähnlich wie Cross platform Objective-C Strategy (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Cross platform Objective-C Strategy
- 1. Patterns & Techniques For Cross-Platform Objective-C Code Graham Lee Smartphone Security Boffin, O2 @iamleeg
- 13. @interface O2LPerson : NSObject - (id)init; - (NSString *)name; - (NSArray *)phoneNumbers; // … @end
- 14. @interface O2LPerson : NSObject - (id)init; - (NSString *)name; - (NSArray *)phoneNumbers; // … @end @implementation O2LPerson { @private O2LPersonStrategy *personStrategy; } - (NSString *)name {return [personStrategy name];} - (NSArray *)phoneNumbers {return [personStrategy phoneNumbers];} // … @end
- 15. @interface O2LPerson : NSObject - (id)init; - (NSString *)name; - (NSArray *)phoneNumbers; // … @end @implementation O2LPerson { @private O2LPersonStrategy *personStrategy; } - (NSString *)name {return [personStrategy name];} - (NSArray *)phoneNumbers {return [personStrategy phoneNumbers];} // … @end @interface O2LPersonStrategyMac @interface O2LPersonStrategyiOS
- 16. @interface O2LPerson : NSObject - (id)init; - (NSString *)name; - (NSArray *)phoneNumbers; // … @end @implementation O2LPerson { @private O2LPersonStrategy *personStrategy; } - (NSString *)name {return [personStrategy name];} - (NSArray *)phoneNumbers {return [personStrategy phoneNumbers];} // … @end @interface O2LPersonStrategyMac @interface O2LPersonStrategyiOS @interface O2LPersonStrategyLiveConnect
- 17. @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
- 21. [frameworkObject hasShinyFeature] [frameworkObject respondsToSelector:] NSClassFromString(@”ShinyClass”) [ShinyClass class] != nil
- 22. [frameworkObject hasShinyFeature] [frameworkObject respondsToSelector:] NSClassFromString(@”ShinyClass”) [ShinyClass class] != nil dlopen(”shiny.dylib”, RTLD_LAZY) != NULL
- 23. [frameworkObject hasShinyFeature] [frameworkObject respondsToSelector:] NSClassFromString(@”ShinyClass”) [ShinyClass class] != nil dlopen(”shiny.dylib”, RTLD_LAZY) != NULL #ifdef SHINYFEATURE
- 30. …
- 31. … include $(GNUSTEP_MAKEFILES)/common.make PACKAGE_NAME = GFractal VERSION = 0.1 # The application to be compiled APP_NAME = GFractal # The Objective-C source files to be compiled GFractal_OBJC_FILES = main.m Controller.m FractalView.m FractalWindow.m # The Resource files to be copied into the app's resources directory GFractal_RESOURCE_FILES = Icons/* include $(GNUSTEP_MAKEFILES)/application.make
- 38. “Be excellent to each other” Graham Lee Smartphone Security Boffin, O2 @iamleeg
Hinweis der Redaktion
- \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