ソースを参照

add comment wrt SwiftUI

B. Petersen 5 年 前
コミット
7166b3e415
1 ファイル変更8 行追加1 行削除
  1. 8 1
      docs/uiview-layout.md

+ 8 - 1
docs/uiview-layout.md

@@ -100,7 +100,9 @@ a tricky part (see eg. [3]) seems to be to hold the correct type of rerences to
   - TODO: `AppCoordinator` is also derived from NSObject - is there a know reason for that?
   - TODO: `AppCoordinator` is also derived from NSObject - is there a know reason for that?
   - seem not to help on making code readable - esp. as all coordinators are in a separate file
   - seem not to help on making code readable - esp. as all coordinators are in a separate file
   - i think the "coordinator" as they are used now are of very limited use,
   - i think the "coordinator" as they are used now are of very limited use,
-  
+
+- however, the coordinator get the UINavigationContoller as argument, so there is some use
+
 - remove "coordinator protocol" and do not use?
 - remove "coordinator protocol" and do not use?
   - in general, for some minor adaptions, a simple flag eg. hiding some elements
   - in general, for some minor adaptions, a simple flag eg. hiding some elements
     appear much more readable to me that having several levels of abstraction
     appear much more readable to me that having several levels of abstraction
@@ -108,6 +110,11 @@ a tricky part (see eg. [3]) seems to be to hold the correct type of rerences to
     we can add these things as needed (or use parameters on creation "flag"),
     we can add these things as needed (or use parameters on creation "flag"),
     i think, in the current state, coordinators create more harm than use.
     i think, in the current state, coordinators create more harm than use.
 
 
+- the tearing up of navigator/coordinator into two files is
+  unfortunate, in swiftUI, this is re-combined to a single file,
+  child-class and a makeCoordinator() called by SwiftUI:
+  https://developer.apple.com/tutorials/swiftui/interfacing-with-uikit
+
 
 
 ## some sources
 ## some sources