Slide 1

Slide 1 text

Massimo Oliviero Freelance Software Developer Building iOS App Project & Architecture

Slide 2

Slide 2 text

About ! Massimo Oliviero IT Consultant & Software Developer #pragma mark founder ! ! ! email [email protected] web www.massimooliviero.net slide www.slideshare.com/MassimoOliviero twitter @maxoly

Slide 3

Slide 3 text

Source Kimera A sample iOS application ! https://github.com/maxoly/Kimera

Slide 4

Slide 4 text

Agenda •Project •Architecture •Resources

Slide 5

Slide 5 text

Project

Slide 6

Slide 6 text

Project •Conventions •Structure •Folders

Slide 7

Slide 7 text

Conventions

Slide 8

Slide 8 text

Naming conventions •First establish a naming convention for all the things for file names, class names, project names, images, etc. •Use Pascal Case for files, folders and class start with a capital letter i.e. Controllers, MyClass, BestAppEver, etc. •Use Camel Case for methods, properties & variables start with a lowercase letter i.e setFirstName:, userPassword, etc. •Avoid using of acronyms and abbreviations What the hell does it mean “usrPswdLbl”? Yuck!

Slide 9

Slide 9 text

Coding conventions •Choose your coding conventions & style there are ton of conventions out there •K&R Style, or Allman Indent Style http://en.wikipedia.org/wiki/Indent_style •Also read Coding Guidelines for Cocoa by Apple http://developer.apple.com/library/mac/#documentation/Cocoa/ Conceptual/CodingGuidelines/CodingGuidelines.html •But most important, choose a convention and respect it the important thing is always be consistent in your project

Slide 10

Slide 10 text

Coding Guidelines for Cocoa Code Commentary insertObject:atIndex: Good. insert:at: Not clear; what is being inserted? what does “at” signify? removeObjectAtIndex: Good. removeObject: Good, because it removes object referred to in argument. remove: Not clear; what is being removed? An extract from “Coding Guidelines for Cocoa” By Apple

Slide 11

Slide 11 text

Structure

Slide 12

Slide 12 text

Structure •Create a specific workspace don’t let Xcode do it for you •Setting up projects with correct name and prefix use simple word (only alphanumeric) and at least 3 chars for prefix •Create a Build Automation to scripting common tasks to compiling source code or to deploy artifacts with one command •Create a README file with most important info you can use markdown syntax or other markup language like that

Slide 13

Slide 13 text

Structure •Create a AdHoc and AppStore Build Configuration So you can handle configuration for different destination •Configure Build Settings to improve quality i.e. you can enable Static Analyzer or Treat Warnings as Errors •Manage third-part libraries with CocoaPods it reduces headaches of storing/managing 3rd party libraries

Slide 14

Slide 14 text

Workspace

Slide 15

Slide 15 text

Project Name & Prefix •Choose a simple Product Name Only alphanumeric characters, avoid spaces •Choose a right Class Prefix At least 3 chars, use product name's acronym •Choose your Personal Prefix Use it in your Library Projects •Use Automatic Reference Counting If app targets iOS 5.0 or above

Slide 16

Slide 16 text

Build Automation •It’s the act of automating a wide variety of tasks you can use build tools like Ant, Maven, Make , CMake or Rake •At least you must automate Compiling and Deploying compiling and deploying are the most common tasks for developer •You can also automate Testing and Docs generation they are useful to use in combination with a Continuous Integration •You can also automate Static Code Analysis tools for improving quality and reducing defects by inspecting C, C++ and Objective-C code

Slide 17

Slide 17 text

Build Configurations •Use different Configurations to specialize the behavior i.e. Code Signing Identity, Preprocessor Macros, Linker Flags, etc. •Use AdHoc Configuration to deploy testing app i.e. app for TestFlight with its own Code Signing Identity & Linker Flags •Use AppStore Configuration to deploy on App Store Duplicate Release Configuration to use the same optimizations

Slide 18

Slide 18 text

Build Settings •Enable Run Static Analyzer run the Clang static analysis tool on source files •Enable Treat Warning as Errors it causes all warnings to be treated as errors •Disable Compress PNG Files instead use ImageOptim

Slide 19

Slide 19 text

Build Settings •Enable new -Ofast optimization Level it maximizes optimization, use it only in Release build configuration (Disclaimer: do not use if your application has high level floating point precision requirement) •Enable Link-Time Optimization reduce binary and increase performance

Slide 20

Slide 20 text

CocoaPods •Manage third-part libraries with CocoaPods download from http://cocoapods.org/ •CocoaPods manage dependency for you it download source files, imports headers and configures flags •It’s like Ruby Gem but for Objective-C! you can search pods, install & update with one command

Slide 21

Slide 21 text

Readme •The Basics Describe what it is that your project makes easier. Provide code examples detailing how the use of the library. Document the installation process. •Don’t get lazy just because this is for developers Technical writing is still writing, and need not be dry and boring. Just as if you were writing an essay or blog post, you should strive to grab the attention of your reader early. This can be easily accomplished with a well-written introductory paragraph. •The code matters Besides speaking English, your readers also understand code. Developers love to see code samples, and a few lines of syntax highlighted source are worth a thousand words. http://robots.thoughtbot.com/post/50852570430/how-to-write-a-great-readme

Slide 22

Slide 22 text

Folders

Slide 23

Slide 23 text

Folders •Put things in the right place ...and everything makes sense, unfortunately, Xcode doesn’t help us •Map all Xcode group folders to file system directories Xcode group folder don’t represent physical folder •Please remove Supporting Files group folder Who wants “Supporting Files” anymore? yuck!

Slide 24

Slide 24 text

My folders structure •Application specific app related stuff like AppDelegate, main.m, .pch etc •Controllers view (.xib) and view controller stuff put together (obviously) •Library specific application classes like helpers, base classes, services, etc

Slide 25

Slide 25 text

My folders structure •Models application domain models and entities, Core Data models too •Resources assets like images, fonts, sounds, videos, etc. •Vendors third part libraries and frameworks (not managed by CocoaPods)

Slide 26

Slide 26 text

Controllers •Put .xib, .h and .m together in the same folders •One (physical) folder for each view controller •If there are too many, group them into a subfolder •Group them by tab (TabBar) or by functions

Slide 27

Slide 27 text

Resources •One folder for each type of asset images, fonts, sounds, videos, strings, plist, samples •One subfolder for each type of image buttons, backgrounds, logos, shapes, icons, app (splash etc.) •If your app support multiple themes, create a hierarchy themes > themes name > images, fonts, etc. •Name image files based on state (if no assets catalog) “button_blue_normal.png”, “button_blue_highlighted.png”, etc.

Slide 28

Slide 28 text

Folders

Slide 29

Slide 29 text

Architecture

Slide 30

Slide 30 text

Architecture...

Slide 31

Slide 31 text

Application •Design (programming) •Layers •Compositions •Best Practices

Slide 32

Slide 32 text

Design

Slide 33

Slide 33 text

Design •Typically an application is divided into layers A layer is a black box with a contract that define an input and output •To increase the cohesion and decoupling of the software The layers, if well designed, help to decouple and increase the cohesion •Cohesion indicates strongly related software module it would be a subroutine, class or library with common responsibilities •Coupling measure the level of dependency between two software module, such as classes, functions or library

Slide 34

Slide 34 text

Design Principles •Single Responsibility Principle A module should have a single responsibility, and that responsibility should be entirely encapsulated by the module •Open Closed Principle A module should be open for extension but closed for modifications •Liskov’s Substitution Principle Derived types must be completely substitutable for their base types

Slide 35

Slide 35 text

Design Principles •Interface Segregation Principle Clients should not be forced to depend upon interfaces that they don't use •Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions •SOLID: the "first five principles" Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion

Slide 36

Slide 36 text

From Principles to Patterns •Design Pattern is a general reusable solution to a commonly occurring problem within a given context •It’s a description or template for how to solve a problem It’s not a finished design that can be transformed into source code •There are many types of design patterns Architectural, Algorithm strategy, Computational, Implementation strategy, Structural, etc.

Slide 37

Slide 37 text

Most Common Design Patterns •Model View Controller Design Pattern It’s a fundamental design pattern in Objective-C. •Singleton Design Pattern For your information the AppDelegate is a singleton •Chain Of Responsibility Design Pattern Have you ever met the Next Responder or the First Responder?

Slide 38

Slide 38 text

Layers

Slide 39

Slide 39 text

Layers •Layer represents a logical section of the system Layer enforce reusability and testability •A typical client/server app have at least 3 layers Presentation Layer, Business Layer and Data Access Layer

Slide 40

Slide 40 text

Layers ! ! ! ! ! Presentation Layer ! ! ! Data Access Layer ! ! ! Business Layer Views Controllers Service Layer Domain Model Layer Persistence Layer Network Layer

Slide 41

Slide 41 text

Presentation Layer

Slide 42

Slide 42 text

Presentation Layer •It have 2 components: the UI and the presentation logic in Cocoa the UI is the View and the presentation logic is the (View)Controller •Cocoa adopt Model View Controller Design Pattern the Presentation Layer is already in iOS SDK out-of-the-box •Advanced Appearance Customization with Theme use Appearance Proxy and Theme technique to customize UI.

Slide 43

Slide 43 text

Theme // KMRMTheme.h typedef NS_ENUM(NSInteger, KMRMThemeLabelType) { KMRMThemeLabelTypeArgumentTitle, KMRMThemeLabelTypeArgumentDescription }; ! @protocol KMRMTheme ! - (void)configure; - (void)themeLabel:(UILabel *)label type:(KMRMThemeLabelType)type; ! @end ! ! ! ! // Concrete implementations #import "KMRMTheme.h" ! @interface KMRMDefaultTheme : NSObject @end ! @interface KMRMGreenTheme : NSObject @end

Slide 44

Slide 44 text

Presentation Layer ! ! ! ! ! ! ! ! ! ! UIView UIViewController Theme Model Appearance

Slide 45

Slide 45 text

Business Layer

Slide 46

Slide 46 text

Business Layer •It holds the specific app Business Logic and Behaviors It is concerned with the retrieval, processing, transformation, and management of application data; application of business rules and policies •The Domain Model is a conceptual model of business It describes the various entities, their attributes, roles, and relationships, plus the constraints that govern the problem domain •Business Layer gets data through a Service Layer Service Layer defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation

Slide 47

Slide 47 text

Domain Model Layer •Domain Model An object model of the domain that incorporates both behavior and data •You can use simple Objective-C objects A plain old Objective-C object that inheriting from NSObject •Or you can use Core Data objects you can extend the class NSMangedObject with your Objective-C class

Slide 48

Slide 48 text

Service Layer •Service Layers is a design pattern The benefits a Service Layer provides is that it defines a common set of application operations available to different clients and coordinates the response in each operation. •Service Layer uses Data Access Layer to access data Service Layer uses DAL to performs the task of retrieving and storing data both from server via network and from database •Service Layer is used by ViewController No more a ton of line of codes in your ViewController, instead few lines of simple Service Layer calls

Slide 49

Slide 49 text

Data Access Layer

Slide 50

Slide 50 text

Data Access Layer •It’s a layer which provides simplified access to data The data may be stored in a persistent storage like SQLite or in a backend accessible by network •It may uses a Persistence Layer or Network Layer Both exposes a simplify contract to access data

Slide 51

Slide 51 text

Persistence Layer •The persistence layer deals with persisting The persistence layer is responsible for manipulating the database, and it is used by the service layer •You can use Core Data as Persistence Layer Or, in alternative, you can use FMDB for direct access to SQLite

Slide 52

Slide 52 text

Network Layer •Network Layer is responsible of all networking calls •You can use AFNetworking as Network Layer AFNetworking is a delightful networking library for iOS and Mac OS X. It's built on top of NSURLConnection, NSOperation, and other familiar Foundation technologies

Slide 53

Slide 53 text

Composition

Slide 54

Slide 54 text

Composition •It’s a way to combine objects into more complex ones Compositions are a critical building block of many basic data structures, including the tagged union, the linked list, and the binary tree, as well as the object used in object-oriented programming •In a real-world app composition takes an important role On iOS / OS X App composition is necessary for a good layering and for a structure UI.

Slide 55

Slide 55 text

Composition •Custom Views are an example of composition A custom view is used to manage small portions of the interface in order to recycle the content and its management •In a real-world iOS/OS App there are many custom views For example, all views that must be inserted in a scroll view, or all those portions of the view that occur multiple times in different view and only with different content.

Slide 56

Slide 56 text

Best Practices

Slide 57

Slide 57 text

General Best Practice •Use Automatic Reference Counting Always use ARC. All new code should be written using ARC, and all legacy code should be updated to use ARC •Use AppDelegate as Singleton Create all common and singleton objects in App Delegate and then expose them by UIResponder Category

Slide 58

Slide 58 text

Coding Best Practices •Create a property for every ivar and use self to access it Always create a @property for every data member and use “self.name” to access it throughout your class implementation •Alway declare “atomic” or “nonatomic” attribute Always use the “nonatomic” attribute on your properties, unless you are writing a thread-safe class and actually need access to be atomic •Use literals and modern Objective-C syntactic sugar The source code will be less verbose and more clear.

Slide 59

Slide 59 text

Presentation Best Practices •Create a base UIViewController Create a MYBaseViewController from which all the view controllers inherit. In this way all the controllers can inherit common behavior. •Create a base UIView Create a MYBaseView from which all the custom views inherit. In this way all the views can inherit common style and appearance •Create a base UITableViewCell Create a MYBaseTableViewCell from which all the custom table view cells inherit. In this way all the cells can inherit common style and appearance

Slide 60

Slide 60 text

Code Design Best Practices •API Design Pay attention to the design of your API. Learn your target platform's conventions before coding. Define the rules that are in accordance with the convention of language •Block and Delegation When should I use blocks instead of delegation for callbacks? Pay attention to this topic and alway look at Apple docs to see how they done

Slide 61

Slide 61 text

Resources

Slide 62

Slide 62 text

Links •Blocks vs Delegation http://thejoeconwayblog.wordpress.com/2012/05/29/blocks-or- delegation/ •API Design http://mattgemmell.com/2012/05/24/api-design/ •Modern Objective-C http://www.slideshare.net/giuseppearici/modern-objectivec-pragma-night

Slide 63

Slide 63 text

Links •objc.io - A periodical about best practices and advanced techniques in Objective-C http://www.objc.io/ •Automatic Reference Counting recap http://www.slideshare.net/giuseppearici/pragma-night- automaticreferencecounting •How to write a great README http://robots.thoughtbot.com/post/50852570430/how-to-write-a-great- readme

Slide 64

Slide 64 text

Videos •Customizing the Appearance of UIKit Controls Session 114 - WWDC 2011 Session Videos •Advanced Appearance Customization on iOS Session 216 - WWDC 2012 Session Videos •What’s New in the LLVM Compiler Session 402 - WWDC 2013 Session Videos

Slide 65

Slide 65 text

Books •Cocoa Design Patterns •Erik M. Buck & Donald A. Yacktman •Addison Wesley

Slide 66

Slide 66 text

Books •Patterns Of Enterprise Application Architecture •Martin Fowler •Addison-Wesley Professional •updates: http://martinfowler.com/ books/eaa.html

Slide 67

Slide 67 text

Thank you Massimo Oliviero IT Consultant & Software Developer #pragma mark founder ! ! email [email protected] web www.massimooliviero.net slide www.slideshare.com/MassimoOliviero twitter @maxoly Any questions?