Czy oddzielasz klasy iPhone'a od iPada od uniwersalnej aplikacji?

Mam aplikację Universal (dla iPhone'a i iPada).Czy oddzielasz klasy iPhone'a od iPada od uniwersalnej aplikacji?

Czy są jakieś zalety związane z oddzieleniem iPada od klas iPhone'a w strukturze folderów?

Oto przykład tego, co mam na myśli:

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

Czy to powszechne w projektach objective-c?

Źródło

2012-04-30 Daniel Ribeiro

Jeśli twoja klasa nie ma nic wspólnego z widokami (które mogą zostać zmienione), ale implementuj pewną logikę, niż myślę, że nie ma potrzeby oddzielania klasy. Oto link, który może pomóc: http://stackoverflow.com/questions/7315551/iphone-vs-ipad-development-process-differences-and-similarities – superM

Ten link daje mi jeszcze więcej wątpliwości: http: // stackoverflow. com/a/7315777/807239. Ponieważ aplikacja na iPada jest bardziej używana niż aplikacja na iPhone'a, powinienem przemyśleć cały proces za interfejsem i sposób, w jaki kontrolery nimi zarządzają ... Czy to prawda? –

Zasadniczo interfejs użytkownika urządzenia z urządzenia zmienia się znacznie bardziej niż logika. Jeśli twoja aplikacja nie jest "ciężka", to nie przeprojektowałbym całego przetwarzania. Mam bardzo małe doświadczenie w tworzeniu ios (więcej z Androidem), ale rzadko widziałem, że logika jest implementowana oddzielnie dla różnych urządzeń. To samo dotyczy Androida)) – superM

Jedną z zasad kodowania nigdy nie jest duplikowanie kodu, więc jeśli twoje widoki robią różne rzeczy lub dane powinny być obsługiwane inaczej w zależności od tego czy jest to iPad lub iPhone (np. Różne źródła danych?) To zdecydowanie powinno być w różnych klasach, jeśli nie ... to nie. Użyj jednej i tej samej klasy.

Jedną z rzeczy, która jest powszechna i którą można zaimplementować w takim przypadku, jest rodzaj pomocnika, klasa delegata, jeśli zechcesz, która obsługuje wszystkie popularne metody i działania, które mają miejsce w twoim kodzie.

Złota zasada: Napisz jak najmniejszy kod! Mniej kodu == więcej konserwacji i ma wyższą jakość. Napisz więc jak najmniej kodu, ale nie zmieniaj swoich wymagań. Również podzielony kod ułatwia jego testowanie (jednostkowe), a przez to łatwiejszy do ponownego wykorzystania.

Mam nadzieję, że odpowiedź na Twoje pytanie.

Aktualizacja
wiem istniała terminologia dla tego, po prostu mógł myśleć. Posiadanie powielonego kodu nazywa się "naruszeniem DRY". DRY oznacza Nie powtarzaj się, co jest zasadą rozwoju oprogramowania mającą na celu ograniczenie powtarzania informacji wszelkiego rodzaju, szczególnie przydatne w architekturach wielowarstwowych.
Więcej informacji: DRY on Wikipedia

Źródło

2012-04-30 13:35:37

Dla mnie zależy to od podobieństwa między widokami iPhone'a i iPada. Jeśli istnieją oddzielne pliki XIB, ale oba zawierają te same elementy, łatwo jest zdecydować o użyciu tej samej klasy.

Jeśli pliki XIB na iPhonie i iPadzie mają unikalne elementy, to rozdzielenie klas może być lepsze.

Inną opcją jest utworzenie klasy bazowej udostępnianej przez klasy iPhone'a i iPada w przypadkach, w których chcesz je rozdzielić. Klasa podstawowa zawierałaby kod, który jest wspólny między nimi, na przykład inicjowanie żądań danych lub wspólnego widoku niestandardowego.

Źródło

2012-04-30 13:40:17 bbarnhart

Czy oddzielasz klasy iPhone'a od iPada od uniwersalnej aplikacji?

Odpowiedz

Powiązane problemy