Cross-platform code for iPhone and iPad applications
We study the Model-View-Presenter paradigm and throw out a bunch of goodies for the iPhone and iPad in the AppStore immediately
How to optimally port an application written for iPhone for iPad, you can only decide yourself. I can only offer a few recipes that will be convenient to use on this particular example of Web applications.
Next, a code organization paradigm will be proposed, components available in SDK 3.2 will be considered. And you will study design patterns yourself :-)
')
It all starts with design. As a rule, several iPhone screens try to fit on one iPad screen.
When writing user interfaces for programs under the iOS platform, the Model-View-Controller paradigm is used. At the same time, it is rather inconvenient when porting and supporting applications for iPhone and iPad. You can find out about it in Wikipedia .
The image shows that there is a link between the model and the view, which violates the freedom to reuse the model. It also makes the controller somewhat heavy, which also has to be rewritten under the iPad.
Instead, I propose to use the paradigm actively promoted on the .Net platform, presented for the first time by Microsoft. It originated from the previous one by replacing the Controller with a Presenter, which takes over the entire interaction of the model and the presentation, breaking the link between the view and the model. As a result, the model becomes more versatile and decreases the Controller code.
How to reduce the amount of written code and, accordingly, reduce the number of errors under iOS
The project should start with a code organization strategy. The examples below use the project settings and the creation of the btContinue button view in code. These views for iPhone and iPad are different. When we compile two applications for both devices, changes should be controlled by macros that change the behavior at the compilation stage. Changes are compiled and hard-coded into the application. Use #define iPad. We get two applications: one for the iPhone, the other for the iPad
Changes are monitored at runtime. We use UIDevice. We receive one application: which is launched both under iPhone and under iPad
In the case of creating a universal application, the definition of a view occurs in the code execution mode, respectively, this operation will slow down the program.
As you can see from this example, both approaches practically do not differ in the amount of written code, but the first option should work faster.
From personal experience
People are very actively using legal software. For example, the project “ Card Index ” (card file of arbitration cases) in the AppStore collects more than 100 downloads per day.
When writing the files of arbitration cases, it was impossible to use the standard components available in the SDK 3.2, such as UISplitViewController and UIPopoverController. For example, the first does not support UINavigationController and should be the main screen. The second component lacks backward compatibility with the iPhone. Output : write your own components. By the way, third-party developers have already made their own versions. About it is, for example, article on Habré
With the desire you can more and more and much more put on the iPad information borrowed from the screens of the iPhone. The draft card index was backward compatible, that is, for ease of use of the transition from case to case instance, the UIPopoverController drop-down list was used, which for no apparent reason has a ban on use on the iPhone, and it turns out that at the code execution stage. Exit : WRITE YOUR COMPONENTS.
Some practice
Usually in practice, the presentation is formed directly in the Presenter.
In the Apple paradigm, screens (views) should be stored in resources, but this is very inconvenient. You need to constantly keep in touch with the Controller, not to mention the model. It was decided that forming the presentation right in Presenter would be most effective. At the same time, the code of the presenter itself is not necessary to increase, even on the contrary, it can be allocated to classes and even subclasses, as shown in this example for the list item.
It must be remembered that we are dealing with weak hardware, for which the processor time and, all the more, the memory becomes very critical resources. Accordingly, there are situations in which the storage of a representation in resources is justified. Moreover, it is for this example code that this is completely justified, since There are simply no extra connections and the code supporting these links. Still, in xib (nib) you can store a UIView, for example, such as UITableViewCell:
But this does not mean at all that for different implementations of the iPhone / iPad this resource xib (nib) cannot be the same!
People are often afraid of the new. They do not want to reanimate macros and give them new life even where they become relevant. The fact is that we simply do not know how to cook them. This is not only healthy food, like oatmeal, but also very tasty if seasoned with grandmother's jam, for example. Pay attention to two examples of the declaration of fields of one interface (class). In the latter, by the way, the error of the first is fixed. But what effect: do not need to forward where something like this and compactness, and most importantly, the clarity of the code!
The inevitable use of macros (disgusting!)
The desirable use of macros (that's better!)
Results
First, you need to define the settings of the project (s) to determine the view (View) at the stage of compilation or execution. Then you need to get rid of the Model-View relationships by transferring the logic of their interaction to the Presenter.
Most effectively we get rid of representations formed by xib, leaving only atomic canvases in them (for example, such as UIViewTableCell).
Then we define macros that limit the presentation for the iPhone / iPad. And don't forget that Objective-C is the “Message Oriented Program” language (we write our own VCL).
How to optimally port an application written for iPhone for iPad, you can only decide yourself. I can only offer a few recipes that will be convenient to use on this particular example of Web applications.
Next, a code organization paradigm will be proposed, components available in SDK 3.2 will be considered. And you will study design patterns yourself :-)
')
It all starts with design. As a rule, several iPhone screens try to fit on one iPad screen.
When writing user interfaces for programs under the iOS platform, the Model-View-Controller paradigm is used. At the same time, it is rather inconvenient when porting and supporting applications for iPhone and iPad. You can find out about it in Wikipedia .
The image shows that there is a link between the model and the view, which violates the freedom to reuse the model. It also makes the controller somewhat heavy, which also has to be rewritten under the iPad.
Instead, I propose to use the paradigm actively promoted on the .Net platform, presented for the first time by Microsoft. It originated from the previous one by replacing the Controller with a Presenter, which takes over the entire interaction of the model and the presentation, breaking the link between the view and the model. As a result, the model becomes more versatile and decreases the Controller code.
How to reduce the amount of written code and, accordingly, reduce the number of errors under iOS
The project should start with a code organization strategy. The examples below use the project settings and the creation of the btContinue button view in code. These views for iPhone and iPad are different. When we compile two applications for both devices, changes should be controlled by macros that change the behavior at the compilation stage. Changes are compiled and hard-coded into the application. Use #define iPad. We get two applications: one for the iPhone, the other for the iPad
Changes are monitored at runtime. We use UIDevice. We receive one application: which is launched both under iPhone and under iPad
In the case of creating a universal application, the definition of a view occurs in the code execution mode, respectively, this operation will slow down the program.
As you can see from this example, both approaches practically do not differ in the amount of written code, but the first option should work faster.
From personal experience
People are very actively using legal software. For example, the project “ Card Index ” (card file of arbitration cases) in the AppStore collects more than 100 downloads per day.
When writing the files of arbitration cases, it was impossible to use the standard components available in the SDK 3.2, such as UISplitViewController and UIPopoverController. For example, the first does not support UINavigationController and should be the main screen. The second component lacks backward compatibility with the iPhone. Output : write your own components. By the way, third-party developers have already made their own versions. About it is, for example, article on Habré
With the desire you can more and more and much more put on the iPad information borrowed from the screens of the iPhone. The draft card index was backward compatible, that is, for ease of use of the transition from case to case instance, the UIPopoverController drop-down list was used, which for no apparent reason has a ban on use on the iPhone, and it turns out that at the code execution stage. Exit : WRITE YOUR COMPONENTS.
Some practice
Usually in practice, the presentation is formed directly in the Presenter.
In the Apple paradigm, screens (views) should be stored in resources, but this is very inconvenient. You need to constantly keep in touch with the Controller, not to mention the model. It was decided that forming the presentation right in Presenter would be most effective. At the same time, the code of the presenter itself is not necessary to increase, even on the contrary, it can be allocated to classes and even subclasses, as shown in this example for the list item.
It must be remembered that we are dealing with weak hardware, for which the processor time and, all the more, the memory becomes very critical resources. Accordingly, there are situations in which the storage of a representation in resources is justified. Moreover, it is for this example code that this is completely justified, since There are simply no extra connections and the code supporting these links. Still, in xib (nib) you can store a UIView, for example, such as UITableViewCell:
But this does not mean at all that for different implementations of the iPhone / iPad this resource xib (nib) cannot be the same!
People are often afraid of the new. They do not want to reanimate macros and give them new life even where they become relevant. The fact is that we simply do not know how to cook them. This is not only healthy food, like oatmeal, but also very tasty if seasoned with grandmother's jam, for example. Pay attention to two examples of the declaration of fields of one interface (class). In the latter, by the way, the error of the first is fixed. But what effect: do not need to forward where something like this and compactness, and most importantly, the clarity of the code!
The inevitable use of macros (disgusting!)
The desirable use of macros (that's better!)
Results
First, you need to define the settings of the project (s) to determine the view (View) at the stage of compilation or execution. Then you need to get rid of the Model-View relationships by transferring the logic of their interaction to the Presenter.
Most effectively we get rid of representations formed by xib, leaving only atomic canvases in them (for example, such as UIViewTableCell).
Then we define macros that limit the presentation for the iPhone / iPad. And don't forget that Objective-C is the “Message Oriented Program” language (we write our own VCL).
Source: https://habr.com/ru/post/103914/
All Articles