Im creating a game using SpriteKit but I’m not using sks files fore levels. I don’t to enter in details about the idea of the game before I release it but basically each level is auto generated based on a few numbers. So essentially what defines a level would be these numbers I would like to know where I could store this numbers. If I used sks files I would just have a file per level but in this case should I have them sorted in an array of levels? Should the array be in the level selection viewcontroller ? Should it be in a singleton class?
Basically what would be a good way to go about storing these values?
So the levels are auto-generated at runtime?
You could use an array of levels, or a file per level. I would just write them to one or more files in your app's documents directory. (I'd probably use one file per level, just to keep it simple and make it so you can easily add more levels without rewriting the whole game layout file each time.)
If you build your level structures out of scalar types, arrays, and dictionaries, (property list objects) then you can write the "object graph" to a property list using the NSArray or NSDictionary method write(to:).
Alternately you could make your level object conform to the Codable protocol, convert it to JSON, and save the JSON data to a file. The Codable protocol is easy to use, it's well documented by Apple, and there are tons of tutorials online.
EDIT
Note that you could also write your data to a property list using the Codable protocol. Just like the JSONEncoder and JSONDecoder classes, there are PropertyListEncoder and PropertyListDecoder classes that will convert your object graph back and forth to property list format. (Binary properties lists are more compact and faster to read and write than JSON.)
Below is a sample playground that defines a custom struct FooStruct, makes it Codable, and then uses a PropertyListEncoder to write the data to the playground's shared data directory (which you will have to set up if you want to test this code)
import UIKit
import PlaygroundSupport
struct FooStruct: Codable {
let aString: String
let anotherString: String
let anInt: Int
}
let fooArray: [FooStruct] = [FooStruct(aString: "Foo 1",
anotherString: "String 1", anInt: 4),
FooStruct(aString: "Foo 2",
anotherString: "String 2", anInt: 7)
]
let encoder = PropertyListEncoder()
encoder.outputFormat = .binary
do {
print(fooArray)
let data = try encoder.encode(fooArray)
let plistURL = playgroundSharedDataDirectory.appendingPathComponent("property list.plist")
try data.write(to: plistURL)
print("Data written to \(plistURL.path)")
} catch {
print (error)
}
Related
What's the difference between using JSONSerialization and JSONDecoder in swift, while converting JSON to a swift model? It's seems like they are doing the same job. If they do, then when is which to use?
Thank you in advance
Apple has provided JSONDecoder which is a huge relief in swift4 and onwards. We can decode json in just one line. eg
{// sample from quicktype app online
"greeting": "Welcome to quicktype!",
"instructions": [
"Type or paste JSON here",
"Or choose a sample above",
"quicktype will generate code in your",
"chosen language to parse the sample data"
]
}
// MARK: - Welcome
struct Welcome: Codable {
let greeting: String
let instructions: [String]
}
// let welcome = try? newJSONDecoder().decode(Welcome.self, from: jsonData)
Here welcome is the struct which is conforming to codable protocol.
If you want to parse JSON by hand rather than using Codable, iOS has a built-in alternative called JSONSerialization.But i think everybody would like to use JSONDecoder. And also quicktype creates json model classes or struct for u for free.
Check yourself.
Use JSONDecoder !
If I remember well, JSONDecoder appeared in Xcode 9, with Swift4.
It's cleaner and much more efficient to encode and decode JSON.
To do so, your Swift Class has to conform to Decodable Protocol.
JSON Serialization is the Old School. (Like Objective-C)
I am in the beginning stages of developing an open-source utility for storing state in the Bundle UserDefaults.
I'm encountering an issue when I add non-Codable data types to my Dictionary of [String: Any].
I need to be able to vet the data before trying to submit it, because the UserDefaults.set(_:) method won't throw any errors. It just crashes.
So I want to make sure that the Dictionary that I'm submitting is kosher.
I can't just check if it's Codable, because it can sometimes say that it isn't, when the struct is actually good. (It's a Dictionary<String, Any>, and I can cram all kinds of things in there).
I need to validate that the Dictionary can produce a plist. If this were ObjC, I might use one of the NSPropertyListSerialization methods to test the Dictionary, but it appears as if this set of methods is not available to Swift.
According to the UserDefaults docs, there are a specific set of types and classes that are "plist-studly."
I think testing each type in the list is unacceptable. I need to see if I can find a way to test that won't be screwed the first time Apple updates an OS.
Is there a good way to test a Dictionary<String, Any> to see if it will make UserDefaults.set(_:) puke?
The Property List type set of UserDefaults is very limited. The supported types are
NSString → Swift String
NSNumber → Swift Int, Double or Bool
NSDate → Swift Date
NSData → Swift Data
Arrays and dictionaries containing the 4 value types.
Any is not supported unless it represents one of the 4 value or 2 collection types.
Property List compliant collection types can be written to UserDefaults with PropertyListSerialization (even in Swift).
There are two protocols to serialize custom types to Data
Codable can serialize structs and classes.
NSCoding can serialize subclasses of NSObject.
All types in the structs/classes must be encodable and decodable (means conform to the protocol themselves).
The APIs of PropertyListSerialization / PropertyListEncoder/-Decoder and NSKeyed(Un)Archiver provide robust error handling to avoid crashes.
UPDATE[1]: And, just because I like to share, here's the actual completed project (MIT License, as is most of my stuff)
UPDATE: This is the solution I came up with. Even though I greenchecked vadian's excellent answer, I decided to get a bit more picky.
Thanks to matt pointing out that I was looking under the wrong sofa cushions for the keys, I found the Swift variant of NSPropertyListSerialization, and I use that to vet the top level of the tree. I suspect that I'll need to refactor it into a recursive crawler before I'm done, but this works for now.
Here's the code for the _save() method at the time of this writing. It works:
/* ################################################################## */
/**
This is a private method that saves the current contents of the _values Dictionary to persistent storage, keyed by the value of the "key" property.
- throws: An error, if the values are not all codable.
*/
private func _save() throws {
#if DEBUG
print("Saving Prefs: \(String(describing: _values))")
#endif
// What we do here, is "scrub" the values of anything that was added against what is expected.
var temporaryDict: [String: Any] = [:]
keys.forEach {
temporaryDict[$0] = _values[$0]
}
_values = temporaryDict
if PropertyListSerialization.propertyList(_values, isValidFor: .xml) {
UserDefaults.standard.set(_values, forKey: key)
} else {
#if DEBUG
print("Attempt to set non-codable values!")
#endif
// What we do here, is look through our values list, and record the keys of the elements that are not considered Codable. We return those in the error that we throw.
var valueElementList: [String] = []
_values.forEach {
if PropertyListSerialization.propertyList($0.value, isValidFor: .xml) {
#if DEBUG
print("\($0.key) is OK")
#endif
} else {
#if DEBUG
print("\($0.key) is not Codable")
#endif
valueElementList.append($0.key)
}
}
throw PrefsError.valuesNotCodable(invalidElements: valueElementList)
}
}
I'm writing an app on iOS using Swift 3 and I'm quite new to programming.
The app mimics a farm where the user can manage plants.
I'm looking for an elegant-solid way to store a quite big number of objects that will never change in the course of the application (descriptions texts, number representing the growing time of a plant, etc.).
At the moment I'm storing the informations of each plant in a dictionary where for each entry the key is a code of the plant("0","1", and so on), and the value is another dictionary where the key (I used an enum "librarySelection") represents the type of data ("description","growingTime", etc.) and the value is of type AnyObject.
For example:
struct Plants {
static let library: [String: [librarySelection: AnyObject]] = [
"0":[
.description: "description1" as AnyObject,
.image: "image1.pdf" as AnyObject,
.growingTime: 10 as AnyObject,
],
"1":[
.description: "description2" as AnyObject,
.image: "image2.pdf" as AnyObject,
.growingTime: 20 as AnyObject,
]
]
}
This doesn't feel very handy. I looked around if there was someway to use CoreData and maybe create a pre-populated database to include with my app but that doesn't feel like the correct way either.
I'm sorry for my poor english.
I am putting together a program that reads the sensors within a cell phone and saves the sensor data to a core-data SQLite model, with each set of readings pertaining to a particular session
The program provides the user with the option to email a .csv file of a particular session.
Having never done this before, I approached the issue by initializing a delegate and context, and searching the core data for entities that pertain to a specified session. The entities that satisfy the session attribute then have their data fields (gps, mag, accel, gyro) read and put into a string. Then the string is appended to an array. All done in swift.
After the entities are searched and the array is created, I attempt to create a csv file for attachment to an email. The file is attached successfully, but my encoding technique is presenting additional data prepended and appended to the file.
I want to save a file on the phone and email a copy to the user.
Here is what I have to change the Array to NSArray before converting again to NSData:
let paths: NSArray = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true);
let path = paths[0].stringByAppendingPathComponent("SessionData.csv")
if !NSFileManager.defaultManager().fileExistsAtPath(path)
{
NSFileManager.defaultManager().createFileAtPath(path, contents: nil, attributes: nil)
}
else
{
NSFileManager.defaultManager().createFileAtPath(path, contents: nil, attributes: nil)
}
var handle: NSFileHandle = NSFileHandle(forWritingAtPath: path)
handle.truncateFileAtOffset(handle.seekToEndOfFile())
var arrayToWriteNS = (arrayToWrite as NSArray)
var dataNS: NSData = NSKeyedArchiver.archivedDataWithRootObject(arrayToWrite as NSArray)
handle.writeData(dataNS)
mc.setSubject(emailTitle)
mc.addAttachmentData(dataNS, mimeType: "text/csv", fileName: "SessionData.csv")
Here is the prepended and appended data:
bplist00‘()T$topX$objectsX$versionY$archiver—TrootĨ
!U$null“
V$classZNS.objectsÄ©ÄÄÄÄÄÄÄÄ Ä
"My Data"
“"#$'X$classesZ$classname¢%&WNSArrayXNSObjectWNSArray܆_NSKeyedArchiver(25:<IOT[fhrtvxz|~ÄÇÑ·Ø}KÁµÉQV_jmu~Üã*ù
In a large data session with 28,000 entities there may be ~750 lines of prepended data.
Any help that you can provide would be appreciated.
I'm new to iOS, Obj-C, and swift, thus I'm positive there is a better way to do this, I just haven't discovered a better method yet.
Thank you.
UPDATE: Ended up just using the NSString data encoding and writing to my file in increments:
handle.truncateFileAtOffset(handle.seekToEndOfFile())
var stringToWriteNS = (stringToWrite as NSString).dataUsingEncoding(NSUTF8StringEncoding)
handle.writeData(stringToWriteNS!)
You do not want NSKeyedArchiver, it is for archiving and restoring classes.
You need to go through the array and create a text representation of each item in a format you what to present to the user.
A quick search of CocoaPods reveals several projects that may fit you needs to generate csv format data.
This one might be what you need.
csv is fairly simple so it would be reasonable to format your data to csv by writing your own code.
With the introduction of Swift I've been trying to get my head round the new language
I'm an iOS developer and would use types such as NSString, NSInteger, NSDictionary in an application. I've noticed that in the "The Swift Programming Language" ebook by Apple, they use the Swift types String, Int, Dictionary
I've noticed the Swift types don't have (or are differently named) some of the functions that the Foundation types do. For example NSString has a length property. But I've not been able to find a similar one for the Swift String.
I'm wondering, for an iOS application should I still be using the Foundation types?
You should use the Swift native types whenever possible. The language is optimized to use them, and most of the functionality is bridged between the native types and the Foundation types.
While String and NSString are mostly interchangeable, i.e, you can pass String variables into methods that take NSString parameters and vice versa, some methods seem to not be automatically bridged as of this moment. See this answer for a discussion on how to get the a String's length and this answer for a discussion on using containsString() to check for substrings. (Disclaimer: I'm the author for both of these answers)
I haven't fully explored other data types, but I assume some version of what was stated above will also hold true for Array/NSArray, Dictionary/NSDictionary, and the various number types in Swift and NSNumber
Whenever you need to use one of the Foundation types, you can either use them to type variables/constants explicitly, as in var str: NSString = "An NSString" or use bridgeToObjectiveC() on an existing variable/constant of a Swift type, as in str.bridgeToObjectiveC().length for example. You can also cast a String to an NSString by using str as NSString.
However, the necessity for these techniques to explicitly use the Foundation types, or at least some of them, may be obsolete in the future, since from what is stated in the language reference, the String/NSString bridge, for example, should be completely seamless.
For a thorough discussion on the subject, refer to Using Swift with Cocoa and Objective-C: Working with Cocoa Data Types
NSString : Creates objects that resides in heap and always passed by reference.
String: Its a value type whenever we pass it , its passed by value.
like Struct and Enum, String itself a Struct in Swift.
public struct String {
// string implementation
}
But copy is not created when you pass. It creates copy when you first mutate it.
String is automatically bridged to Objective-C as NSString. If the Swift Standard Library does not have, you need import the Foundation framework to get access to methods defined by NSString.
Swift String is very powerful it has plethora of inbuilt functions.
Initialisation on String:
var emptyString = "" // Empty (Mutable)
let anotherString = String() // empty String immutable
let a = String(false) // from boolean: "false"
let d = String(5.999) // " Double "5.99"
let e = String(555) // " Int "555"
// New in Swift 4.2
let hexString = String(278, radix: 18, uppercase: true) // "F8"
create String from repeating values:
let repeatingString = String(repeating:"123", count:2) // "123123"
In Swift 4 -> Strings Are Collection Of Characters:
Now String is capable of performing all operations which anyone can
perform on Collection type.
For more information please refer apple documents.
Your best bet is to use Swift native types and classes, as some others have noted NSString has toll free translation to String, however, they're not the same a 100%, take for example the following
var nsstring: NSString = "\U0001F496"
var string: String = "\U0001F496"
nsstring.length
count(string)
you need to use the method count() to count the characters in string, also note that nsstring.length returns 2, because it counts its length based on UTF16.
Similar, YES
The same, NO
String and NSString are interchangeable, so it doesn't really matter which one you use. You can always cast between the two, using
let s = "hello" as NSString
or even
let s: NSString = "hello"
NSInteger is just an alias for an int or a long (depending on the architecture), so I'd just use Int.
NSDictionary is a different matter, since Dictionary is a completely separate implementation.
In general I'd stick to swift types whenever possibile and you can always convert between the two at need, using the bridgeToObjectiveC() method provided by swift classes.
Swift 4 update
String gets revisions in swift 4. Now you can directly call count on it and it consider grapheme clusters as 1 piece, like an emoji. NSString is not updated and is counting it in another way.
var nsstring: NSString = "👩👩👧👦"
var string: String = "👩👩👧👦"
print(nsstring.length) // 11
print(string.count) // 1
Since the objective C types are still dynamically dispatched they're probably going to be slower. I'd say you're best served using the Swift native types unless you need to interact with objective-c APIs
Use the Swift native types whenever you can. In the case of String, however, you have "seamless" access to all the NSString methods like this:
var greeting = "Hello!"
var len = (greeting as NSString).length
Swift Strings are quite elegant and easy to use, unless you need to parse them. The whole concept of indexing into Swift strings is just plain crazy. Whenever I need to parse through a typical unicode string, I convert it to NSString. Swift makes this a bit tricky though in that the common "character" integer expressions like ' ' or 'A' or '0' don't work in Swift. You have to use 32, 65, 48. Unfortunately, I'm not kidding! Because of this, I've put most of my string parsing code into an NSString extension written in Objective-C.
Yes I do know WHY Swift's designers made String indexing so crazy: They wanted to be able to express many-byte characters like emoji as single "Characters". My choice would have been to let this rare use case be expressed as multiple UTF16 characters, but what the heck.
String is a struct
// in Swift Module
public struct String
{
}
NSString is a class
// in Foundation Module
open class NSString : NSObject
{
}