Author: root
A Gory Detail For Xcode Test Targets
Somehow, I’ve gone for years without being aware of this setting in the Test Targets used in Xcode projects. Apologies if this has been obvious to everyone on Earth other than me.
A Tangentially related background story, that enabled me to discover this setting
In my flash cards app, I needed logic to figure out which cards could be used for a given user’s ask/answer languages setting. For example, if a user wants to always use Korean as their ask language, and all other languages available as answer languages, then only cards that included Korean and at least one other language could be presented.
Also, bear in mind that for languages that have roman and non-roman script versions, they need to be treated as two separate languages, only one of which is relevant, depending on which the user has selected in Settings.
My first pass at the logic to pick the next card erred on the side of simple, rather than safe. It used the following process:
- Select the ask language (randomly if the user’s preference specifies multiple ask languages)
- Determine an answer languages list (again shuffle them randomly if there is more than 1 answer language)
- Find the list of words matching the ask language and the answer languages (a bug here was returning an empty word list when I specified a single answer language and there were no words yet with that language)
- Pick a word from the list
- Calculate the intersection of available languages for the word and answer language(s) specified by the user
- Return an object containing the wordId, the askLanguage and the array of answerLanguages
As I mention in the list, there is a bug in step 3 that can cause a crash later in the process. (Better would be to say at the get go, something like: ‘I don’t have any words that match your languages choices’
Also, the above has a highly buried dependency on the user’s setting/pref on whether they want to use the roman version or the non-roman version of languages that have their own special script/alphabets.
So (we’re getting VERY close to the topic of this post) I am currently in the process of improving this process by pulling the user setting dependency out (or at least make it injectable when testing.)
The Point
So I wrote a test, and attempted to run it. But when I ran my single test, with its shiny new injected dependency it never ran, because Xcode first insisted on running my main app, which of course was still crashing when attempting to use the old/broken logic for picking a card.
Thanks to a great answer from the ever helpful Quinn, I was able to discover this setting in Xcode.
Once I set it to None
, I was able to run my stand alone test, and resume creating my improved card picking logic.
Flipping #*&$%@! Cards with SwiftUI
Despite the salty title this was a very low stress investigation. I wanted to find a way to use animation to flip my flash cards. There are many great sources to do something like this:
struct ContentView: View {
@State var angle: CGFloat = 0
var body: some View {
VStack {
Text("contentText: frontText")
.padding(40)
.background(.green)
.rotation3DEffect(.degrees(angle), axis: (x: 0.0, y: 1.0, z: 0.0))
.animation(.default, value: angle)
Button("Flip") {
angle += 180
}
}
}
}
Tapping the button in the above app will flip the card, and show an empty green rectangle. So how would I go about showing different (dynamic) content on the ‘back’ of the card? The idea I’m currently going with is to create a front content view and a back contentView. The back contentView begins pre-rotated, so that when the parent view gets rotated it ends up being the correct orientation,
VStack {
ZStack {
FlippableContent(contentText: frontText)
FlippableContent(contentText: rearText)
.rotation3DEffect(
.degrees(180), axis: axis)
}
.rotation3DEffect(.degrees(angle), axis: axis)
.animation(.default, value: angle)
Button("Flip") {
angle += 180
}
}
...
struct FlippableContent: View {
let contentText: String
var body: some View {
VStack {
Text(contentText)
}
.frame(width: 300, height: 250)
.background(.green)
}
}
This is close, but not quite right. It always only ever shows the FlippableContent view showing rearText (sometimes forwards, sometimes reverse). I experimented with different angles on the FlippableContents, however I’m not entirely clear on exactly how multiple 3d rotation effects get combined. Not my circus, not my monkeys I guess. Tho I’m definitely a bit curious…
To fix my problem, I’ve created logic that creates different opacity values for the front and back content of the card.
extension CGFloat {
var rearOpacity: CGFloat {
return (self / 180).truncatingRemainder(dividingBy: 2)
}
var frontOpacity: CGFloat {
return 1 - rearOpacity
}
}
And these new functions get used in opacity modifiers in the ZStack.
ZStack {
FlippableContent(contentText: frontText)
.opacity(angle.frontOpacity)
FlippableContent(contentText: rearText)
.rotation3DEffect(
.degrees(180), axis: axis)
.opacity(angle.rearOpacity)
}
Now the view gets initialized with angle at zero, which shows the front text. When the user flips the card, angle gets increased by 180 degrees. This animates through the rotation, and hides the front face, and shows the rear face. On the next flip, the rear face gets hidden and the front face gets shown.
AppStorage part 2
Turns out this topic needs more than just one post. In part 1, I described how I was able to use AppStorage for an enum with associated values.
Here I will discuss a challenge I encountered when attempting to build the View to enable users to change their value for the languageChoice enum.
enum LanguageChoice: Equatable, Codable {
case all
case oneToOne(Language, Language)
case oneToAll(Language)
case allToOne(Language)
case symmetricSubset(Set<Language>)
Step 1, create a version of LanguageChoice with no associated values:
enum SimpleLanguageChoice: String, CaseIterable {
case all
case oneToOne
case oneToAll
case allToOne
case symmetricSubset
}
Step 2, create a state variable using the new enum type and bind it to a picker:
@State var languageChoice: SimpleLanguageChoice = .all
var body: some View {
VStack {
Picker("Languages Choice", selection: $languageChoice) {
ForEach(SimpleLanguageChoice.allCases, id: \.self) {
Text($0.rawValue)
.tag($0)
}
}
}
}
Step 3, add UI below the picker to display the appropriate controls to go with the value of languageChoice.
@ViewBuilder var bottomStuff: some View {
switch languageChoice {
case .all:
EmptyView()
case .oneToAll:
Picker("Ask in", selection: $language) {
ForEach(Language.allCases, id: \.self) {
Text($0.rawValue)
.tag($0)
}
}
// et cetera
Step 4, add an AppStorage var to get the persisted LanguageChoice value and use it to configure the Picker UI.
@AppStorage("languageChoice") var persistedLanguageChoice: LanguageChoice = .all
@State var languageChoice: SimpleLanguageChoice
init() {
languageChoice = SimpleLanguageChoice.simpleChoice(for: persistedLanguageChoice)
}
Insert record scratch sound here! This code created the following compiler error:'self' used before all stored properties are initialized
I wanted to use the persisted languageChoice to set up the UI to allow users to choose a new languageChoice. But doing this required reading persisted languageChoice, which was not allowed. Alas. So to get things to work I needed to set a default value for languageChoice in the declaration and then update the value in init. Just do this, right?
@State var languageChoice: SimpleLanguageChoice = .all
init() {
languageChoice = SimpleLanguageChoice.simpleChoice(for: persistedLanguageChoice)
Nope. If you set an initial value for a State variable in the declaration, updating it in init gets more complicated. You need to do this:
init() {
_languageChoice = State(initialValue: SimpleLanguageChoice.simpleChoice(for: persistedLanguageChoice)
SwiftUI AppStorage wrinkles
The SwiftUI property wrapper AppStorage
is a great way to cut down on boiler plate code needed to manage/access UserDefaults. At the risk of sounding like I’m looking a gift horse in the mouth, I feel compelled to describe a couple of challenges I encountered while using AppStorage
in my current project, the language flash cards app.
AppStorage for enums with associated values
The type I wanted to persist using AppStorage
was a fairly gnarly enum with a variety of associated values. It is the value that persists the users preferences for languages to use for asking and answering. See this blog post for more details on how this enum came to be.
enum LanguageChoice: Equatable, Codable {
case all
case oneToOne(Language, Language)
case oneToAll(Language)
case allToOne(Language)
case symmetricSubset(Set<Language>)
}
Out of the box, AppStorage only works with the most basic of types. (Int, String, Bool, etc.) There are several great resources on how to extend AppStorage
support to basic structs. If you google “AppStorage RawRepresentable” you’ll be away to the races in no time. The tl;dr version is: implement public init?(rawValue: String)
andpublic var rawValue: String
My first inclination was to use JSONDecoder()
in init
and JSONEncoder()
in rawValue
. Unfortunately JSONEncoder()
was calling rawValue
, which was calling JSONEncoder()
etc.
So instead I defined a custom scheme to encode (and decode) the LanguageChoice enum
. This required a fair bit of custom code (see below) and allowed LanguageChoice
to work with @AppStorage
. But I wasn’t out of the woods yet. There was still more work to be done, which I’ll describe in a future post.
Here is how I chose to conform to RawRepresentable
.
public init?(rawValue: String) {
let components = rawValue.components(separatedBy: ":")
guard let first = components.first else {
return nil
}
switch first {
case "all":
self = .all
case "oneToOne":
guard components.indices.contains(2),
let lang1 = Language.init(rawValue: components[1]),
let lang2 = Language.init(rawValue: components[2]) else {
return nil
}
self = .oneToOne(lang1, lang2)
case "oneToAll":
guard components.indices.contains(1),
let lang = Language.init(rawValue: components[1]) else {
return nil
}
self = .oneToAll(lang)
case "allToOne":
guard components.indices.contains(1),
let lang = Language.init(rawValue: components[1]) else {
return nil
}
self = .allToOne(lang)
case "symmetricSubset":
guard components.indices.contains(1) else {
return nil
}
let languageComponents = components[1].components(separatedBy: ",")
let languages: Set<Language> = Set(languageComponents.compactMap { Language(rawValue: $0) } )
self = .symmetricSubset(languages)
default:
return nil
}
}
public var rawValue: String {
let data = try? JSONEncoder().encode(self)
print("data: \(data)")
let result: String
switch self {
case .all:
result = "all"
case .oneToOne(let language, let language2):
result = "oneToOne:\(language.rawValue):\(language2.rawValue)"
case .oneToAll(let language):
result = "oneToAll:\(language.rawValue)"
case .allToOne(let language):
result = "allToOne:\(language.rawValue)"
case .symmetricSubset(let set):
let setRawValue = set.sorted().reduce("") {
$0 + $1.rawValue + ","
}
result = "symmetricSubset:\(setRawValue)"
}
return result
}
Unit tests for this code have been left as an exercise for the student.
Binding to a Dictionary
SwiftUI is mostly awesome, but sometimes in the corners things get a bit messy. In my recent work on the multi-lingual flash cards app, I encountered one such corner.
I am planning to include languages that use writing systems other than the good ol’ Western Alphabet. These include:
- ਜਪਾਨੀ (Japanese)
- 旁遮普语 (Punjabi)
- китайський (Chinese)
- ウクライナ語 (Ukrainian)
Just for fun, the above list is: Japanese (in Punjabi), Punjabi (in Chinese), Chinese (in Ukrainian), and Ukrainian (in Japanese)
When using the app, I want to give users the choice to see these words in their native script or in the ‘Roman’ alphabet. But I didn’t immediately how to implement this ‘feature.’
I saw two challenges:
- How to store the differently scripted versions of the same language
- How to map user preferences to the list of languages to use when quizzing users.
Problem #1: Storing the Languages
I ended up creating multiple localizations for each languages. For Japanese I used ‘ja’ and ‘ja-JP.’ The ‘ja’ localization stores the kana (and possibly kanji) version of the flash card content. The ‘ja-JP’ localization stores the romaji version of the content.
To be honest, I don’t LOVE this implementation option, but I really didn’t see anything better. Try not to judge me too harshly!
Problem #2: Mapping the user preferences to the languages list
Thanks to my solution to problem #1, the internal list of available languages will now look something like: en, fr, ja, ja-JP. But we never want to show users this list. Instead we will want to show them either ja or ja-JP. Depending on a user’s preferences, their language list will either be: en, fr, ja OR en, fr, ja-JP.
For each language with local script or western/roman alphabet options, the user will set a bool preference value. The bool preference values will be used to create a set of excluded languages. Here is the logic for the case where Japanese is the only multi-script language.
var scriptExcludedLanguages: [Language] {
let ja: Language = useNativeScript ? .ja_roman : .ja_nonRoman
return [ja]
}
The app can then remove the scriptExcludedLanguages to generate the list of languages available to the current user with the following code:
var allLanguages: Set<Language> {
let result = Language.allLanguages.subtracting(scriptExcludedLanguages)
return result
}
In the course of implementing this feature, I uncovered one other piece that ended up being non-obvious.
Problem #3 Binding the UI and UserDefaults for the Dictionary of Bools
First I defined the type: typealias ScriptPickers = [String: Bool]
And then in the picker view added the following AppStorage property: @AppStorage("scriptPickers") var scriptPickers: ScriptPickers = ScriptPickers.defaultDictionary
This lead to the following cryptic compiler error:No exact matches in call to initializer
It turned out the fix for this was to make ScriptPickers conform to RawRepresentable
. Here’s what that looks like:
extension ScriptPickers: RawRepresentable where Key == String, Value == Bool {
public init?(rawValue: String) {
guard let data = rawValue.data(using: .utf8),
let result = try? JSONDecoder().decode(ScriptPickers.self, from: data)
else {
return nil
}
self = result
}
public var rawValue: String {
guard let data = try? JSONEncoder().encode(self),
let result = String(data: data, encoding: .utf8)
else {
return "{}" // empty Dictionary respresented as String
}
return result
}
}
// hat tip: actw https://stackoverflow.com/questions/65382590/how-to-use-appstorage-for-a-dictionary-of-strings-string-string
But there was still the need to map the UI toggles to the ScriptPickers dictionary. Each language toggle needs a binding to the corresponding entry in dictionary. Here is the basic structure for doing that.
struct ContentView: View {
@AppStorage("scriptPickers") var scriptPickers: ScriptPickers = ScriptPickers.defaultDictionary
var body: some View {
VStack {
ForEach(scriptPickers.keys.sorted(), id: \.self) { key in
Toggle(key, isOn: binding(for: key))
}
}
.padding()
}
private func binding(for key: String) -> Binding<Bool> {
return .init(
get: { self.scriptPickers[key, default: false] },
set: { self.scriptPickers[key] = $0 })
}
}
I am no noticing that some languages don’t just have roman and non-roman options. Punjabi for example can be expressed in Gurmukhi, Shamukhi, and the roman alphabet. Japanese can be expressed in Kanji (pictograms), Kana (non-Roman alphabets), and Romaji (using the Roman alphabet.)
So in the future, it feels like this code may need to be extended. Also, it feels like the languages should be expressed as an enum, rather than as strings.
(Not a book by JK Rowling, tho I’m sure many people would purchase and read Harry Potter and the Codable Protocol)
I’m working on a project where I need to write code to convert the following JSON
into a structure:
{ "en" : { "stringUnit" : {
"state" : "translated",
"value" : "Cat" } },
"fr" : { "stringUnit" : {
"state" : "translated",
"value" : "Chat" } },
"ja" : { "stringUnit" : {
"state" : "translated",
"value" : "ねこ" } }
}
To accomplish this, I created the following model objects:
typealias LocalizationsDict = [String: Localization]
struct Localization: Codable, Equatable {
let stringUnit: StringUnit
}
struct StringUnit: Codable, Equatable {
let state: String
let value: String
}
The code to decode a LocalizationsDict
looked like this:
let languages: LocalizationsDict = try JSONDecoder().decode(LocalizationsDict.self, from: data)
Everything was working wonderfully. But then I got greedy. (queue the jump scare music.) I wanted to see if the keys could be an enum
, instead of a String
. I felt this would make the code safer, and would mean languages could be types using autocomplete. (The jury may still be out on whether necessity or laziness is truly the mother of invention.)
Here was the code needed to create the Language enum
:
enum Language: String, Codable {
case en = "en"
case fr = "fr"
case ja = "ja"
}
Unfortunately…in order for a Swift dictionary to conform to Codable
, its key type must be either String
or Int
. For a Swift dictionary with any other type of key, decode will assume the JSON
will be represented as an array, where the first item is the first key, the second item is the first value, third item is the second key, etc.
Thank you Apple Dev forums, yet again. https://developer.apple.com/forums/thread/747665
This would mean the JSON
would need to be stored like this:
[ "en", { "stringUnit" : {
"state" : "translated",
"value" : "Cat" } },
"fr", { "stringUnit" : {
"state" : "translated",
"value" : "Chat" } },
"ja", { "stringUnit" : {
"state" : "translated",
"value" : "ねこ" } }
}
Sadly, in this situation, the JSON
was being generated by the metaphorical ‘somebody else’ and I didn’t have the option to change the format of my incoming JSON
.
Instead I added a step when decoding this type of Dictionary. Here’s a code snippet:
typealias LocalizationsDict = [Language: Localization]
typealias LocalizationsDict2 = [String: Localization]
init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: CodingKeys.self)
let stringKeyedLocalizations = try container.decode(LocalizationsDict2.self, forKey: .localizations)
var enumKeyedLocalizations: LocalizationsDict = [:]
for (key, value) in stringKeyedLocalizations {
if let enumKey = Language(rawValue: key) {
enumKeyedLocalizations[enumKey] = value
}
}
self.localizations = enumKeyedLocalizations
}
The details of what’s happening are as follows:
- Decode the
JSON
to a[String: Localization]
dictionary - Create an empty
[Language: Localization]
dictionary - Iterate through the
[String: Localization]
dictionary - For each entry, verify it’s possible to create a valid enum value from the language string. (eg map
"en"
toLanguage.en
- For each entry store the value in the
[Language: Localization]
dictionary, using theenum
key generated in the previous step.
This works, but I thought this seemed like an interesting shortcoming in Swift.
Zoom Burst Instructions
Here are my instructions for how to open Zoom Burst. (or any iOS Photo Editing Extension)
In order to effectively use Zoom Burst, you should understand the principles behind the app. Zoom Burst starts with the original photo serving as the base layer of a composition. It also allows you to make the following adjustments:
- Select the blend mode used to compose the layers in the composition (CIColorDodgeBlendMode works best for night photographs)
- Specify the amount of scaling used. This determines how much the lights expand or pop.
- Specify the amount of rotation used.
- Adjust the number of layers. This reduces the gaps between the steps.
Or if you’d prefer, here’s a video of Zoom Burst in action.
You can download Zoom Burst from the App Store.