Comparison of IOS and Android frameworks and application development models

both IOS and Android are popular mobile operating systems, used by mobile terminals and smart devices, both of which are designed with advanced software technology, and use advanced design patterns to facilitate application development. What technologies are used in the design of the framework? What design patterns are used? What are the similarities and differences between the design ideas and the application development model?

1. Both use a frame pattern.

The IOS framework is called Cocoa Touch.

The framework provides two functions, one is a collection of classes, each class constructs a problem space, and provides complete solutions and services, and two more importantly, the classes in the framework are interdependent to form a whole, and the structure of the entire application is developed and implemented. A framework-defined structure is a generic structure that provides an execution template for an application, so that many of the framework classes ' implementations are abstract or intentionally incomplete, and such classes typically implement a large number of common code, but leave an important part of the work, either unfinished, or done in a safe, default manner.

Because the application structure is generic, the developer uses the hooks or other methods provided by the framework as subclasses to specialize them to meet the requirements of a particular application; Designing an application is to insert application code into the design provided by the framework to complete the design, and by the framework driver's execution and management of the application's life cycle.

To use a framework, a developer must accept the application structure it defines, and then, as needed, use and customize its classes as much as possible, transforming specific applications to fit the structure.

In the broad sense of metaphor, a framework is like a frame of a house, and application code is a door, window, wall panel, and other elements that make a house unique.

Both the IOS framework and the Android framework provide a variety of ways for applications to modify and extend their common behavior.

One way to add application-specific behavior to the framework is to create a self-stator class of the framework class. Subclasses fill in the gaps in their superclass, providing the missing parts of the framework class. An instance of the stator class occupies its position in the object network defined by the framework, and also inherits the ability of the framework to work with other objects. This design pattern is called template mode.

For example, Android uses this mode to customize the behavior of the application. The Android framework provides the application with the common default implementation of the activity, SERVICE, Content providers, broadcast receivers four application components, which are subclasses of these components, And a few ways to cover the component as needed to complete an application development.

iOS uses delegation and protocol patterns to implement some of the application's specific behavior.

In iOS, one of the frameworks provided by Cocoa touch UIKit to provide and manage the behavior of the application, including the launch of the application until exiting, and the UIKit framework manages many of the core behaviors of the application.

The UIKit framework includes a UIApplication object, the UIApplication object is the heart of the application, which receives events from the system and then dispatches the event to custom code that is implemented by the application for processing.

A specific application simply instantiates the UIApplication object object, without having to subclass it, and the application's specific behavior is implemented by an application delegate object using the delegate and protocol pattern.

The application invokes the Uiapplicationmain function of the UIApplication object to launch the app by instantiating an application delegate object and passing it as a parameter to the Uiapplicationmain function.

Application delegation acts as a subclass of Uiresponder, and also implements the Uiapplicationdelegate protocol, which is used to handle application-related events (mainly the various application state change events) of UIApplication object delegation to achieve the customization of the application.

Protocol mode is one of the unique design patterns adopted by OSX OS framework. A protocol is a declaration of a programmable interface, and any class can implement its methods. The class instance associated with the protocol, invoking the method of the Protocol, and obtaining the value returned by the formal adoption and implementation of the Protocol by the class. This type of communication between objects produces a specific goal, such as parsing an XML code or copying an object. The objects on both sides of the Protocol interface can be related to each other through inheritance and implementation over long distances. The protocol, like a delegate, can be used as a sub-class replacement. Apple provides a framework that declares dozens of agreements.

The model-View-controller (MVC) design pattern is adopted in the two application development

The view Controller object in the iOS framework acts as a controller role in MVC mode, managing the rendering of application content on the screen. The view controller is responsible for displaying and managing individual views and their sub-views, as well as the interaction between those views and other parts of the application. When rendered, the view controller installs the view into the application's window so that they are displayed.

The Uiviewcontroller class in the iOS Uikit framework is the underlying class for all view controller objects, each view controller object is an instance of the Uiviewcontroller class, and provides some default functionality for loading views, rendering views, and rotating views. In response to device rotation and several other standard system behaviors. Application implementations require subclasses of the Uiviewcontroller class to load application-specific views.

UIKit and other frameworks define additional view controller classes to implement standard system interfaces like picker, tab bar interface, and navigation interface.

The View Controller object provides the infrastructure to manage content-related views and coordinate the display and hiding of views. The view controller is also used to manage the child hierarchies of the application view.

Because IOS applications show limited space for content, the view controller also provides the infrastructure needed to evacuate views from one view controller and replace them with views from another view controller. Therefore, a view controller is a way for you to implement various types of content conversions. The view controller object, which can be viewed as a self-contained unit, handles the creation and destruction of its own view, handles the display of its view on the screen, and coordinates the interaction between the view and other objects in the application.

The application loads the view controller and related views through a concatenation diagram or a nib resource file. A concatenation diagram or nib resource file contains views and view controllers that the application uses to render content on the screen. The views in the concatenation diagram are organized according to the view controller that displays them. A tandem chart also determines the transformation of a set of views (called transitions) and brings users from one set of views to another.

When you create a project, the name of the main concatenation diagram file is specified by the Nsmainstoryboardfile key in the Info.plist file that the application contains. For applications that use the nib file instead of a concatenation diagram, you can use the Nsmainnibfile key to replace the Nsmainstoryboardfile key and use that key to specify the main nib file to use.

The iOS frame's window corresponds to a UIWindow object, and the UIWindow object coordinates the rendering of one or more views on the screen. Most applications have only one window for rendering content on the home screen, but the application may have another window that displays content on an external monitor.

To change the content of your application, use the view controller to change the view that is displayed in the corresponding window. You will not replace the window itself.

In addition to hosting the view, the window works with the UIApplication object, delivering events to the view and view controllers.

The iOS framework's view objects include objects such as views, controls, and layer objects, and views and controls visually render the contents of the application. The view is used to draw content within the specified rectangular area and respond to events in that area. Control is a special kind of view that implements common interface objects such as buttons, text bars, and toggle switches.

The View object communicates to the application's model object through the application's controller object, understanding the changes to the model data, and passing the user-initiated modifications through the Controller object

The UIKIT framework provides a standard view, with each view object eventually inheriting from the UIView class for rendering many types of content. You can also define your own custom views by directly UIView (or its subclasses).

In addition to including views and controls, applications can incorporate the Core Animation layer into their view and control hierarchies. A Layer object is actually a data object that represents the visual content. Views use a lot of layer objects behind the scenes to render their content. You can also add custom layer objects to the interface to implement complex animations and other types of complex visual effects.

The views provided by the UIKIT framework are organized into view hierarchies. The views displayed by the application are arranged in a hierarchical structure (intuitively based on inclusions). This mode allows an application to treat a single view and a composition view equally. The root of the hierarchy is a Window object; Each view below the root has a parent view and 0 or more child views. The parent view contains child views. The view hierarchy is a structural component of drawing and event processing.

Model objects in the iOS framework can be implemented by the Uidocument object provided by the Uikit framework to implement the data model of the document type. You can also define your own data model and its associated business logic with the data types provided by the framework as needed.

iOS applications can also use the core data framework to create and implement model objects. Core Data provides an infrastructure for managing modifications to model objects, storing model objects in a file, and then fetching them back. The Core data Framework also provides a number of other features, such as automatic support for undo and redo, and the maintenance of inter-object relationships, allowing only subsets of model objects to be kept in memory at any given time, using patterns to describe model objects, and allowing the maintenance of disjoint collections of edited objects Support data storage version management and migration. Versioning allows you to easily upgrade older versions of user files to the current version, allow data to be stored in ICloud, and then access data from multiple devices.

While the Android system does not have a separate View controller object, the activity component of the application serves as the View controller role, which is used to create and load, render the view, load the data provided by the model object through the model adapter adapter interface, and update the display to the view. The user's changes to the data model on the view are also the responsibility of the activity to update the model through the model adapter interface. Adapter serves as the middleman between data models and views.

The Windows object of the Android system is not open to the application and is managed by the Framework's window Management service.

The Android system is also an application that corresponds to a window that corresponds to the system-provided root view object. The view object is rendered in the window.

Each view object of the Android system inherits from the view class, including the view and ViewGroup objects. The UI of an app is constructed from a view tree that consists of views and ViewGroup objects that are used to draw content on the screen and interact with the user, such as a button buttons or text fields. The ViewGroup object is the container for the view and can contain other view and ViewGroup objects to enable the layout of the interface. The ViewGroup object and other view and ViewGroup objects contained therein are organized in the form of a view tree.

The visual structure of the application UI of an Android system is defined by the specific layout object layouts, each of which is a ViewGroup object. Includes linear layout, Relative layout, Web view, and more.

A View object consisting of multiple sub-views that comprise the application interface is displayed by loading the Setcontentview function into the application as the activity component of the View controller role.

The availability of model objects for Android systems is primarily provided by the content providers, and is provided to the view through a model adapter adapter object provided by the activity.

                                                                                                                    All rights reserved, please mention the link when reprinted, thank you!