|
prom candy posted:So is it cool and good to just chuck this class underneath my ViewController class in the same file? I know in some languages that's not all that popular but it does seem like Xcode makes it a little easier to navigate long files. The more languages I learn the more I find I want to learn the the sort of style/housekeeping practices early on but a lot of tutorials don't really focus on that. The guy who started this project also uses 4 spaces for indenting so I'm suspicious about how much I want to trust his way of doing stuff (while obviously still trying to maintain consistency in the project) It's just a style thing. Some people wanna stuff everything into a single main.swift, other people are allergic to files that don't fit on their monitor. Personally I don't enjoy having to change seventeen different files just to rework a single screen, but whatever works. In this example I'd probably do something like code:
|
# ? Nov 21, 2020 20:12 |
|
|
# ? Jun 8, 2024 09:03 |
|
Okay great, thanks! I'm probably going to be a pest in this thread while I get a handle on some of this stuff. Swift is a cool language though, I like it so far. I worked in an iOS app back in 2010 or so and that really turned me off of wanting to work on any more, but it seems like it's way nicer now.
|
# ? Nov 21, 2020 21:26 |
|
I think one of the biggest things I’ve taken away after gaining some experience is that figuring out the right way to break your code up across files is not nearly as important as becoming very fluent in your IDE’s commands for code navigation.
|
# ? Nov 21, 2020 22:35 |
|
Uhg learning new things and practicing is never not frustrating . I’m trying to learn Swift UI and things that that would take two seconds to set up with Autolayout in Interface Builder feel impossible in SwiftUI. Like im trying to place 4 small (10by10) square views in a parent view, one in each corner. This would be incredibly trivial in IB but feels impossible in SwiftUI. I’ve tried using a z stack and aligning the sub views inside but this just causes the z stack to collapse down (basically shrink wrap) the 4 sub views. (Also .overlay() feels weird for using parentheses instead of curly braces). The visual editor doesn’t feel very helpful because I have to just hunt through a list for the various modifiers or view types and I end up doing it mostly in code. The IB XML merge nightmare is gone but now view files are cluttered with stylizing code. Sorry just needed to vent. The start of learning new things is always the most painful.
|
# ? Nov 21, 2020 23:05 |
|
Pulcinella posted:Sorry just needed to vent. The start of learning new things is always the most painful. Yeah one day I realized that doing all my layout in code means not having to go through growing pains every time the latest UI toolset comes along.
|
# ? Nov 21, 2020 23:15 |
|
Pulcinella posted:Uhg learning new things and practicing is never not frustrating . Something like? code:
|
# ? Nov 22, 2020 01:47 |
|
brand engager posted:Something like? This works if you're statically sizing the views but if they're dynamic then you're going to run into issues as Spacer() will only fill empty space.
|
# ? Nov 22, 2020 20:34 |
|
what do you mean statically sizing
|
# ? Nov 22, 2020 21:28 |
|
I think something like: code:
SwiftUI views set their own size and can override their parent view’s suggestion though. It’s definitely awkward trying to do anything that can’t be easily expressed as a stack view, which is a lot, but not everything. We aren’t going to switch to SwiftUI any time soon at work (most clients still want to support back to iOS12 with some even earlier), but we still don’t know how we are going to tell our designers that we don’t know if a lot of their designs are going to work in the future. I do like just being able to apply a gaussian blur to a view. Wish Apple would let us apply CIFilters to a CALayer on iOS (you can on macOS but on iOS the filters property in CALayer does nothing.)
|
# ? Nov 23, 2020 03:57 |
|
So I'm building this subclass view inside my viewcontroller that I was posting about on Saturday and I'm wondering how to get the click event from the button inside the subview to trigger a function on my viewcontroller. my code is kinda like thiscode:
1. My React-brain says I should pass clearSelectedAccount as a param into SelectedAccountView when I initialize it. Like pre:let selectedAccountView = SelectedAccountView(onTapClose: clearSelectedAccount) 2. I could make TwitterSearchController the delegate of SelectedAccountView and have a function like selectedAccountView(tappedClose: ) but that feels a bit odd since it seems weird to have to use a delegate for something that's a subclass. Maybe I'm wrong there? 3. Forget about subclassing entirely and just manage this whole thing in TwitterSearchController. That doesn't feel like very good OOP though. 4. Maybe there's something where I can like .addTarget on SelectedAccountView and then have an .addTarget on the button inside which fires the class' addTarget? I'm assuming there's just a correct/common way to do this, anyone know what it is?
|
# ? Nov 23, 2020 15:29 |
|
Usual approach would be a delegate or passing in a block, you got it. Don't forget to take a weak reference to self if you pass a block in, otherwise you'll get a retain cycle.
|
# ? Nov 23, 2020 18:23 |
|
Thanks!
|
# ? Nov 23, 2020 18:48 |
|
Is it considered bad to put a lot of logic into a variable's didSet observer? I think I'm kind of trying to shoehorn declarative programming into ViewControllers, so I figured I could put a bunch of UI update code (hide this, show that, etc.) into the didSet of a variable, and then when anything changes it the view will update. Feels like that might be a bit of a footgun though? I know SwiftUI works in a way that would probably be more familiar to me as a React developer but I also know a lot of people say it's not really ready for prime time and the guy who's running this project definitely doesn't want to use it.
|
# ? Nov 25, 2020 15:10 |
|
Not sure about bad form, but it gets complicated if you end up with many didSets. I usually end up making an update() method that ensures the view reflects all current state, then I call update() from the didSets (and anywhere else that needs it, like the end of the initializer maybe).
|
# ? Nov 25, 2020 16:58 |
|
Right. That falls under my general rule of: UI responders don't do anything but call functions that do stuff. Because inevitably that update needs to be triggered from four different sources.
|
# ? Nov 25, 2020 17:23 |
|
The guy that I'm working with said that he wouldn't expect doing something like self.displayName = nil to update the UI but I just wanted to see if that was a common feeling among iOS devs. It sounds like maybe it's fine but just better if the actual code goes in a function that gets called by the didSet rather than straight in the didSet. My thinking is I'd never want self.displayName to be nil but the UI to reflect something else (i.e. because someone set it to nil without explicitly running the update() function)
|
# ? Nov 25, 2020 17:34 |
|
I would expect pretty well any method call or property change on a view to be reflected in the UI because that's the entire point of a view. Totally up to y'all how to expose the functionality, of course, and avoding surprising your teammates is a worthy goal. Maybe it's not property setters, that's ok. Sometimes I make all properties private (or private(set)) and expose my one update() method that takes a parameter for each property. Then you literally can't call update() without specifying every bit of the view's state. Other times there's a viewmodel type that I'll watch for changes, or the didSets trigger an update() or setNeedsLayout() or setNeedsDisplay().
|
# ? Nov 25, 2020 17:48 |
|
Binding properties to the UI so that assignments to the property update the UI too are a very common thing on basically every platform. That doesn't necessarily mean that it's the best way to do things, but it's certainly not something that should surprise anyone who has ever touched GUI code before.
|
# ? Nov 26, 2020 03:02 |
|
Does Swift have any kind of union types or type discrimination? I can't seem to find anything but maybe it's one of those things where they just call it something else? Here's a typescript example of what I mean:code:
|
# ? Nov 30, 2020 19:57 |
|
prom candy posted:Does Swift have any kind of union types or type discrimination? I can't seem to find anything but maybe it's one of those things where they just call it something else? Here's a typescript example of what I mean: use a protocol and have your types implement it.
|
# ? Nov 30, 2020 20:04 |
|
Seems like the closest analogue in swift is enums?
|
# ? Nov 30, 2020 20:23 |
|
enum is as close as you'll get.
|
# ? Nov 30, 2020 21:07 |
|
Thanks, that's kind of what I figured. I can live without it, it's just really convenient.
|
# ? Nov 30, 2020 21:18 |
|
Enums can carry payload values, so they seem to be exactly what you want.
|
# ? Dec 1, 2020 04:13 |
|
Has anyone done much unit testing with Core Data? I have some test files that each succeed individually, but when I try to run them all I get the error "Failed to find a unique match for an NSEntityDescription to a managed object subclass" as though the tests were creating multiple NSPersistentContainers (I'm only creating them in memory) at the same time and the entity names were colliding. These are all instance level NSPersistentContainer variable and since they're only in memory I'm not sure why they know about each other or how to fix it.
|
# ? Dec 1, 2020 18:46 |
|
Random guess: are you creating multiple instances of your managed object model?
|
# ? Dec 1, 2020 22:24 |
|
pokeyman posted:Random guess: are you creating multiple instances of your managed object model? On each test case I initialize an NSPersistentContainer and loadPersistentStores in setUp and destroyPersistentStore and set the NSPersistentContainer to nil in tearDown It looks like I'm creating multiple identical persistent stores somehow, but since each test file works individually. Multiple test files extend the same XCTestCase superclass I created for testing core data, but since the NSPersistentContainer is instance-level I'm not sure where the problem is SaTaMaS fucked around with this message at 03:00 on Dec 2, 2020 |
# ? Dec 2, 2020 02:58 |
|
SaTaMaS posted:On each test case I initialize an NSPersistentContainer and loadPersistentStores in setUp and destroyPersistentStore and set the NSPersistentContainer to nil in tearDown My guess is the first test loads the model, then the second test tries to load the same model again and you're hooped. Does it go away if you init a single NSManagedObjectModel (like at the module level, so there's only ever one instance) and pass it in to the NSPersistentContainer's initializer? Or you could make it a static var in your test case superclass, just make sure there's only ever one. I could be barking up the wrong tree, but this is sounding awfully familiar, and that's how I got around it. edit: yeah this https://stackoverflow.com/questions/51851485/multiple-nsentitydescriptions-claim-nsmanagedobject-subclass
|
# ? Dec 2, 2020 05:29 |
|
Is there any reason future apps can't be developed on xcode 11 at this point ? I know eventually it won't be supported, but for now it's ok, yeah ?
|
# ? Dec 2, 2020 19:09 |
|
TheReverend posted:Is there any reason future apps can't be developed on xcode 11 at this point ? I don't think there's an issue with that for now, I don't even know of an announcement for a sunset date (but I expect not to be able to use 11 in 2022). That said, a terrible SDK I am forced to use has me making builds regularly with 11.1 and 11.3.1 (and switching between them). I can't wait until this poo poo dies. Also gently caress them for making a binary SDK using Swift that I've had to use since Xcode 9 and god dammit
|
# ? Dec 2, 2020 19:15 |
|
I have updates of an app out to TestFlight on version 7.7.0 and am trying to ship a hotfix 7.6.1. The hotfix went through QA and everything fine via TestFlight, the build is there, but when I try to select it to ship it to the store all I see are 7.7.0 builds. Tried in Chrome and Safari. Sending a new build of the 7.6.1 changes on 7.7.0 would be painful and require annoying regulatory hurdles to be met and documented (healthcare). Has anyone run into this before? edit: I am really dumb, the builds are listed in the order they were uploaded not based on their build number. My hotfix was in the middle of my 7.7.0 builds I just kept scrolling past it. Glimm fucked around with this message at 21:56 on Dec 2, 2020 |
# ? Dec 2, 2020 21:28 |
|
pokeyman posted:My guess is the first test loads the model, then the second test tries to load the same model again and you're hooped. Does it go away if you init a single NSManagedObjectModel (like at the module level, so there's only ever one instance) and pass it in to the NSPersistentContainer's initializer? Or you could make it a static var in your test case superclass, just make sure there's only ever one. That fixed it, thanks!! I guess XCode can run multiple tests concurrently but I'm still fuzzy on how it happens that when multiple NSPersistentContainers are created in memory the NSManagedObjectModels are all lumped together creating duplicates.
|
# ? Dec 3, 2020 00:51 |
|
SaTaMaS posted:That fixed it, thanks!! I guess XCode can run multiple tests concurrently but I'm still fuzzy on how it happens that when multiple NSPersistentContainers are created in memory the NSManagedObjectModels are all lumped together creating duplicates. Nice! You can toggle concurrent testing in the scheme editor (go to Test, Info tab, then click Options next to a test bundle and toggle "Execute in parallel"). I think you'll run into it with sequential testing too though, as there's some kind of process-level bookkeeping or caching going on with managed object subclasses and entities.
|
# ? Dec 3, 2020 01:24 |
|
ketchup vs catsup posted:I work on an app with a tableview whose data comes from a realm db. I thought about this some more and my plan is: in the tableview controller's viewModel: for each visible cell, dispatch an operation to a background thread to run the calculations, and in the call back set the result as value in a dictionary held by the viewModel and reload the cell if it's visible. then in cellForRow, look in the dictionary for the key/value and if present, pass that into the cell's configure method.
|
# ? Dec 3, 2020 01:32 |
|
Makes sense to me! I'd also make sure not to start a redundant operation if the cell gets scrolled off-screen and back before the initial operation completes.
|
# ? Dec 3, 2020 02:16 |
|
pokeyman posted:Makes sense to me! I'd also make sure not to start a redundant operation if the cell gets scrolled off-screen and back before the initial operation completes. Is there a clean way to do that? I imagine I’d have to track my dispatches in order to know which to cancel, instead of just firing and forgetting. Or should I use an operation queue instead? I managed to go a long way in iOS engineering without doing too much multithreading so I appreciate any advice and things to watch out for like your comment.
|
# ? Dec 3, 2020 02:25 |
|
ketchup vs catsup posted:Is there a clean way to do that? I imagine I’d have to track my dispatches in order to know which to cancel, instead of just firing and forgetting. Assuming your view models stick around (i.e. you're not recreating them all during scrolling or database changes), I'd just keep track of the calculation state there. Maybe an enum with cases for none, pending, and calculated. Then when the cell is about to appear, you can check the state and fire off the calculation if the state is none. If you want to support cancellation, you could associate a DispatchWorkItem with your enum's pending case. A dispatch queue makes sense. I'd make a dedicated serial queue for calculations and dispatch to that instead of a global queue. Oh, and you're probably already doing it, but be careful about which queue you're on when updating the cell and the view model. e.g. when the calculation's done I would dispatch to the main queue to update the view model's state.
|
# ? Dec 3, 2020 03:18 |
|
I have a subproject which builds dylib that my main project is linking to and I can't figure out how to get the code signing to work so I can build and archive. I am able to emulate without any issue. The error I'm getting is this code:
Originally the antlr4 target had a 'Choose Identity' button ( or something similar ). I clicked on that and chose the antlr4_ios.plist and that filled out that section. I've made sure the Team matches my main app and set the every bundle identifier I can find to match with the understanding if I did that I wouldn't need to sign the dylib but I still can't get past that build error. Edit: Noticed that in the main project that libantlr4-runtime.dylib was set to 'Embed & Sign'. Changing that to 'Embed Without Signing' has no affect and it still looks like it's attempting to sign the dylib for some reason. fankey fucked around with this message at 19:21 on Dec 3, 2020 |
# ? Dec 3, 2020 17:48 |
|
Can you set the antlr4 target to "don't code sign" in its build settings?
|
# ? Dec 3, 2020 19:32 |
|
|
# ? Jun 8, 2024 09:03 |
|
The error message is explicitly saying it can’t be signed because you don’t have a team specified, and in your screenshots you don’t have a team or bundle specified. Also, shipping it with your app as a framework instead of a dylib is probably gonna be the path of least resistance in the long run. Doc Block fucked around with this message at 19:42 on Dec 3, 2020 |
# ? Dec 3, 2020 19:37 |