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
32.
33.
34.
35.
36.
37.
38. “Be excellent to each other”
Graham Lee
Smartphone Security Boffin, O2
@iamleeg
Notas do Editor
\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
