1 / 52

ITECH 7602 PROJECT

ITECH 7602 PROJECT. FINAL PRESENTATION SYDNEY TOUR. Team Members. Divya Nalla 30107395 Raja Kandasamy 30102984 RajaShekar Donti 30106226 Ren Zhu 30115339 Sadah Omar Sulaiman 30086830. Role of Team Members. Raja Kandasamy – Team Leader, coding Ren Zhu – coding, documentation

chung
Download Presentation

ITECH 7602 PROJECT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ITECH 7602 PROJECT FINAL PRESENTATION SYDNEY TOUR

  2. Team Members Divya Nalla 30107395 Raja Kandasamy 30102984 RajaShekar Donti 30106226 Ren Zhu 30115339 Sadah Omar Sulaiman 30086830

  3. Role of Team Members Raja Kandasamy – Team Leader, coding Ren Zhu – coding, documentation Divya Nalla – Documentation Rajashekar Donti – poster, documentation Sadah Omar Sulaiman – team website, documentation

  4. Aim of the project Develop a simple online digital tour guide on Sydney city for the iOS mobile device

  5. Overview of the project • iOS application on exploring the city Sydney, Australia • Users to explore the classical and traditional places of the city • Users to deliver a tour plan accordingly on their current locations • Navigates the user to their destination comfortably

  6. Project deliverables • Basic project plan • Software project management plan • Software requirement specification • Software architecture design document • Software testing plan • User documentation

  7. Analysis

  8. Analysis • Content for the application • Data required for the application • Team member designation

  9. Design

  10. Design • Sketched the story boards • Compared the other applications • Discussed in locating the buttons and contents

  11. Design Initial story board – Home page

  12. Design Story board – search page

  13. Design Story board – map view

  14. System • Intel-Based Macintosh Computer with IOS SDK (Software Developer Kit) Installed • Applicable to All IOS Devices • Devices includes mobile devices like iPad, Iphone, iTouch & iPod

  15. Design Choices • Pattern • Design/Code Structure • Implementation

  16. App Design Basics • Handling Events • Displaying Content on the Screen • Interacting with the rest of the System • Run the application on background

  17. Core App Objects • Must be Different in Background and Foreground • Runs Simultaneously apps in the background • Only one foreground App but multiple apps can run in the background

  18. Performance • For iOS apps, performance means more than just writing fast code • App does not degrade battery life significantly • The types of changes that are likely to provide the most benefit

  19. Development Tools required • Operating system – Macintosh • Software – xcode 4.6.3 with simulator • Database – Google API • Programming language – Objective C

  20. Prerequisites • Practical aspects involved with implementing your app •  installed the iOS SDK and configured your development environment

  21. Prerequisites contd., • App Store provides information for Developing Environment on how to configure the Development Process and an overview

  22. Class diagram

  23. iOS Architecture Layers • Cocoa Touch • Media • Core Services • Core Operating System

  24. Framework • Dynamic Shared Library • Header Files • Images • Helper Apps

  25. Development Environment X-Code • Create • Test • Debug • Tune This is to be done in an iOS Simulator

  26. Developer Library • Documentation • Platform • Objective c • Google API

  27. Design Patterns The great thing about these patterns is they work well regardless of the tools you are using—whether it’s Objective-C and iOS, Java and Android, or C# and Windows Phone

  28. Evolution and Changes in Apps • Not just once or twice, but many times over—and that’s even before you release it to the App store for the first time • After it’s released, your App will change even more as others use it, provide feedback and suggest enhancements

  29. Where to Implement? • User Interface(UI) • Core logic • Data • It is a Monolithic architecture that is difficult to change • Creates a situation where you can’t change one part of the App without changing the other

  30. Model-View-Controller A more formal way to look at the three main parts of an App is by means of the Model-View-Controller design pattern • Model →  Data • View → User Interface • Controller → Core Logic

  31. Model • The Model is your application’s data and, in iOS, usually takes the form of entities. An entity represents an object in the real world • Customer entity, Order entity, and Product entity

  32. Vision Vision is the interaction between the user and the systems directly. The user interacts with objects like • Buttons • Slide bar • Dropdown boxes • Search bar

  33. Controller The Controller acts as an intermediary between the Model and the View. The Controller is where your core logic goes

  34. Flow diagram

  35. Interaction User interacts with • view • Touch • Tap • Pinch

  36. Interaction contd., In response, the View passes a call to the Controller, and the Controller does something related to the response based on that interaction

  37. Alternative Process Interaction • Sometimes when saved, a Model entity, it gets new or default values • For example, if you save a new location entity, it may be assigned an location number. So, the model can fire an event that tells the controller

  38. Defects •  A view is typically bound to a single view controller • Ultimately, the view controller is a user-interface object. It’s not the tight coupling between the view and the view controller that’s the problem—that’s perfectly fine • The problem is the core logic code that’s in the view controller

  39. Defects contd., • Unfortunately, because the core logic is buried inside the view controller, there isn’t a clean way to reuse this logic in another App. It’s “stuck in the weeds” of the user interface

  40. Better Implementation Techniques Put in the core logic in some other place where you can access it from multiple Apps, or from multiple view controllers in a single App

  41. Screen shots of the application

  42. Screen shots of the application

  43. Screen shots of the application

  44. Screen shots of the application

  45. Screen shots of the application

  46. Screen shots of the application

  47. Screen shots of the application

  48. Screen shots of the application

  49. Screen shots of the application

  50. References • http://weekendtechnologies.com/en/apps • http://www.theinquirer.net/inquirer/feature/2274104/ios-7-specs-and-features-everything-you-need-to-know • http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats

More Related