iOS Beginners Lesson 2

566 views

Published on

iOS Beginners Lesson 2

Published in: Software
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
566
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
26
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

iOS Beginners Lesson 2

  1. 1. UNDERSTANDING iOS Specifics
  2. 2. OVERVIEW • Lesson 1: Introductions • Lesson 2: iOS specifics • Lesson 3: Data Model • Lesson 4: Logic (Controller) & Interface
  3. 3. LESSON 2: IOS SPECIFICS • Hour 1: Anatomy of an App • Hour 2: View • Hour 3: Different types of applications with Xcode
  4. 4. ANATOMY OF AN APP
  5. 5. ANATOMY OF AN APP • UIApplication • AppDelegate • App Launch Cycle
  6. 6. • Controller object that maintains app event loop • High-level app behaviours ‣ Interace orientation changes ‣ Suspend incoming touch events ‣ Proximity sensing of user’s face ‣ etc… • When app is launched, UIApplicationMain function is called • One single instance of UIApplication is created • We can call the UIApplication object through the sharedApplication class method • UIApplicationMain is made available by importing UIKit framework UIApplication
  7. 7. UIApplication main.m
  8. 8. UIApplication Access UIApplication from anywhere UIApplication *application; application = [UIApplication sharedApplication];
  9. 9. UIApplication Practical usage // Hide status bar when app is launched // AppDelegate.m application:didFinishLaunchingWithOptions: [[UIApplication sharedApplication] setStatusBarHidden:YES];
  10. 10. UIApplication TakeNotes-Info.plist
  11. 11. UIApplication TakeNotes-Info.plist
  12. 12. • Custom object created at App launch time, usually by UIApplicationMain function • Main purpose is to handle transitions between states (the state of your App) ‣ Not running ‣ Inactive ‣ Active ‣ Background ‣ Suspended AppDelegate
  13. 13. • State Transitions are usually handled by corresponding call to methods of our app delegate object ‣ application:willFinishLaunchingWithOptions: (execute code at run time) ‣ application:didFinishLaunchingWithOptions: (perform final initialisations before app is displayed to user) ‣ applicationDidBecomeActive: (app becomes the foreground app) ‣ applicationWillResignActive: (lets us know our app is transiting away from being foreground app) ‣ applicationDidEnterBackground: (lets us know our app is running in background and may be suspended at any time) ‣ applicationWillEnterForeground: (lets us know our app is moving out of background and back into foreground but not yet active) ‣ applicationWillTerminate: (lets us know our app is being terminated. This method is not called if app is suspended) AppDelegate
  14. 14. App Launch Cycle
  15. 15. • UIApplication object • AppDelegate • Data model objects (and documents) • View controller objects • UIWindow object • View, control and layer objects Anatomy of an App
  16. 16. • Representation of what your app does (using custom classes, subclass from NSObject for example) • Spaceship game app will have Spaceship class, TakeNotes app will have Note class, Painting app could define a Image class • Can subclass from UIDocument as well if we want to define a document-based data model • Other possibilities if using CoreData (NSManagedObject) or Realm.io (RLMObject) Data model objects
  17. 17. ANATOMY OF AN APP
  18. 18. • Manages the presentation on screen • A view controller manages a single view and its collection of sub-views • When presented, the view controller makes its views visible by installing them in app’s window • Uses base class UIViewController View Controller
  19. 19. • Co-ordinates presentation of one or more views on screen • Most apps have only one window, which presents content on main screen; but apps may have additional window for content displayed on external screen • To change content of app, use view controller to change views displayed in corresponding window. Never replace window. • Besides hosting views, windows work with UIWindow object
  20. 20. UIWindow object
  21. 21. ANATOMY OF AN APP UIWindow
  22. 22. ANATOMY OF AN APP View
  23. 23. • View and controls and layer objects provide the visual representation of our app • They are subclassed from UIView • View: object that draws content in a designated rectangular area and responds to events in that area. • Controls: “special” view which implements commonly used interfaces like buttons, text fields, toggle switches etc • We generally use the standard classes provided by UIKit framework to create our views and controls • If we want to, we can subclass from UIView directly to create our custom visual element (object) View
  24. 24. • We can control our views from storyboard • Storyboards allow us to set view objects we want on a view • Storyboards also allow us to connect view objects to our code View
  25. 25. View
  26. 26. View Controller DetailViewController.h @property (weak, nonatomic) IBOutlet UITextView *tView; DetailViewController.m @synthesize tView; - (void)configureView { // Update the user interface for the detail item. if (self.detailItem) { self.tView.text = [self.detailItem description]; } }
  27. 27. View to View Controller
  28. 28. View to View Controller
  29. 29. Some Explanations? @property A declared property so the values given to that property can be set and accessed easily @synthesize If we declare a property name (e.g. tView), the default setter name is _tView (setter is where we “set” the value(s) pertaining to the tView object). So we write @synthesize tView in our implementation file so that we can call its setter by the same name IBOutlet Identifier used to identify a property so that Interface Builder can synchronise the display and connection of outlets with Xcode.
  30. 30. Some Explanations? @property (weak, nonatomic) atomic versus nonatomic as property attributes • properties are atomic by default • this means that a value is always fully retrieved by getter method or fully set by setter method, even if accessors are called by different threads • we use nonatomic property attribute to specify that our synthesised accessors simply set or return a value directly, with no guarantees about what happens to this value if it is accessed simultaneously from different threads, so it’s usually faster to access a nonatomic property than an atomic one and we can combine a synthesized setter with our own getter implementation
  31. 31. Some Explanations? @property (weak, nonatomic) weak versus strong as property attributes • In example diagram, XYZPerson object owns the two string properties for firstName and lastName. firstName and lastName is available in our app’s memory as long as XYZPerson is in the memory. In other words, they are strongly referenced by the XYZPerson object
  32. 32. Some Explanations? @property (weak, nonatomic) weak versus strong as property attributes • we use weak attribute when working with groups of interconnected objects. In our example, the tView property can be controlled by other logic in future, so it is not a one-way relationship.
  33. 33. Extra Explanations IBOutlet vs IBAction @interface Controller // links to TextField UI object @property (weak, nonatomic) IBOutlet id textField; // e.g. called when button pushed - (IBAction)doAction:(id)sender;
  34. 34. Different App Templates
  35. 35. • Master-Detail Application • Tabbed Application • OpenGL Game • Utility Application • Page-based Application • Single View Application • SpriteKit Game • Empty Application Different App Templates
  36. 36. Master-Detail App
  37. 37. Tabbed App
  38. 38. OpenGL Game App
  39. 39. Utility App
  40. 40. Page-based App
  41. 41. Single View App
  42. 42. SpriteKit Game App
  43. 43. Empty App
  44. 44. WHAT’S NEXT • Lesson 1: Introductions • Lesson 2: iOS specifics • Lesson 3: Data Model • Lesson 4: Logic (Controller) & Interface

×