prom candy posted:

Mainly there's just stale data in there and it's almost worse to have that vs. just having nothing at all. Plus it seems like all the calls have to be async and that just adds a lot of extra boilerplate/indenting (thus my question about promises earlier this week)

This project isn't using ViewModels at all and is mostly powered by a handful of really big view controllers. I don't want to slag off the contractor that we're working with because this is my first iOS/Swift project and he's been doing this since 2010 or so and I've learned a ton about iOS working with him but he just has a higher tolerance for like 1000-line classes that do a whole lot of stuff than I do.

That approach sounds interesting though, so essentially your ViewModel or VC has an initializer where you pass in the currentUser? Do you then save that as an instance variable within the class? If so how do you keep that in sync? The instance var would be a copy and not a direct reference, right?

awesomeolion posted:

My guess is that there's some Spritekit bug related to figuring out a reasonable drawing order when sprites on the same z position.

quote:

I've now run full speed into the next issue... spawning obstacles on a timer and dropping my frame rate from 60 to 8 to freezing. So far my impression of going from Unity to SpriteKit is that it's very foot-gun-y. Which I guess makes sense because Unity is pretty idiot-proof. Anyways, something to debug next time!

pokeyman posted:

Core Data model objects (NSManagedObject and subclasses) are reference types and keep themselves up-to-date with any changes to their context. You can observe changes to individual objects with key-value observing, and to fetch requests using NSFetchedResultsController. When you're providing stuff via initializers, you can pass the NSManagedObjectContext instance, or just pass in e.g. the user object (which has a reference to its context if you need it for subsequent fetching). Then keep it around in an instance variable yeah, and use KVO/FRC to know when to update the UI.

prom candy posted:

Oh drat, okay I think I need to back up and read some docs or focused tutorials on CoreData. This does not appear to be how we're using it in our app at all. Thanks!

pokeyman posted:

I've seen people use Core Data as a glorified object-relational mapper, and they'll pull data from managed objects into structs or plain old NSObjects and pass those around instead. To put it mildly, this pattern does not play to Core Data's strengths, but it can work well enough.

Glimm posted:

Does anyone use Applanga or a similar tool to handle translations? Any thoughts on it?

I saw a demo from them recently and like most marketing demos it looked a little too good to be true, but still probably useful.

Doc Block posted:

If there’s any sanity to SpriteKit’s implementation, z position is just used for sorting. It’s not like they’re enabling depth testing and you’re getting z-fighting problems. Two objects having the same Z value shouldn’t have any effect; the second one should just get drawn on top of the first.


Adding and removing nodes constantly is going to be slow, especially if you’re also doing a bunch of your own initialization stuff. The worst case is that SpriteKit has to allocate memory for a new node array, copy everything over, and then re-sort it by Z value.

Keep a handful of “dead” objects around and parented to your scene, but either hidden or positioned offscreen, then when you need a new one use one of those, and when removing an object make it one of the dead objects.

Or, if you’re adding all objects as direct children of the scene, instead break your scene apart into layers. Use a separate SKNode for each layer of your scene, and add/remove objects from those, which will limit the amount of work SpriteKit has to do when adding/removing objects to that particular SKNode instead of having to re-sort the whole scene.

lord funk posted:

It'd be super nice if the App Store screenshot section actually told me which device produces the exact resolution they want instead of making me guess which of the 50 simulators is 5.5".

jabro posted:

lord funk posted:

Well gently caress. Looks like running my app on iOS 14 causes saved files to have data payloads of nothing because of deprecated keyed archiving. Awesome! Glad my data is more secure because of the move to NSSecureCoding!

gently caress.

KidDynamite posted:

I'm in a lot of pain because you can't generate an appstoreconnect api key for an enterprise account and apple now enforces 2fa so all the automation i just finished setting up is broken. literally got one build out with automation.

KidDynamite posted:

I just changed over to archivedData:withRootObject:requiringSecureCoding and it was a pain in the rear end because it's a bunch of extra code. I had no idea ios 14 broke things though that sure is something.


I'm in a lot of pain because you can't generate an appstoreconnect api key for an enterprise account and apple now enforces 2fa so all the automation i just finished setting up is broken. literally got one build out with automation.

fankey posted:

Thanks for the input. I'd prefer that they run in order so I don't have to worry about 429 errors or something similar. I don't really need to load things as fast and as parallel as possible. There might be a different approach - let me explain better what I'm trying to accomplish.

I'm loading a bunch of images from an HTTP server. The current version of the app creates a separate dispatch_queue_t, uses CGImageSourceCreateWithURL to create the images and once finished makes a callback back to the dispatch_get_main_queue to notify the UI that the images have been loaded. This worked perfectly fine until we wanted to use HTTPS instead of HTTP to load the images. Because this server is an internal network appliance the certs will either be self signed or likely not installed on the iOS device. Since the certs can't be verified CGImageSourceCreateWithURL fails due to TLS issues. I do know that I can automatically trust the cert when using the URLSession:didReceiveChallenge callback. Is there a way to accomplish the same without using the async URLSession methods?

prom candy posted:

So these classes seem powerful as hell, feels like you could use these for any complex layout even if you were presenting mostly static data. Is that something that people do now or are stackviews and scrollviews still the way to go? I also checked out the new(ish) UICollectionView/TableViewDiffableDataSource talk from the same WWDC and that also looks like an upgrade over delegation. The guy who built our app for us didn't use them anywhere though, do they have downsides?

take boat posted:

at my job we typically use stack views contained within scroll views, though we don't generally deal with long lists of user-generated content so this works out okay

we also do things like using wrapping views to add insets vOv

I would suggest using collection views for any layout beyond a single screen if possible, though

edit: one big downside with UITableViewDiffableDataSource / UICollectionViewDiffableDataSource is that they're iOS 13+ only. we're getting to the point where that's a pretty reasonable requirement (especially if you're looking to use SwiftUI), but for many apps that's still a problem

prom candy posted:

I need to build a layout and I'm a bit unsure of how to do it. I have a card-like design that can grow until it takes up the full height of the screen. The content is made up of a title, and then some dynamic content. If the content is greater than the length of the screen I want to be able to do an inner scroll of the content itself, while the title (and the card itself) stays in place.

What I've tried is making the card itself a UIStackView, and adding the title as a UILabel. After that, I add a UIScrollView to the stack view, and then add the content to the UIScrollView. The thing I can't figure out is how to tell the UIScrollView that it can grow until the outer stack view reaches its max height (set with a lessThanOrEqualTo constraint) at which point it needs to become scrollable instead.

Here's a crude ascii representation of a shorter amount of content as well as a longer amount of content. Any ideas? Do I need to calculate the size of my content/card container or can I do this with autolayout?

code:

|-------------------|   
| TITLE             |
|                   |
| |---------------| |
| | No            | |
| | Scrolling     | |
| | Required      | |
| |---------------| |
|-------------------|   

|-------------------|   
| TITLE             |
|                   |
| |---------------| |
| | Max           | |
| | Limit         | |
| | Hit           | |
| | So            | |
| | Now           | |
| | Scrolling     | |
| | is            | |
| |---------------| |
|-------------------|