Gibt es einen Vorteil bei der Trennung von iPhone- und iPad-Klassen in einer Universal App?

Ich habe eine Universal (für iPhone und iPad) -Anwendung.Gibt es einen Vorteil bei der Trennung von iPhone- und iPad-Klassen in einer Universal App?

Gibt es Vorteile beim Trennen des iPads von den iPhone-Klassen in der Ordnerstruktur? Hier

ist ein Beispiel dafür, was ich meine:

- MyApp 
    - Resources 
    - Classes 
     - iPad 
      - SomeUniqueClassOnIPad.h 
      - SomeUniqueClassOnIPad.m 
     - iPhone 
      - SomeUniqueClassOnIPhone.h 
      - SomeUniqueClassOnIPhone.m 
    - SomeUniversalClass.h 
    - SomeUniversalClass.m

Ist das gemeinsam in Objective-c-Projekte?

Quelle

2012-04-30 Daniel Ribeiro

Wenn Ihre Klasse nichts mit Sichten zu tun hat (die geändert werden können), aber etwas Logik implementieren, dann glaube ich nicht, dass es notwendig ist, die Klasse zu trennen. Hier ist ein Link, der helfen könnte: http://stackoverflow.com/questions/7315551/iphone-vs-ipad-development-process-differences-and-imarilities – superM

Dieser Link gibt mir noch mehr Zweifel: http: // stackoverflow. com/a/7315777/807239. Da eine iPad App mehr genutzt wird als eine iPhone App, sollte ich den gesamten Prozess hinter der Benutzeroberfläche überdenken und wie die Controller sie verwalten ... Ist das richtig? –

Grundsätzlich ändert sich die Benutzeroberfläche von Gerät zu Gerät viel mehr als die Logik. Wenn Ihre App nicht "schwer" ist, würde ich die gesamte Verarbeitung nicht neu gestalten. Ich habe sehr wenig Erfahrung in der Entwicklung für iOS (mehr mit Android), aber ich habe selten gesehen, dass die Logik separat für verschiedene Geräte implementiert ist. Das gleiche gilt für Android)) – superM

Eine der Regeln in der Codierung ist nie doppelte Code, also wenn Ihre Ansichten verschiedene Dinge tun oder wenn Daten unterschiedlich behandelt werden sollten, je nachdem ob ein iPad oder iPhone (zB verschiedene Datenquellen?) Sollte es definitiv in verschiedenen Klassen sein, wenn nicht .. dann nein. Verwenden Sie ein und dieselbe Klasse.

Eine Sache, die üblich ist und die Sie in diesem Fall implementieren könnten, ist eine Art Helfer, eine Delegate-Klasse, die alle gängigen Methoden und Aktionen in Ihrem Code behandelt.

Goldene Regel: Schreiben Sie so wenig Code wie möglich! Weniger Code == mehr wartbar und hat eine höhere Qualität. Schreiben Sie so wenig Code wie möglich, ohne Ihre Anforderungen zu beeinflussen. Teilen Sie Code auch auf, damit es einfacher ist, (Einheits-) Test durchzuführen und dadurch einfacher wiederzuverwenden.

Ich hoffe, dass Ihre Frage beantwortet.

aktualisieren
Ich kenne eine Terminologie für diese da war, konnte nur daran denken. Doppelter Code heißt "DRY-Verletzung". DRY steht für Do not Repeat Yourself, was ein Prinzip der Softwareentwicklung ist, das darauf abzielt, die Wiederholung von Informationen aller Art zu reduzieren, besonders nützlich in mehrstufigen Architekturen. Weitere Informationen: DRY on Wikipedia

Quelle

2012-04-30 13:35:37

Für mich hängt es von der Gemeinsamkeit zwischen dem iPhone und iPad Ansichten. Wenn es separate XIB-Dateien gibt, die jedoch dieselben Elemente enthalten, ist es leicht, sich für die Verwendung derselben Klasse zu entscheiden.

Wenn die XIB-Dateien des iPhones und iPads einzigartige Elemente enthalten, könnte die Trennung der Klassen besser sein.

Eine weitere Option besteht darin, eine Basisklasse zu erstellen, die von den iPhone- und iPad-Klassen für Fälle geteilt wird, die Sie trennen möchten. Die Basisklasse enthält den Code, der ihnen gemeinsam ist, z. B. das Einleiten von Datenanforderungen oder eine allgemeine benutzerdefinierte Ansicht.

Quelle

2012-04-30 13:40:17 bbarnhart

Gibt es einen Vorteil bei der Trennung von iPhone- und iPad-Klassen in einer Universal App?

Antwort

Verwandte Themen