Post

Replies

Boosts

Views

Activity

Reply to full-cover PIN screen in SwiftUI App Lifecycle?
Hi karim, Here is a simple solution, just to give you a hint. struct ContentView: View {     @Environment(\.scenePhase) private var scenePhase     @State private var coverIsPresented = false     @State private var password = ""          var body: some View {         Text("Hello, world!")             .padding()             .onChange(of: scenePhase, perform: { value in                 coverIsPresented = true             })             .fullScreenCover(isPresented: $coverIsPresented) {                 TextField("Enter Password", text: $password)                 Button("OK") {                     if password == "1234" {                         coverIsPresented = false                     }                 }             }     } }
Mar ’21
Reply to Anyone successful in moving small to medium apps to SwiftUI?
I have been experimenting with SwiftUI since day one. Unfortunately even now I would categorize it in early beta stage. Let me explain. This year I decided to update one of my apps from UIKit to SwiftUI. After two months, all I can guarantee you is that you will cry for many nights over your keyboard. And this for the following reasons: 1) Too many Views and modifiers have bugs, and you have to become an instrument ninja to understand what is causing the problem. 2) All ready-made Views are in their simplest versions, or even worse there are no matches with UIKit at all. 3) For the previous reason, it is certain that you will have to make your own custom versions, or you will have to use UIKit Views with SwiftUI wrappers. And this leads us directly to the next *huge* problem ... 4) The biggest problem of all. After programming in SwiftUI, when you go back to UIKit you feel like you went back to something old and dusty, like you went back from Swift to ObjectiveC. And that's because SwiftUI is really great, and you'll fall in love with it right away, it's just not ready yet.
Mar ’21
Reply to Saving two user data item Strings that are not lost on shutdown - how?
Hi John, Welcome to the community! In your case, User Defaults are the best option, (considering that you don't want to persist user sensitive information, like passwords) and it's the easiest way to start persisting data. You typically use it to save user preferences-options. Save Data: swift UserDefaults.standard.set(true, forKey: "loveSwift") Fetch Data: swift let data = UserDefaults.standard.bool(forKey: "loveSwift") Other ways to persist data with swift are: Storing files: Storing data on the user's file system. Keychain: The place where iOS saves all kinds of sensitive user data like usernames, passwords ect. Core Data: A framework to manage and persist objects. It is considered a difficult framework, but from my experience once you learn it you will love it. If you want to learn more about the above, as it is more complex, you may need to read lots of articles and some books, but the good thing is that Swift has a great community that will help you every step of the way! Stay safe Nikos
Feb ’21
Reply to SWIFTUI Core Data Object Return from Picker
Hey @kennedycraig, I had many problems with pickers myself, so I have good news for you, it's an easy fix. Wait for it..... ....."selection" shouldn't be optional. Yep. Thats it. Initial "selection" value, has to be one of the "player" values. I modified your code example, to give you a small hint: import SwiftUI import CoreData struct ContentView: View {     @FetchRequest private var players: FetchedResultsPlayer     @State private var selection: Player     init(moc: NSManagedObjectContext) {         let fetchRequest: NSFetchRequestPlayer = Player.fetchRequest()         fetchRequest.sortDescriptors = [NSSortDescriptor(keyPath: \Player.familyName, ascending: true)]         fetchRequest.predicate = NSPredicate(value: true)         self._players = FetchRequest(fetchRequest: fetchRequest)         do {             let firstPlayer = try moc.fetch(fetchRequest)             self._selection = State(initialValue: firstPlayer[0])         } catch {             fatalError("Uh, fetch problem...")         }     }     var body: some View {         VStack{             Picker("", selection: $selection){                 ForEach(players) { (player: Player) in                     Text(player.givenName ?? "")                         .tag(player)                 }             }             Text(selection.familyName ?? "No family name")             Text("\(players.count)")         }     } } Hope I helped, Stay safe! Nikos
Feb ’21
Reply to Migration of local core data to iCloud core data
No, unfortunately if you hadn't set true for key NSPersistentHistoryTrackingKey, they will never get it to cloud, they will stay only in your device. A workaround that I used and worked fine, is to add a property to all entities (I used "cloudReady: Bool", and at the first run of the app, after you adopt NSPersistentCloudKitContainer, change that property to "true" for all entities. This will force iCloud to sync those objects.
Jun ’20
Reply to Cloudkit and CoreData Sync memory issue with image Data.
I have exactly the same problem, I use NSPersistentCloudKitContainer with Catalyst. The problem started after I deployed the Schema to production.The synchronization works perfectly on all devices (mac, iPhone, Simulator) until I add a photo from Simulator. This photo is synchronized with Mac, but as soon as it tries to sync with iPhone, it crashes. The only way I found not to crash, is to delete as many photos as I had added from Simulator. After that, iPhone crashes stops and starts syncing again.EDIT:I've found that the problem is not from the simulator but from a big image.I tried that using a 8k image and it crashed.If I deselect the "Allow External Storage" option though, it works fine.
Apr ’20