Uncategorized - MathsTutor UK

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)!

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.

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:

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.

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).

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

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 second SwiftUI app!

Loads of new learning in these three days. It was great to get what felt like a complete app up and running and make a number of changes to it on the challenge day including a few enhancements of my own.

It made more sense to me to combine the three days into one in order to reach a logical end before posting. Here is what stood out for me over these three days:

Rationale for .leading and .trailing rather than .left and .right (how easy is it to forget that not everyone writes from left to right), so for some .leading is on the right!
Spacers: These are great vs the equivalent tools in UIKit
ZStack – brilliantly useful. SwiftUI has really made the design process so much cleaner vs UIKit.
Semantic colours. What a lovely concept.
.ignoresSafeArea
Materials – lovely effects.
Easy application of gradients to add vibrancy to the designs. I found myself compromising on designs in UIKit at times due to the associated implementation effort. I can see myself spending more time now really thinking about the design and presentation aspects without as much concern about adding in implementation overhead.
Decorative keyword to assist in accessibility. Apple have really thought this issue through.
Alerts on state…I need a bit more practice for this to feel natural.

I enjoyed identifying and implementing my own enhancements to the design and implementation as follows:

Use of .capsule with ultraThinMaterial for highlighting the flags area.
Use of descriptive nouns ie german flag vs flag of Germany in messaging
Avoidance of repetition in message and summary at bottom
Handling of error on final question to receive the Wrong …message as well as the game over / new game variation.

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.