I have just completed SXPS288 Remote experiments in physics and space. It was a great experience, and I am looking forward to my next module for my Open University Physics degree starting in October (I am in no hurry to get the qualification, and sign up for a single module each year). I therefore have some space for a summer project.

I would like to add LaTeX processing into my FlashCardGenie iPhone app, and have discovered LaTexSwiftUI  (a SwiftUI view that renders LaTeX equations) available through the Swift Package manager to help me along. However my Swift knowledge and experience is in UIKit. Recognising that SwiftUI is clearly the way forward, I have decided it is time to bite the bullet and migrate FlashCardGenie over to SwiftUI.

It is possible to do this incrementally but my preference is for a clean rewrite so that I can take full advantage of SwiftUI’s modern UI design techniques as well. So earlier on this year I completed the Apple introductory tutorials on SwiftUI. My other commitments meant that I did not consolidate that knowledge properly, other than confirming a conviction that it is the right direction.

But now I have space to execute my plan for this, which is:

• Learn SwiftUI
• Redesign FlashCardGenie interface in SwiftUI (from UIKit)
• Rewrite FlashCardGenie using SwiftUI
• Upgrade rewritten version to enable LaTeX as an option in any text based note attached to a FlashCard. This is key to supporting Mathematics FlashCards and FlashSets better.

After a little research I have decided to Learn SwiftUI using Paul Hudson@twostraws (Hacking with Swift) 100 days of SwiftUI. This demands a daily commitment of 1 hour on the course itself plus a blog posting on progress for 100 days (happily achievable before the end of October). Posting on this website’s blog is my chosen social media platform, so here goes!

Just completed Day 0. My takeaways and thoughts are:

• Have I have fallen into the lone wolf trap? I do use StackOverflow and other help forums extensively so not entirely, but I have not generally engaged in any specific subject matter forums. I have therefore joined HackingWithSwifts hackingwthswift.com/slack SwiftUI community as a step towards addressing this risk. Might try out an iOS Dev happy hour as well, though the June date is not yet up on the site.
• mmm Testing, I have let things slip on that. I actually like writing testing code (I became heavily invested in the java testing framework at one point a few years ago) but am embarrassed to admit that while I have formalised automated testing for some of my training apps in the past, my actual released app (FlashCardGenie) has been acceptance tested mainly through the process of writing the tutorial guides and creating the training videos. I need to address this and will do formally in the SwiftUi rewrite. I need to get more familiar with xcTest in XCode as a start….

Although I have been using Swift / UIKit for over 3 years now and have an educational support app released on the Apple store, I always like to consider myself a beginner when learning anything new (in this case SwiftUI) since it never fails to deliver, and this is no exception. Today (and indeed the first 14 days) cover the essential fundamentals of Swift itself as a pre-requisite for getting into SwiftUI which you might think should hold nothing new for me…and yet here is a surprisingly long list of essential basics that I had forgotten about (if I ever knew them!):

• Running up to any chosen line in the playground.
• You can put emojis in strings
• You can have multi line strings using triple inverted commas “””
• .hasPrefix and .hasSuffix methods of String
• Use of underscores in large constant integers for readability
• .isMultiple(of:) method of Int
• How easy it is to demonstrate double arithmetic errors (just print the result of 0.1 + 0.2)!

Some more essential basics that I had forgotten about (happily a shorter list than yesterday):

• Booleans are named after the mathematician George Boole (1818-1864)
• .toggle() is alternative to !
• inefficiency of + for strings

In How to store ordered data in arrays

• Optimisation advantage of Array<T>.reversed() held as a new type ReversedCollection<Array<String>

In How to store and find data in dictionaries

• Use of default value return if lookup does not exist

In How to use sets for fast data lookup

• The reason for Set.insert() rather than Set.append() is because Sets are unordered.
• Although I have used Sets (primarily when I wanted to ensure no duplicates), I was not conscious of the high performance benefit of Set.contains() vs Array<T>.contains() – hence exploit when can.

In How to create and use enums

• Each enum is its own type hence no need to state the type explicitly for a defined variable due to type safe rules
• Although I have used enums, I was not conscious of its highly optimised storage method – hence as for Sets, exploit when can.

Straightforward today – but was pleased I remembered the syntax of how to convert arrays to sets when coding the checkpoint exercise.

Key takeaways:

• Inefficiency of string comparison vs numbers
• Inefficiency of .count in Swift
• Efficiency of .isEmpty
• Efficiency of not including boolean result == true (I have often done this thinking this was more readable…more fool me)
• Use of comparable in enums
• Readability of enums especially when used in conjunction with switch
• The existence of fall-through in switch statements
• When the ternary conditional operator are needed (ie when you need to include conditional processing within a statement (like print)
• The fact that the ternary conditional operator is going to be essential for use in SwiftUI

Key takeaways:

• Range is its own type in Swift
• Through 1…12 and up to 1..<12 options
• array[1…] section of array defined b one sided range (every element from array[1] to end of array)
• Int.random[in: 1…1000]
• Double.random[in: 0…1]
• continue (to break ust the current iteration
• continue and break to a labelled statement (useful for eg breaking more than one level of loop

Key takeaways:

• Distinction between a parameter (the placeholder label for an input into a function) and an argument (the value passed into the function identified by the placeholder label).
• A single line function that returns a value does not need the keyword
• Use tuples to return multiple values (de-structuring to read multiple returns using tuples)
• Can distinguish a function by its parameter labels (not just its parameter types)
• When to stop using a parameter label name (when the function is a verb and the parameter is a noun that the verb acts upon) to avoid repeated parameter label and name of what is being passed.

Missed a couple of days away on holiday in Cornwall. Still there actually but a wet rainy day .. good opportunity to get back to 100 days of SwiftUI!

Key takeaways:

• Optimisation option for .removeAll(keepingCapacity)
• throws using own eNums
• try! (when do not care  about a fatal error occurring)
• try? (when prepared to lose error information)
• rethrows (for functions that do not throw errors but exist within functions that do)

Back from holiday in Cornwall! Great tutorial today demystifying Closures. I have used closures quite extensively and indeed successfully written my own functions with functions as parameters, but always with a underlying confusion prevailing in every case.

Paul has sorted that for me at last! I really think I can now improve the readability of the closures I have written to date with this deeper understanding under my belt.

Key takeaways:

• “in” as a marker separating type definition from code.
• When to use shorthand syntax and when not.
• When trailing closures work best
• I was confusing the syntax associated with the definition of function parameters with the syntax options associated with executing them. 

I continue to be amazed about how much I am gaining from going through all the basics again. Can anyone guess the link between the photo I have chosen today and the subject matter? The earlier ones are obvious but going up to 100 in the same vein was clearly a non starter….

Key takeaways:

• Clarity on rationale for the mutating keyword and its associated constraints. 
• Clarity on the init function for structs.
• Clarity on the implication of assigning default values to constants (let) and variable (var) properties on the required signature when initialising a new struct.
• A useful comparison of tuples with structs
• An understanding of the difference between a function and a method.
•  willSet and oldValue
• The use of an extension retain automatic struct initialisers

On the slightly negative side I discovered that playground does not handle function variables the same way as in a project (printed output is not displayed).  

Key takeaways:

• private(set) for write only access control
• use of static properties for example data
• self vs Self (self is current value of this instance of a struct while Self is the current type of this instance of a struct)

Key takeaways:

• 5 differences between classes and structs: inheritance, non auto init, copies points to same data, de-init, constant classes let… can have variable properties no need for the mutating keyword on its updating functions
• use of final to prevent inheritance
• super.init required to initialise parent class
• add manual copy to create unique copies
• using deinit – no parameters

Lots of both reminders and genuinely new things learnt today!

• Properties in protocols can be finely restricted by {get set}
• Opaque return types effective in broadening applicability using the “some” keyword.
• Add String.trimmingcharacters(in: whiteSpacesAndNewLines) into a String extension
• Naming guidelines for something returning a new value: end in something like “…ed” or “…ing” eg trimmed. But if returning in place have no extended end:  eg trim
• Rationale for restriction of only addition of computed properties within protocols
• In order to retain auto init for structs, add init as an extension
• Add default implementations in extensions to protocols (I have actually used this feature before without truly appreciating what I was doing) 
• Use of Self to represent current type to return for example either an Int or a Double.

The last day covering material that I should already know…here are todays surprises!

• Can do if let number = number (ie use the same variable name – I am forever creating new names for these statements)!
• nil – sometimes I mistakenly think of null rather than nil as the value held by an empty optional
• Rationale for Swift preventing fall through option when using guard
• Can use guard without an optional….
• Dictionary default values: let new = captains[“serenity: default: “N/A”]
• try? useful when do not care about the error just success

Hurrah! At last no surprises…..

Yes very different from UIKit – key takeaways at this early stage:

• Refresh preview Option Command P
• Creating a form:
  • Forms: scrolling list of static controls like texts and images plus UI controls like textField, toggle, button
  • Section: Group related items on a form
  • NavigationBar, Navigation stack
  • Modifying state: @State as a keyword on var to enable it to automatically mutate using $ binding state to UI controls,  designed for simple properties stored in one view 

My first SwiftUI app! I enjoyed experimenting a little with some minor improvements:

• Rather than defaulting the amount to checkAmount £0.00  I set it as an optional. This saves the need to delete the initial zero value before entering.
• Rather than describe numberOfPersons as given (when in truth it is not) I set it as numberOfPersonsIndex (which is what it is) and then created a computed property called numberOfPersons which added 2 to the value. This keeps the code telling the truth for improved readability.
• I replaced the picker for selecting the number of people with a pickerStyle(.wheel). I think this is nicer.
• I added a text display for the Grand Total (including tip) as well as Each to pay. I really wanted to know what the total was including the tip.

Ah! I had anticipated some of the challenges set by Paul and made a few additional ones of my own.

• Noted that the solution to challenge 3 send you to a page that is not automatically scrolled to the selected value if it is further down the long list than one pages presentation.
• Explored the Forum for 100 days of SwiftUI to see if anyone else had raised this – they had not and I am still awaiting an answer on whether there is a way to invoke the desired behaviour.
• Noticed another post about this app that highlighted some limitation in the display management when using the currency formatter with a SwiftUI TextField and had some fun discussing different possible solutions and their respective implications.

Challenge successfully completed! – my first SwiftUI app from scratch!

These are the style of chapters I personally enjoy the most – lightening the darkness with insight and understanding.

My key takeaways:

• SwiftUI uses structs to enforce simplicity through isolating state and guaranteeing performance through reduced overhead from layers of inheritance
• There is nothing behind the body that we can / should access. The view must be specified to fill the screen if that is what we wish.
• Conceptually modifiers increment the previous view creating a view of a new type containing the previous view of the previous type. As a result the sequence of modifiers matters.
• some View saves us the overhead of precisely defining the types of the views we are creating. Under the covers, each View has a property called associatedType within it that Swift creates for us automatically.
• Use the ternary operator to create conditional modifiers on views to minimise overheads on SwiftUI. If else creates two views, ternary (syntax WTF!) creates just one
• Environment modifiers are modifiers that, when applied to a View container (a View that contains other Views), are overridden by the child Views within the containing View. Regular modifiers are not overwritten. You can apply either type of modifiers to View containers – see the documentation for which modifiers act as environment and which act as regular modifiers.
• You can create Views as properties to help structure code. These properties can be computed to include multiple views. Beware not to overdo this, it is an indicator of complexity implying the need to break things down further (see below).
• Break up complex views by creating custom Views. These are separate structs containing their own properties and body view to which the body view in the SwiftUI ContentView refers. Look to do this extensively to encapsulate and simplify.
• For greater flexibility can create own custom modifiers. These are  structs of type ViewModifer with func body(content: Content) -> some View that then enhances / extends modifies the content in some way. Add these as an extension to View for easy use with a func that calls modifer(modifierName(paras)) as required.
• Can create own custom View containers eg like VStack. These are structs of type View that take in a closure that returns an object of type Content (itself a View).

Slightly odd mixture of subjects today. Stepper, DatePicker and using dates fitted easily under a general classification of input controls and associated functions, while machine learning is just a completely different topic. I would have split the latter into its own day but then the first three would have been too short a day, so I would have added those onto a previous day.

I needed to view the video CreateML for Everyone to make sense of the Machine Learning section but having done that it certainly took some of the mystery out machine learning and I could see the potential.

TestyTimes in action

Key takeaways are

• Showing and dismissing screens: You can show and hide views as sheets by adding a sheet modifier, Use @Environment to get access to the dismiss environment function
• Saving data: Add compliance to codable to enable archive and unarchiving of structs and classes via JSONEncoder() and JSONDecoder() by try? to encode the UserDefaults.standard.set()
• deleting rows from a list: To delete items using .onDelete must be attached to ForEach
• The implications of using @State with a class is that you need to mark the class as @Observable to ensure views are redrawn when a property inside it changes.