Frank Marx IT-Consulting

Softwareentwicklung

 

  • Start
  • Curriculum Vitae
  • Leistungen
  • Biographie
  • GIT-Repository
  • Dies & Das
  • Stats
  • Impressum
  • Blog – Gedankensplitter
  • Off the record
  • Prototyping
  • Kotlin Multiplatform for Mobile
  • SwiftUI & iOS
  • Start
  • Curriculum Vitae
  • Leistungen
  • Biographie
  • GIT-Repository
  • Dies & Das
  • Stats
  • Impressum
  • Blog – Gedankensplitter
  • Off the record
  • Prototyping
  • Kotlin Multiplatform for Mobile
  • SwiftUI & iOS
MyReceipts
October 2, 2023
Compose Multiplatform mit Kotlin
December 1, 2023
Published by Frank Marx on October 9, 2023
Categories
  • App
  • iOS
  • Programming
  • Swift
  • Technical Article
  • Uncategorized
Tags

Local Packages in Xcode

Im Gegensatz zu Sprachen wie Java oder Kotlin hat Swift nicht die Möglichkeit das Projekt explizit in verschiedene Pakete zu unterteilen wie dies z.B. in Java möglich ist durch die Eröffnung von Namensräumen mit dem Package-Statement.
In einem iOS-Projekt sind alle Typen, die nicht explizit mit “private” oder “fileprivate” eingeschränkt wurden im ganzen Modul, d.h. in dem ganzen App-Projekt sichtbar. Dies kann schnell ziemlich unübersichtlich werden wenn das Projekt größer und damit komplexer wird.

Es ist dann schwierig die einzelnen Schichten in der App, wie z.B. Persistenz/Datenhaltung, generelle Services oder Benutzerschnittstelle voneinander sauber zu trennen, um zum einen die Testbarkeit des Codes zu verbessern aber auch um die Zuständigkeiten klar zu trennen. Schnell kann es dann passieren, dass eine untere Schicht ungewollt eine Abhängigkeit zu einer oberen, spezifischeren Schicht hat, was dann diverse Probleme mit sich bringen kann, die man leider dann erst recht spät bemerkt.

Apple empfiehlt, um eine solche Situation zu vermeiden, das Aufteilen des Projektes in unterschiedliche lokale Pakete ( https://developer.apple.com/documentation/xcode/organizing-your-code-with-local-packages ). Typen die in einem lokalen Paket definiert werden sind, solange sie nicht durch den Sichtbarkeitsmodifizierer “public” über die grenzen des Moduls, was in diesem Falle dann das Package ist, bekannt gemacht werden nur innerhalb des Packages sichtbar.

Dies ermöglich es dann in jedem lokalen Package eine öffentliche Schnittstelle zu definieren, eben durch “public“, und die internen, implementationsspezifischen Details in einem privaten Teil von den Verwendern zu verbergen. Dadurch hat man die Möglichkeit die internen Details auch später noch zu ändern und zu refactoren, solange man nicht die öffentliche Schnittstelle, also die API, dadurch bricht.

Der Verwender erlangt durch den Import des Packages dann Zugriff auf alle öffentlichen Schnittstellen und Datentypen. Die Internas bleiben ihm jedoch verborgen. 
Dadurch ist es auch einfacher einzelne Packages in anderen Projekten problemlos wieder zu verwenden und die App in eine diskrete Schichtenarchitektur zu zerlegen:

https://www.fm-it-consulting.de/wp-content/uploads/2023/10/LocalPackages.mp4
Share
1
Frank Marx
Frank Marx

Related posts

July 15, 2024

KMM: Shared logic , native UIs


Read more
June 16, 2024

Snake Prototype: Fluid movement


Read more
June 6, 2024

Basic Snake Demo


Read more

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *