Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »

Doc Block: Apr 15, 2003; Fun Shoe

pokeyman posted:

That documentation says the opposite though?

quote:

Return Value
An initialized object, or nil if an object could not be created for some reason that would not result in an exception.

(emphasis mine)

# ? Jun 4, 2018 17:36

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 14:09

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

And it says -[NSObject init] just returns self. Maybe something else can return nil from init?

# ? Jun 4, 2018 18:45

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Doc Block posted:

(emphasis mine)

The init method defined in the NSObject class does no initialization; it simply returns self. In terms of nullability, callers can assume that the NSObject implementation of init does not return nil.

# ? Jun 4, 2018 19:47

Doc Block: Apr 15, 2003; Fun Shoe

Like, I didn't think NSObject's init did very much (if any) actual work, but that it could return nil maybe for some reason. Still, shows what I get for skimming the docs in search of confirmation of what I thought I already knew.

In any case, returning nil if the init method can't succeed is totally valid, and even if your own classes don't do it something further up the inheritance hierarchy might, so I generally assume that values returned by init methods can be nil.

# ? Jun 4, 2018 20:35

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

While -[NSObject init] can�t return nil, the expression [[NSObject alloc] init] could conceivably return nil if +[NSObject alloc] fails.

Of course if allocation fails everything is completely hosed, because nobody writing code on UNIX has ever paid attention to allocation failure or attempted recovery�

# ? Jun 4, 2018 21:16

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Doc Block posted:

Like, I didn't think NSObject's init did very much (if any) actual work, but that it could return nil maybe for some reason. Still, shows what I get for skimming the docs in search of confirmation of what I thought I already knew.

In any case, returning nil if the init method can't succeed is totally valid, and even if your own classes don't do it something further up the inheritance hierarchy might, so I generally assume that values returned by init methods can be nil.

A fair and good assumption! You just happened to pick like the only counterexample

eschaton posted:

While -[NSObject init] can�t return nil, the expression [[NSObject alloc] init] could conceivably return nil if +[NSObject alloc] fails.

Of course if allocation fails everything is completely hosed, because nobody writing code on UNIX has ever paid attention to allocation failure or attempted recovery�

I wouldn�t even know where to start an attempted recovery in that case. Or am I hosed anyway because some library I depend on will break even if I don�t?

# ? Jun 5, 2018 00:43

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

That�s what I mean, if allocation fails everything is about to fall over, there�s nothing you can do.

On the classic Mac applications actually could gracefully handle allocation failures, but that�s because the entire OS stack was written with that in mind: First because they were impossibly RAM constrained, later because Switcher and then MultiFinder stuck applications in fixed RAM partitions.

Even then �recovery� really just meant freeing a reserve heap block to provide enough heap to show an error alert and let the user save their work before quitting.

# ? Jun 5, 2018 07:31

Toady: Jan 12, 2009

Are there AppKit or Foundation release notes for 10.14? The old area I used to find those sorts of documents in has a message that it's no longer being updated.

# ? Jun 5, 2018 17:14

Doctor w-rw-rw-: Jun 24, 2008

So my team is getting reorged into a different project, and there's some Swift in the project. We're trying to establish some baseline coding standards from the get-go, since we have a lot of this team's people going from ObjC->Swift.

Does anyone know about/can vouch for/can vouch against SwiftLint and SwiftFormat?

What coding standards does Apple use or enforce?

# ? Jun 5, 2018 17:19

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

SwiftLint turned out surprisingly well for something originally hacked together on a plane flight to go with a conference talk. As with every linting tool there's a pile of dumb and wrong warnings, but also some useful ones.

# ? Jun 5, 2018 21:17

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Look at the Swift standard library and other official Apple Swift projects to see Apple�s coding standards for Swift. (And when in doubt, follow what Apple does, not what some random online tells you is the �true Swift way.�)

# ? Jun 5, 2018 22:01

Doctor w-rw-rw-: Jun 24, 2008

eschaton posted:

Look at the Swift standard library and other official Apple Swift projects to see Apple�s coding standards for Swift. (And when in doubt, follow what Apple does, not what some random online tells you is the �true Swift way.�)

Well, I started by applying swiftformat to swift-corelibs-foundation, and found inconsistencies in spacing, case indenting, and self usage...so Apple's own True Swift Way� doesn't have a clear answer. Also, IMO blank lines should never have indentations, so there's that, too.

# ? Jun 6, 2018 06:34

Dog on Fire: Oct 2, 2004

Is there any way to add custom data to the App Store in-app purchase representation, and have that custom data be later retrievable? Say I have a bunch of different items under one App Store Connect�s Product and would like to somehow have every separate purchase action to also refer to the actual item�s id using some parameter, property, field or whatever. And have that data stick to that purchase representation.

Typing this out I can kind of see how we�re probably going to have to implement this separately on our own, but Android seems to have a possibility to add custom data to a purchase using an instance variable named �developerPayload� which is supposed to permanently tie that custom payload to the purchase, so maybe there�s something like that also for the App Store in-app purchases?

# ? Jun 6, 2018 22:21

SaTaMaS: Apr 18, 2003

Toady posted:

We're well past the point where Objective-C, as fond as I am of it, could be considered something other than legacy technology. It's clear where the focus is.

There seems to be a good reason to still write libraries in it, so you can pull in C/C++ code and interface it with Swift

# ? Jun 7, 2018 02:59

Stringent: Dec 22, 2004; image text goes here

Swift is good, just write Swift.

# ? Jun 7, 2018 03:28

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

I still use Objective C++, best way to interface Swift with C++ yet

# ? Jun 7, 2018 09:41

Doc Block: Apr 15, 2003; Fun Shoe

Gonna be... interesting to see what happens with regards to stuff like Unity if Apple actually deprecates Objective-C/Objective-C++ before Swift has C++ interop. Especially on iOS.

# ? Jun 8, 2018 01:30

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Apple needs obj-c++ for interop too.

# ? Jun 8, 2018 02:57

Doctor w-rw-rw-: Jun 24, 2008

Doc Block posted:

Gonna be... interesting to see what happens with regards to stuff like Unity if Apple actually deprecates Objective-C/Objective-C++ before Swift has C++ interop. Especially on iOS.

Swift just needs a good story for being called into from C or C++, then I don't think it should be an issue.

# ? Jun 8, 2018 05:32

Toady: Jan 12, 2009

I was just reading a thread about this on the Swift forums: C++ / Objective-C++ Interop

# ? Jun 8, 2018 06:05

Doctor w-rw-rw-: Jun 24, 2008

Toady posted:

I was just reading a thread about this on the Swift forums: C++ / Objective-C++ Interop

To my knowledge, Logan Shire's characterization isn't accurate - he doesn't work in close proximity to the teams developing a lot of that infrastructure (I was on a sibling team). ABI stability is not a concern except insofar as it affects the binary size restrictions due to shipping the swift libraries. If we were to hypothetically start from scratch, our component abstractions could probably be written in Swift.

In my view, key parts of the codebase's infrastructure are migrating towards C++ in parts where Objective-C/C++ are no longer sufficient. It's to the point where even the cost of loading the Objective-C metadata and rebasing pointers on startup are significant, and I think that, if anything, there might be a trend away from Objective-C/C++ for components, especially in light of improved ARC support for structs.

That's not to say C++/Swift interop wouldn't be hugely useful for other reasons, though. Since that would essentially obsolete Objective-C++, I'd actually prefer the interop avoid bothering with Objective-C++ altogether.

# ? Jun 8, 2018 06:45

Toady: Jan 12, 2009

What's the point of NSCollectionViewFlowLayout's estimatedItemSize? The documentation gives the impression the layout will use the size returned by collectionView:layout:sizeForItemAtIndexPath:, else it uses estimatedItemSize if it's non-zero, else it falls back to itemSize, which has a default value. If you have items with different sizes, you're implementing the delegate method, and if you have items of the same size, you're setting itemSize, so there doesn't appear to be a point to estimatedItemSize. It doesn't enable special self-sizing cell behavior like UICollectionViewFlowLayout's version, and based on my limited testing, the delegate method always gets called even for offscreen elements.

On a related note, several protocol methods in the documentation actually state they'll never get called on 10.11 (the version they were introduced), and they aren't getting called on 10.13 either. I've seen log messages mentioning UIKit classes. It gives the impression the NSCollectionView APIs are incomplete and were hastily put together from their UIKit equivalents.

Toady fucked around with this message at 04:36 on Jun 13, 2018

# ? Jun 12, 2018 23:24

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

For performance and to modernize my code, I'm trying to scale an image with UIGraphicsImageRenderer the way I did with UIGraphicsBeginImageContext. I'm doing something wrong since the resulting image is twice as large instead of half!

The old way:

code:

let sourceCore = ciImage
let scaledSourceImage:UIImage = UIImage(ciImage:ciImage)
		
let size = scaledSourceImage.size.applying(CGAffineTransform(scaleX: 0.5, y: 0.5))
let hasAlpha = false
let scale: CGFloat = 1.0 // use scale factor of main screen

UIGraphicsBeginImageContextWithOptions(size, !hasAlpha, scale)
	scaledSourceImage.draw(in: CGRect(origin: .zero, size: size))
	let scaledImage = UIGraphicsGetImageFromCurrentImageContext()!
UIGraphicsEndImageContext()

The new way, that makes a big image instead of half the size:

code:

let sourceCore = ciImage
let scaledSourceImage:UIImage = UIImage(ciImage:ciImage)
	
let size = scaledSourceImage.size.applying(CGAffineTransform(scaleX: 0.5, y: 0.5))
let hasAlpha = false
				
let renderFormat = UIGraphicsImageRendererFormat.default()
renderFormat.opaque = !hasAlpha
let renderer = UIGraphicsImageRenderer(size: size, format: renderFormat)
let scaledImage = renderer.image {
	(context) in
	scaledSourceImage.draw(in: CGRect(origin: .zero, size: size))
}

# ? Jun 13, 2018 21:55

Dog on Fire: Oct 2, 2004

LP0 ON FIRE posted:

The old way:

code:

let scale: CGFloat = 1.0 // use scale factor of main screen

I can�t try the code out on my own, but maybe the scale being 1.0 messes things up in the old function and the image has been smaller than it has had to be?

What if you compare the images after setting the scale in the old function instead of 1.0 to this: https://developer.apple.com/documentation/uikit/uiscreen/1617836-scale

# ? Jun 14, 2018 07:03

Doctor w-rw-rw-: Jun 24, 2008

EDIT: ignore me

Doctor w-rw-rw- fucked around with this message at 08:16 on Jun 14, 2018

# ? Jun 14, 2018 07:53

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

Dog on Fire posted:

I can�t try the code out on my own, but maybe the scale being 1.0 messes things up in the old function and the image has been smaller than it has had to be?

What if you compare the images after setting the scale in the old function instead of 1.0 to this: https://developer.apple.com/documentation/uikit/uiscreen/1617836-scale

The old function works great. I�m trying to make it smaller, although it is a valid point that the scale variable name is misleading. It�s the new function that I can�t understand why it doesn�t work correctly.

LP0 ON FIRE fucked around with this message at 16:31 on Jun 14, 2018

# ? Jun 14, 2018 16:29

ManicJason: Oct 27, 2003; He doesn't really stop the puck, but he scares the hell out of the other team.

You probably want scale to be 0.0, which means use the main screen scale, or whatever your main screen scale is (2.0 for most devices). 1.0 is specifying non-Retina.

# ? Jun 14, 2018 19:20

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

ManicJason posted:

You probably want scale to be 0.0, which means use the main screen scale, or whatever your main screen scale is (2.0 for most devices). 1.0 is specifying non-Retina.

The newer code that I can't get working correctly that uses UIGraphicsImageRendererFormat does not use the scale variable. (Maybe I should somehow?)

# ? Jun 14, 2018 19:26

ManicJason: Oct 27, 2003; He doesn't really stop the puck, but he scares the hell out of the other team.

UIGraphicsImageRendererFormat should default to main screen scale. If your old code worked with 1.0, try setting the UIGraphicsImageRendererFormat scale to 1.0.

# ? Jun 14, 2018 21:05

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

ManicJason posted:

UIGraphicsImageRendererFormat should default to main screen scale. If your old code worked with 1.0, try setting the UIGraphicsImageRendererFormat scale to 1.0.

You mean in the CGAffineTransform's scaleX and y? That just makes the image even bigger. Besides that, I'm unaware of a scale parameter to send to UIGraphicsImageRendererFormat like UIGraphicsBeginImageContextWithOptions has.

# ? Jun 14, 2018 22:14

ManicJason: Oct 27, 2003; He doesn't really stop the puck, but he scares the hell out of the other team.

I literally mean the property called �scale� on UIGraphicsImageRendererFormat.

# ? Jun 15, 2018 03:36

Doctor w-rw-rw-: Jun 24, 2008

UIImage.init(ciImage: CIImage, scale: CGFloat, orientation: UIImage.Orientation)

maybe that's your problem.

# ? Jun 15, 2018 05:12

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

ManicJason posted:

I literally mean the property called �scale� on UIGraphicsImageRendererFormat.

Oh! I did not know about that haha. Interesting

Anyway, my performance went waaaay up by using all CIFilters instead to scale (CILanczosScaleTransform) and place (CISourceAtopCompositing) smaller images onto a larger one. I was running it live through the camera view, so draw and UIGraphicsImageRendererFormat was attempted murder to my phone in comparison. Highly suggested.

# ? Jun 15, 2018 19:59

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

What�s wrong when my provision profile expires way too soon? In most cases it lasts about a week. Sometimes a couple days before needing to build and verify my app again in Settings.

I just verified my app again in Settings today, which I thought meant it auto renewed my provision, but here we are tonight and my app already refuses to open. Same pattern that often happens, and I�ll need to go back into work and verify the app again.

# ? Jun 16, 2018 02:14

Doctor w-rw-rw-: Jun 24, 2008

So what do people think about Marzipan?

# ? Jun 16, 2018 04:11

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

LP0 ON FIRE posted:

What�s wrong when my provision profile expires way too soon? In most cases it lasts about a week. Sometimes a couple days before needing to build and verify my app again in Settings.

I just verified my app again in Settings today, which I thought meant it auto renewed my provision, but here we are tonight and my app already refuses to open. Same pattern that often happens, and I�ll need to go back into work and verify the app again.

Are you using the free developer account? The provisioning profile for those only lasts a week.

Doctor w-rw-rw- posted:

So what do people think about Marzipan?

lol

As a piece of technology it seems interesting and impressive. As a platform for building apps I have a feeling it'll be known for utter garbage ports.

# ? Jun 16, 2018 04:20

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

Plorkyeran posted:

Are you using the free developer account? The provisioning profile for those only lasts a week.

That�s it! Thanks. I�ve been using my own account and need to switch.

# ? Jun 16, 2018 05:34

Doctor w-rw-rw-: Jun 24, 2008

Plorkyeran posted:

As a platform for building apps I have a feeling it'll be known for utter garbage ports.

Can you expand on that?

I'm pretty optimistic. I think apps that work well on iPad and recent years' trend towards flexible layouts are both enabling for the desktop form factor - especially as dual-app multitasking on the iPad allows for different sizes. One can imagine left click as touch, and right click (perhaps optionally) as a long press.

# ? Jun 16, 2018 08:58

Toady: Jan 12, 2009

Doctor w-rw-rw- posted:

So what do people think about Marzipan?

I'm annoyed it was announced a year ahead of time with no other information, and I wonder why anyone would bother writing a Mac app from this point forward.

# ? Jun 16, 2018 10:07

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 14:09

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Doctor w-rw-rw- posted:

Can you expand on that?

I'm pretty optimistic. I think apps that work well on iPad and recent years' trend towards flexible layouts are both enabling for the desktop form factor - especially as dual-app multitasking on the iPad allows for different sizes. One can imagine left click as touch, and right click (perhaps optionally) as a long press.

The iPad is already full of garbage ports of software written for phones with no effort put into the iPad version beyond getting it to work well enough to pass review. Making a UI designed for touch actually good on a mac would be significantly more work.

# ? Jun 16, 2018 20:16

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »