Mobile iOS Application Architectures
Download as PPTX, PDF1 like303 views
The document discusses different types of iOS application architectures including thin clients, thick clients, and smart clients. It then covers reasons why good architecture is required like distribution of responsibilities, scalability, and ease of development. Common design patterns used in iOS like singleton, delegation, observer, facade, template method, and composite are explained. Specific patterns like singleton, delegation, observer, facade design are described in more detail. The document also discusses layers in architectures and provides a sample layered architecture. It poses an architectural use case problem and provides suggestions for how to approach it.
Mobile iOS Application Architectures
- 1. iOS Application Architectures Arpit Kulshrestha
- 2. Type of Client Applications Thin Web Client Every communication will be done with a central processing server ,Client only used to show that processed data in mannered way to accomplish information to end user using that application. Thick Client Unlike thin clients, thick clients do not rely on a central processing server because the processing is done locally on the user system. This will provide users with more features, graphics and choices making the applications more customizable Smart / Rich Client Smart clients are Internet-connected devices that allows a user's local applications to interact with server- based applications through the use of web services.
- 3. Why Good Architecture Required Distribution Easiest way to defeat complexity is to divide responsibilities among multiple entities following the Singleton, layers , design patterns etc. Scalability A application can grow to a large level and may change the requirements at mid level or last phase of development so it must be scalable. Ease of Development Less and Smart code which would not take too much time as well as should not too complex to implement and understanding.
- 4. Design Patterns in iOS ● Singleton ● Delegation ● Observer (KVO , NSNotification ) ● Facade Design ● Template Method ● Composite
- 5. Singleton ● When a class is restricted to just one instantiation, that one object is called a singleton ● It is a very common pattern, but developers have to be careful not to overuse it. Delegation ● As the name indicates, the delegation pattern is used to have one object delegate control to another object to act on its behalf. ● This is used to keep implementation specific behavior out of the generic class
- 6. Key Value Observer ● The observer pattern is used when one object wants to know when another object changes ● This pattern is build into every NSObject vi Key-Value Observing NSNotification Centre ● NSNotificationCenter provides a centralized hub through which any part of an application may notify and be notified of changes from any other part of the application
- 7. Facade Design ● Alamofire , AFNetworking, Kingfisher etc. ● Facade Design patterns provide simple interface of large and complex structure / algorithm / calculations. ● We should use in our architecture to separate out complex things with simple to use interface. Template Methods - Subclassing ● For usability of features in applications we can make those classes with some basic functionality which can be subclassed by other node class to extend the functionality.
- 8. Data Binding
- 9. Layers in Architectures Single Unit of Architecture Layer is a basic unit of Architecture to distribute responsibility of features. Number of layers and their responsibilities could be differ as per requirements. It usually between user interactions points to Network / DB layers and vice versa too.
- 10. A Sample Layered Architecture UI Layer Validation Layer Authentication Layer Encryption Layer Storage Layer Payment LayerBookMark Layer
- 11. Architectural Use Case Problem for Discussion There is requirments of iOS Project, where every text label content’s color, font name, text is configurable from Server at any point of time even after app upload to Apple Store. Some features of this app could be offline too and others are heavily dependent upon Server API data. What Architectural Approach you will take to fulfill above Criteria?
- 12. Data Model Layer ● API Request data Model ● API Response Data Model ● Application Data Model ● Business Data Model These Both can be combined, Not necessary to be different unless too big Architecture and data to be handled.
- 13. Application Data Model Vs Business Data Model UI Layer Network Layer Request data Model Storage Layer Application Data Model Business Data Model Contains - Cache, internal calculation use, ViewModel etc.
- 14. You can use Json Export for Data Model { username : “john”, Email : “john@matellio.com” First_Name : John, Lastname : mishel, Age : “30”, Token : “73783e8w798” sessionKey : “heiudh37897weq” } Name - John Mishel Email - john@matellio.com Age - 30
- 15. Assembly Layer ● It contains app configuration level informations such as urls, 3rd party keys, base classes of (viewcontroller - navigation - UI component) etc. ● Appdelegate , UIApplication subclass , plist configurations, theme , font , color , image configurations of iOS project. ● Application level declarations, App Global Cache, and information which would be affecting and related to complete application.
- 16. Infrastructure Layer Infrastructure Layer Contains :- ■ Helper Classes ■ Extensions / Category ■ App Utility ■ Interface / UI Utility
- 17. Services Layer ● Whenever our app required to communicate with the external systems, services whose data and authentication required to achieve features. ● When interacting with Network , Server API. (Alamofire handling, Error Handling) ● 3rd Part API Implementations. (Facebook, Twitter , pubnub etc)
- 18. Storage Layer Storage Layer in iOS Contains :- ● Core Data / Realm Implementations ● Sqlite Implementations ● Save data in plist / json file / other files in document directory only for non incremental data. Note :- Writing data to files would be a costlier comparing to DB in terms of CPU processing.
- 19. Manager Layer ● When a major process, complex calculations, hardware processing, application module processing required to be managed as Single responsibility then it would count in Manager Layer. ● Geo Location, BLE handling , Beacon handling, Remote Notification , Encryption handling, Address Book Manager, Media Cropping handling, user credential handling (via keychain, user defaults etc.), I/O file operations etc.
- 20. Coordinators Layer ● Not always necessary to be in separate layer. ● To combine and coordinating chain of features / asynchronous callbacks / event triggering success or failure. ● There should be very less / No processing in terms of CPU uses. ● Validation Manager, message passing between multiple module, controllers, converting one form of data to another, synchronize data from multiple sources, combine business logic.
- 21. Architectural Use Case Problem II for DiscussionThere is a Ecommerce iOS Application, User can browse the app even without login. - Requirements contains - category , subcategory and featured items in every sub category should be configured from server and dynamic (Not changes frequently but may change in 15 days) - There should be some featured items in each category / subcategory which should show as fast as possible even in low network, there should be no delay due to any circumstances. - Server team comes up with 14 API to call for all such data (category , subcategory and featured items with images) , and data could be change in future. - During testing, client observed that After App Download, some time server fails and no data (category , subcategory and featured items) is there only blank screens. - Client thoughts it would give a very bad impression if after download there will be blank screens even due to any reason. User will be able to see at least category - subcategory and featured items with images in any condition. Analyse and Give Suggestions
- 22. UI Layer UI Layer Contains :- ● Views ● ViewController ● ViewModels Type of Architecture Methodology with above sublayers :- ● MVC ● MVP ● MVVM ● Clean Architecture
- 23. MVC Usually used for Small Application, those initial development time could be upto 3-4 month other than maintenance. MVP Majorly not practical use, almost similar to mvp other than unit testing configurability have more significance here. MVVM Most popular, Significant Mid - Large level application (development time 5 - 12 month) other than maintenance. VIPER Complex, Very large, Scientific & Research, Enterprise application (development time 1.5 year to 3 year) other than maintenance.
- 24. MVC
- 25. MVVM
- 26. Clean Architecture - VIPER