Swift - Revision history

M: /* Deep linking */

2022-12-05T19:16:23Z

Deep linking

← Older revision		Revision as of 19:16, 5 December 2022
Line 15:		Line 15:
	* Test in the simulator from the terminal with this command:		* Test in the simulator from the terminal with this command:
	xcrun simctl openurl booted "abt://com.abettertrader.abettertrader"		xcrun simctl openurl booted "abt://com.abettertrader.abettertrader"
			# deep link url
			xcrun simctl openurl booted "abt://com.abettertrader.abettertrader/1.103/forgot_password.html"

	== Concepts ==		== Concepts ==

M at 19:07, 5 December 2022

2022-12-05T19:07:11Z

← Older revision		Revision as of 19:07, 5 December 2022
Line 1:		Line 1:
			== Development ==
			=== Deep linking ===
			You can set up deep linking in your app so that when the user clicks a standard url link in a browser or email, it will be redirected to your app, if it is installed. Excellent!

			I am using it to handle "forgot password" links.
			* Determine the link you will be handling. Mine is:
			https://abettertrader.com/1.103/forgot_password.html
			* You must serve up a configuration file from the domain webserver:
			https://abettertrader.com/.well-known/apple-app-site-association
			* Its contents determine which urls will be redirected to the site.
			* Inside the app, there are two requirements.
			** Add a .onOpenURL property to your main view under your App WindowGroup.
			** In the app properties, add a URL Type
			app properties (click on top left name) > Info > URL Types > identifier: abettertrader, URL scheme: abt
			* Test in the simulator from the terminal with this command:
			xcrun simctl openurl booted "abt://com.abettertrader.abettertrader"

	== Concepts ==		== Concepts ==
	* @Binding: allows one "source of truth" with many references called bindings		* @Binding: allows one "source of truth" with many references called bindings

M: /* Lessons learned */

2022-07-31T20:53:31Z

Lessons learned

@@ Line 10: / Line 10: @@
 == Lessons learned ==
 === Lists ===
 * Lists should have NavigationView parents

M: /* Lessons learned */

2022-07-25T22:53:50Z

Lessons learned

← Older revision		Revision as of 22:53, 25 July 2022
Line 10:		Line 10:

	== Lessons learned ==		== Lessons learned ==
			=== Lists ===
	* Lists should have NavigationView parents		* Lists should have NavigationView parents
	* To avoid the FAT ASSED UGLY NavigationView header in the top navigation view (where you do not WANT it, doh), you have to set this on the EMBEDDED view (not NavigationView):		* To avoid the FAT ASSED UGLY NavigationView header in the top navigation view (where you do not WANT it, doh), you have to set this on the EMBEDDED view (not NavigationView):
	.navigationBarHidden(true0		.navigationBarHidden(true0
	.navigationBarTitle("") // don't skip this or it won't work, DOH		.navigationBarTitle("") // don't skip this or it won't work, DOH
			* Always use listStyle plain or you will get awful default Swift 5 LIGHT/DARK backgrounds; it is the only way to set ANY other kind of background on the list
			.listStyle(.plain)

	== SwiftUI vs UIKit ==		== SwiftUI vs UIKit ==

	UIKit is OLD and BIG. You'll still need it to get to some Apple services until SwiftUI is fully fleshed out. For my JSON API driven apps, I WILL AVOID IT LIKE THE PLAGUE, and hold out for SwiftUI expansion.		UIKit is OLD and BIG. You'll still need it to get to some Apple services until SwiftUI is fully fleshed out. For my JSON API driven apps, I WILL AVOID IT LIKE THE PLAGUE, and hold out for SwiftUI expansion.

M: Created page with "== Concepts == * @Binding: allows one "source of truth" with many references called bindings * @StateObject: an object owned and mutated by its parent class * Codable: a desig..."

2022-07-25T22:52:01Z

Created page with "== Concepts == * @Binding: allows one "source of truth" with many references called bindings * @StateObject: an object owned and mutated by its parent class * Codable: a desig..."

New page

== Concepts ==
* @Binding: allows one "source of truth" with many references called bindings
* @StateObject: an object owned and mutated by its parent class
* Codable: a designation that an object can be en/decoded
* Identifiable: a designation that an object uses predictable identification (eg via an ID)
* [https://www.hackingwithswift.com/books/ios-swiftui/custom-modifiers Custom modifiers] allow you to put all your modifiers (eg .font(.headline)) into one reusable set.

=== Modifiers vs Custom View ===
Tip: Often folks wonder when it’s better to add a custom view modifier versus just adding a new method to View, and really it comes down to one main reason: custom view modifiers can have their own stored properties, whereas extensions to View cannot.

== Lessons learned ==
* Lists should have NavigationView parents
* To avoid the FAT ASSED UGLY NavigationView header in the top navigation view (where you do not WANT it, doh), you have to set this on the EMBEDDED view (not NavigationView):
.navigationBarHidden(true0
.navigationBarTitle("") // don't skip this or it won't work, DOH

== SwiftUI vs UIKit ==

UIKit is OLD and BIG. You'll still need it to get to some Apple services until SwiftUI is fully fleshed out. For my JSON API driven apps, I WILL AVOID IT LIKE THE PLAGUE, and hold out for SwiftUI expansion.