Text("Hello, World!").padding(EdgeInsets(top: 500, leading: 0, bottom: 0, trailing: 0))
references:
https://medium.com/@alexperse/swiftui-padding-with-edgeinsets-example-8febcb9cd6f8
Text("Hello, World!").padding(EdgeInsets(top: 500, leading: 0, bottom: 0, trailing: 0))
references:
https://medium.com/@alexperse/swiftui-padding-with-edgeinsets-example-8febcb9cd6f8
ScrollView (.vertical, showsIndicators: false) {
ZStack(alignment: .top) {
GeometryReader { insideProxy in
Color.clear
// get offset
} // GeometryReader inside
VStack(alignment: .leading, spacing: 10) {
HStack(alignment: .center, spacing: 5){
Text("A").font(.tableData).frame(width: 75, height: 50, alignment: .center)
}
HStack(alignment: .center, spacing: 5){
Text("B").font(.tableData).frame(width: 75, height: 50, alignment: .center)
}
HStack(alignment: .center, spacing: 5){
Text("C").font(.tableData).frame(width: 75, height: 50, alignment: .center)
}
HStack(alignment: .center, spacing: 5){
Text("D").font(.tableData).frame(width: 75, height: 50, alignment: .center)
}
} // VStack
} // ZStack
} // Scrollview
.clipped() // << here !!references:https://stackoverflow.com/questions/63943777/swiftui-scrollview-contents-are-outside-scrollable-area
import SwiftUI
struct JobDetailView: View {
init() {
UINavigationBar.appearance().backgroundColor = .clear
}
var body: some View {
NavigationView {
Form {
Section(header: Text("General")) {
HStack {
Text("Job Name")
Spacer()
Text("Scientist")
.multilineTextAlignment(.trailing)
}
HStack {
Text("Hourly Rate")
Spacer()
Text("$ 1.00")
.multilineTextAlignment(.trailing)
}
}
}
.navigationBarTitle("Scientist")
.navigationBarHidden(false)
}
}
}
#if DEBUG
struct JobDetailView_Previews: PreviewProvider {
static var previews: some View {
JobDetailView()
}
}
#endif
references:
https://stackoverflow.com/questions/57365747/swiftui-navigation-bar-colour
Earlier to App, To display a view made with SwiftUI, you had to wrap it in a UIHostingController, which had to be wrapped in a UIWindow, which had to be defined in SceneDelegate:
import UIKit
import SwiftUI
// Auto-generated code
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
var window: UIWindow?
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
// Use this method to optionally configure and attach the UIWindow `window` to the provided UIWindowScene `scene`.
// If using a storyboard, the `window` property will automatically be initialized and attached to the scene.
// This delegate does not imply the connecting scene or session are new (see `application:configurationForConnectingSceneSession` instead).
// Create the SwiftUI view that provides the window contents.
let contentView = ContentView()
// Use a UIHostingController as window root view controller.
if let windowScene = scene as? UIWindowScene {
let window = UIWindow(windowScene: windowScene)
window.rootViewController = UIHostingController(rootView: contentView)
self.window = window
window.makeKeyAndVisible()
}
}
... Lots more code!
}
at WWDC20, a solution was announced: App.
import SwiftUI
@main
struct HelloWorldApp: App {
var body: some Scene {
WindowGroup {
ContentView()
}
}
}
It looks very, very similar to our HelloWorldApp struct! There are some differences, however:
@main tells Xcode that the following struct, HelloWorldApp, will be the entry point for the app. Only one struct can be marked with this attribute.
According to the documentation, App is a protocol that “represents the structure and behavior of an app.” HelloWorldApp conforms to this. It’s like the base view of your app — no, the app itself. You’re literally writing out what your app will look like in this struct.
Scene — The body of a SwiftUI View must be of type View. Similarly, the body of a SwiftUI App must be of type Scene…
And because platforms like macOS and iPadOS support multiple windows, wrapping all your app’s views in a Scene makes reusability easier while also allowing for “Scene Phases” that include active, inactive, and background states.
WindowGroup is a Scene that wraps views. The view that we want to present, ContentView, is a View — not a scene. WindowGroup lets us wrap them up into a single Scene that SwiftUI can recognize and display.
In the new App protocol, Apple made sure that even the optional parts of the life cycle — those that not many will use — are still super easy to implement:
@main
struct HelloWorldApp: App {
@Environment(\.scenePhase) private var scenePhase
var body: some Scene {
WindowGroup {
ContentView()
}
.onChange(of: scenePhase) { (newScenePhase) in
switch newScenePhase {
case .active:
print("scene is now active!")
case .inactive:
print("scene is now inactive!")
case .background:
print("scene is now in the background!")
@unknown default:
print("Apple must have added something new!")
}
}
}
}
Also, sometimes you still need AppDelegate (for things like Firebase and home screen quick actions). In this case, you can continue using the App protocol — just extend it with @UIApplicationDelegateAdaptor.
references:
https://betterprogramming.pub/say-goodbye-to-scenedelegate-in-swiftui-444173b23015
this is how we can provide navigation bar with navigation bar items
NavigationView {
Text("SwiftUI tutorials")
.navigationBarTitle("Master view")
.navigationBarItems(trailing:
HStack {
Button(action: {
print("SF Symbol button pressed...")
}) {
Image(systemName: "calendar.circle")
.imageScale(.large)
}
Button(action: {
print("Edit button pressed...")
}) {
Text("Edit")
}
}
)
}
to provide kind of detailed view, below can be done
struct DetailView: View {
var body: some View {
Text("Detail view")
}
}
struct ContentView: View {
var body: some View {
NavigationView {
NavigationLink(destination: DetailView()) {
Text("Show detail view")
}
.navigationBarTitle("Master view")
}
}
}
Below is how we can provide navigation bar inline
struct DetailView: View {
var body: some View {
Text("Detail view")
.navigationBarTitle("Detail view", displayMode: .inline)
}
}
references:
https://www.simpleswiftguide.com/swiftui-navigationview-tutorial-with-examples/
sudo arch -x86_64 gem install ffi
import looks first in sys.modules to see whether it has already imported the module. If it has, it will just give you the module object that it made when it last imported the module. Since del mymodule doesn't remove the module object from sys.modules, re-importing it will just rebind the name to the object in sys.modules.
if you want it to re-import the module, do reload(module). Equivalently, delete it from sys.modules and then import it.
Just like any other Python object, a module continues to exist until there are no more references to it. In other words, sys.modules behaves like a regular dict, and
import mymodule
lst = {mymodule.__name__: mymodule}
'mymodule' in globals() # True
'mymodule' in lst # True
del mymodule
'mymodule' in globals() # False
'mymodule' in lst # Still True
sys.modules is only consulted on import statements. You can delete a module from sys.modules to make Python reload it the next time it is imported.
del removes the binding of a name in the appropriate scope; it has nothing to do with modules per se.
sys.modules keeps a list of all modules that have been loaded, regardless of whether they're bound to any name in your program.
References:
https://stackoverflow.com/questions/437589/how-do-i-unload-reload-a-python-module
https://stackoverflow.com/questions/437589/how-do-i-unload-reload-a-python-module/438845#438845
https://stackoverflow.com/questions/7121802/module-name-in-sys-modules-and-globals => Globals