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 »

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

Doctor w-rw-rw- posted:

Is this true or is this alluding to the actual problem which is that UIViews aren't key-value compliant (unlike CALayers, which are)?

I'm not sure what you mean by "key-value compliant". UIView is key-value coding compliant in every sense that CALayer is. But, unlike CALayer, it's not a generic KVC-accessible container.

As I understand it, UIKit makes no guarantees that KVO notifications will happen. The value of a table view's contentSize could well change out from under you without your knowledge. I'd imagine this is due in part to CALayer's KVO non-compliance.

Oh, and my (admittedly lame) source is this two-year-old Stack Overflow answer from an Apple engineer:

quote:

Nothing in UIKit is guaranteed to be KVO-compliant.

I'd love a money quote from the docs, but that's all I have squirrelled away and my search came up dry.

quote:

As a ginormous hack, I've used CALayers to store data, when I had no other (politically viable*) option.

* hated that job

That is outstanding! I'd love to hear more, if you're comfortable sharing. Trying to imagine someone saying no to adding a property or associated object, but yes to irrelevant arbitrary data on a layer.

# ? Sep 27, 2013 06:52

Adbot: ADBOT LOVES YOU

# ? May 21, 2024 07:45

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

pokeyman posted:

I'm not sure what you mean by "key-value compliant". UIView is key-value coding compliant in every sense that CALayer is. But, unlike CALayer, it's not a generic KVC-accessible container.

...

That is outstanding! I'd love to hear more, if you're comfortable sharing. Trying to imagine someone saying no to adding a property or associated object, but yes to irrelevant arbitrary data on a layer.

Associated objects weren't a part of the runtime yet, and at least at the time, setValue:forKey on UIView was prone to reliably crashing your app with an exception, because you couldn't store something in it. Hell, automatic property synthesis wasn't even a thing yet, or GCD.

Welp.

This was also the job where:

The model objects all had singleton arrays storing the client's state. My boss called this the "multiton" pattern. Also, there was no synchronization. No need, really, everything was on the main thread anyways.
We ported our response parsing to the Objective-C version of a Java XML parsing library that basically used a xpath-like pattern to scan the XML into objects.
My boss believed that equality and hash code implementations only had to cover the properties you cared about
The model objects were initialized by their 'multitons', which were initialized lazily. Which they were, in an arbitrary order. So every app startup would happen differently. Because race conditions.
I was pretty explicitly a code monkey and also not *allowed* to help on backend, even though I had more experience with nearly all the stack than pretty much everyone my age, and at least more breadth than most.
They didn't give me a raise because they said my salary was too high compared to people hired at the same time. Nevermind that my title was two to three levels higher and not 'junior'; I didn't graduate from college, didn't go to the same college nearly everyone else went to, and they totally forgot that I sacrificed stock to have the cash to support my parents. When I reminded them of this they gave me a tiny raise compared to the junior engineers hired with me, because their budget was already done. Meanwhile, they were gambling millions more than revenue on advertisement and marketing. Granted that investment paid off for them, but still. drat. I later interviewed one of their engineers who joined after I left, at a different company of course, and he was such a clown. Ugh.
The VP of Engineering was hired from outside the company and when I left insisted that I was burning bridges. I then proceeded to make sure my friends blacklisted the company from consideration and to recommend that their friends do the same. This was at the time a startup with a steadily increasing growth rate, so it had reason to be appealing.

So yeah, there wasn't enough logic and reason for me to recall the reasons for using CALayer as basically a dictionary. :P

Doctor w-rw-rw- fucked around with this message at 17:09 on Sep 27, 2013

# ? Sep 27, 2013 17:05

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

If anyone else was wondering why they kept insisting that we have to stop touching isa directly for unspecified performance reasons at WWDC, http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html answers that (and as usual for Mike Ash, has a bunch of other interesting stuff).

# ? Sep 27, 2013 22:29

haveblue: Aug 15, 2005; Toilet Rascal

Did Apple change how the status bar is hidden or something? I set UIStatusBarHidden in the info.plist and called setStatusBarHidden from the finish launching handler and it's still visible. Maybe this is because I'm using Cocos2d?

e:

code:

	[UIApplication sharedApplication].statusBarHidden = YES;
	NSLog(@"is the status bar hidden? %d", [UIApplication sharedApplication].statusBarHidden);

This prints 0.

haveblue fucked around with this message at 20:00 on Sep 28, 2013

# ? Sep 28, 2013 19:49

Doc Block: Apr 15, 2003; Fun Shoe

Yes. In iOS 7 the status bar and its appearance are determined on a per-viewController basis. This can be really annoying and frustrating.

There's a key you can add to your app's info.plist to disable per-viewController status bar appearance (I don't remember what it is offhand), but it's not perfect: using any system component that causes the status bar to be shown (such as UIImagePickerController) will cause the status bar to stay showing.

Basically, when it comes to the new status bar and appearance stuff in iOS 7, Apple designed it for their one specific use case (apps with a white background and a visible status bar with black text) and anything else is a major pain.

# ? Sep 28, 2013 20:36

lord funk: Feb 16, 2004

Doc Block posted:

Basically, when it comes to ... and .... in iOS 7, Apple designed it for their one specific use case ... and anything else is a major pain.

# ? Sep 29, 2013 01:00

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

Plorkyeran posted:

If anyone else was wondering why they kept insisting that we have to stop touching isa directly for unspecified performance reasons at WWDC, http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html answers that (and as usual for Mike Ash, has a bunch of other interesting stuff).

No one should overlook that article if they care about low level Obj-C/ARM stuff at all. Apple added even more crazy witchcraft along the lines of tagged pointers (which, incidentally, I thought were already in iOS but apparently were not until ARM64.) Every object's retain count is now shoved into its isa pointer :aaaaa:

# ? Sep 29, 2013 02:40

Doc Block: Apr 15, 2003; Fun Shoe

Yeah, all the people saying that going to ARM64 won't be that much of a performance improvement are talking out their rear end.

# ? Sep 29, 2013 02:55

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?

Froist posted:

I've never understood why this isn't on as default, but you have to add an exception breakpoint. Go to the breakpoints tab in the left hand view, click the plus at the bottom, add exception breakpoint, "break: on throw" (default).

You have to do this for every project, it's not a global setting.

You can use the contextual menu for your exception breakpoint to promote it to a per-user breakpoint, so it'll be available from then on in every project you open.

# ? Sep 29, 2013 04:09

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

ManicJason posted:

No one should overlook that article if they care about low level Obj-C/ARM stuff at all. Apple added even more crazy witchcraft along the lines of tagged pointers (which, incidentally, I thought were already in iOS but apparently were not until ARM64.) Every object's retain count is now shoved into its isa pointer

Yeah, I really thought tagged pointers were in iOS, but it makes sense that they weren't in retrospect. It's cool that they have enough control over the platform that they can do crazy runtime stuff like this. I mean if you know exactly how pointers are laid out, you can do weird stuff like throw 19bits into a pointer for retain counts.

# ? Sep 29, 2013 07:20

Small White Dragon: Nov 23, 2007; No relation.

I heard that the App Store is now offering older App versions for older devices. Is there any documentation on this?

# ? Sep 29, 2013 10:33

Hughlander: May 11, 2005

ManicJason posted:

No one should overlook that article if they care about low level Obj-C/ARM stuff at all. Apple added even more crazy witchcraft along the lines of tagged pointers (which, incidentally, I thought were already in iOS but apparently were not until ARM64.) Every object's retain count is now shoved into its isa pointer

From that same site http://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-build-tagged-pointers.html NSNumber has been a Tagged Pointer since iOS5.

# ? Sep 29, 2013 15:15

lord funk: Feb 16, 2004

eschaton posted:

You can use the contextual menu for your exception breakpoint to promote it to a per-user breakpoint, so it'll be available from then on in every project you open.

Booyah. I love this thread.

# ? Sep 30, 2013 02:43

Small White Dragon: Nov 23, 2007; No relation.

Anybody know what, if any, changes have been made to video encoding specs in iOS 7? I have a bunch of videos that play without audio, even though they were fine on every previous iOS release and device.

# ? Sep 30, 2013 09:24

Doh004: Apr 22, 2007; Mmmmm Donuts...

Doh004 posted:

Anyone know why I can't change my UISearchBar's textColor in iOS7?

code:

[self.SearchBar setBarStyle:UIBarStyleBlack];
[self.SearchBar setTranslucent:NO];
[self.SearchBar setTintColor:[UIColor blackColor]];
[self.SearchBar setBarTintColor:[UIColor whiteColor]];
[self.SearchBar setBackgroundColor:[UIColor clearColor]];

Produces this:

Sorry to quote my own post, but would anyone happen to have any idea? Any help would be greatly appreciated :shobon:

# ? Sep 30, 2013 15:34

Hog Obituary: Jun 11, 2006; start the day right

The only solution I've seen is this crappy one: http://stackoverflow.com/questions/19048766/uisearchbar-text-color-change-in-ios-7
(traversing the view hierarchy)

# ? Sep 30, 2013 16:00

lord funk: Feb 16, 2004

Doh004 posted:

Sorry to quote my own post, but would anyone happen to have any idea? Any help would be greatly appreciated

It looks like the text color is in a private property of the UISearchBar (its _searchField UITextField), so you shouldn't have direct access to the text color. I'm thinking your best bet is to manually set the background color to increase the contrast, rather than using the clearColor.

edit: or what Hog posted

# ? Sep 30, 2013 16:02

Doh004: Apr 22, 2007; Mmmmm Donuts...

Why the gently caress are we still doing this poo poo? I know they've consciously made the decision to not make the text color directly changeable, but I don't get why.

But thank you for the sanity check guys.

# ? Sep 30, 2013 16:29

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

quote:

Doc Block posted:
Basically, when it comes to ... and .... in iOS 7, Apple designed it for their one specific use case ... and anything else is a major pain.

This so loving bears repeating.

I wish Apple didn't ban their employees from releasing apps in the App Store. If they had to live with the pain there is no way we'd still be dealing with half the boilerplate and hacks we deal with.

# ? Oct 1, 2013 03:30

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

Ender.uNF posted:

I wish Apple didn't ban their employees from releasing apps in the App Store. If they had to live with the pain there is no way we'd still be dealing with half the boilerplate and hacks we deal with.

There's a few apps that seem to be out of pocket. Podcasts, Find My Friends, and Apple Store all seem to be done by small teams more or less on their own, probably in addition to some other duties. They'll feel the pain, though they sure have an easier path to solving the problems.

# ? Oct 1, 2013 04:47

Doc Block: Apr 15, 2003; Fun Shoe

Ender.uNF posted:

This so loving bears repeating.

I wish Apple didn't ban their employees from releasing apps in the App Store. If they had to live with the pain there is no way we'd still be dealing with half the boilerplate and hacks we deal with.

I don't think it's so much an issue of not eating their own dog food, but rather of doing a major UI overhaul in only 7 months, and the lead designer having zero software design experience.

My advice is to file bug reports. And if iOS 7.1 comes along without a marked improvement in things like they way the status bar and navbar stuff are handled, maybe a little bit of public whining.

# ? Oct 1, 2013 06:32

lord funk: Feb 16, 2004

I'm putting TC-11 on sale this Thursday. I never really wanted to play the 'one-day sale, big price drop' game, but I've been convinced it's a good thing.

Anyway, I'll be happy to share results here. It's a bit scary being in an expensive price bracket, and there isn't a lot of info about it floating around. Most trip reports of putting apps on sale go something like this: "My app went live for 6 days, and then I made it free..." Not exactly the same boat I'm in. :ohdear:

# ? Oct 1, 2013 18:45

Doc Block: Apr 15, 2003; Fun Shoe

I put one of my apps, which is $0.99, on free for one day. It got picked up by one of those Free Apps of The Day sites, and downloads went from 3-4 per day to 5000. Got maybe a dozen the following day even though the sale had ended.

It's a good thing that app was created primarily for my own use and I never expected anyone to buy it.

# ? Oct 1, 2013 20:20

lord funk: Feb 16, 2004

Yeah mine definitely won't be free, and I haven't actually decided how low it's going to go. I just hope my inbox doesn't turn into a running ticker of 'when's the next sale?'

# ? Oct 1, 2013 21:17

DreadCthulhu: Sep 17, 2008; What the fuck is up, Denny's?!

How much testing do you guys do on your apps? Let's say you don't keep too much crazy logic in your iOS client, most of the hard work is done on the server and you just need to visualize the data correctly/pleasantly and transition between various controllers without crashing too much. How much TDD/BDD work would you actually do in this situation?

# ? Oct 2, 2013 08:13

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

Man did I hate printf'ing NSU?Integers until I learned this:

Objective-C code:

NSInteger i = -2;
NSUInteger u = 3;
NSLog(@"NSInteger: %zd, NSUInteger: %tu", i, u);

Warning-free on both 32-bit and 64-bit. (By coincidence, not by design, but still handy.)

DreadCthulhu posted:

How much testing do you guys do on your apps? Let's say you don't keep too much crazy logic in your iOS client, most of the hard work is done on the server and you just need to visualize the data correctly/pleasantly and transition between various controllers without crashing too much. How much TDD/BDD work would you actually do in this situation?

I test my apps all the time by using them. However, you probably meant automated testing since you mentioned TDD/BDD. In which case: it depends. I wrote an HTML parser in Objective-C using TDD because someone wrote a lovely suite of unit tests for HTML parsers. But using TDD for an app sounds dreadful. Unit testing view controllers seems pointless to me. Doubly so for views. BDD just cracks me up, so I've got no experience to dwell on there. If I had to guess, I'd put my average app code test coverage at less than 1%. (I don't use storyboards and rarely use nibs, so my apps probably have more code than the norm.)

Automated UI testing is something I'd do if, say, I was working on a built-in app. I'd definitely want a big pile of recipes for testing, say, Calendar, comparing screens to saved screenshots, verifying VoiceOver, notifying me of regressions, and all that. I've never held my own work up to that standard.

# ? Oct 2, 2013 19:16

HiriseSoftware: Dec 3, 2004; Two tips for the wise:
1. Buy an AK-97 assault rifle.
2. If there's someone hanging around your neighborhood you don't know, shoot him.

iCloud in games question - How are people supporting virtual currency and things that can be bought with them (items, upgrades, etc)? I want to assume everything is key-value, and I'd imagine non-consumable bought items are easy because you're just setting a Boolean to true once it's bought on any device, but how are conflicts resolved in currency value (e.g. Smurfberries) and bought consumables (e.g. usable boosts)? Do developers just not bother with those?

# ? Oct 3, 2013 18:15

DreadCthulhu: Sep 17, 2008; What the fuck is up, Denny's?!

pokeyman posted:

I test my apps all the time by using them. However, you probably meant automated testing since you mentioned TDD/BDD. In which case: it depends. I wrote an HTML parser in Objective-C using TDD because someone wrote a lovely suite of unit tests for HTML parsers. But using TDD for an app sounds dreadful. Unit testing view controllers seems pointless to me. Doubly so for views. BDD just cracks me up, so I've got no experience to dwell on there. If I had to guess, I'd put my average app code test coverage at less than 1%. (I don't use storyboards and rarely use nibs, so my apps probably have more code than the norm.)

Automated UI testing is something I'd do if, say, I was working on a built-in app. I'd definitely want a big pile of recipes for testing, say, Calendar, comparing screens to saved screenshots, verifying VoiceOver, notifying me of regressions, and all that. I've never held my own work up to that standard.

So basically, you test the really meaty logic that can be nicely isolated and tested, but anything involving UI transitions and fairly simple controller logic is basically not worth it as long as you run through it a couple of times manually?

Know anything about mocking async API calls? I feel like that might make people's lives easier.

One conclusion I've been getting to recently in apps for the web is that you should move as much business logic into the backend layer as possible, and treat any sort of client like iOS, a web SPA etc as just a dumb shell for rendering pretty views. A backend is really easy to test, so if you take care of most code coverage down there, then there's only so much you can gently caress up in the client.

# ? Oct 3, 2013 19:20

Dr Monkeysee: Oct 11, 2002; just a fox like a hundred thousand others; Nap Ghost

The app I'm working on we've gone almost the opposite route and try to do TDD as much as possible. It *is* challenging for UI layer stuff. I've found that you can test view controllers as long as you're willing to dig into the internals a bit since controllers are so tightly bound to views their "observable functionality" amounts to implementation details from a method-call perspective. You can test (and mock) them but you don't get a clean input -> output pattern like you would for a service API or something.

We rely on OCMock (http://ocmock.org/) pretty heavily, as well as test categories in the test .m files themselves if we need to expose internals of the class under test. Due to Objective C's dynamic nature OCMock makes it pretty easy to set up dependency expectations without having to resort to depedency injection like we would have to for, say, C# or Java.

# ? Oct 3, 2013 20:24

lord funk: Feb 16, 2004

TC-11 is on sale w0000t! $7.99 down from $29.99.

Problem is Taiwan is still showing the old price. I'm having a hard time getting a quick response from Apple about this...

# ? Oct 3, 2013 20:31

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

DreadCthulhu posted:

So basically, you test the really meaty logic that can be nicely isolated and tested, but anything involving UI transitions and fairly simple controller logic is basically not worth it as long as you run through it a couple of times manually?

Know anything about mocking async API calls? I feel like that might make people's lives easier.

One conclusion I've been getting to recently in apps for the web is that you should move as much business logic into the backend layer as possible, and treat any sort of client like iOS, a web SPA etc as just a dumb shell for rendering pretty views. A backend is really easy to test, so if you take care of most code coverage down there, then there's only so much you can gently caress up in the client.

That might be easier but it makes the app suck in many scenarios, like being indoors with poor cell reception, at a game where the network is overloaded, on an airplane, etc. Not to mention the snappiness and instant feedback you get when the client isn't just a dumb viewer.

# ? Oct 3, 2013 21:59

dizzywhip: Dec 23, 2005

Quick question about in-app purchases. I created my app a while back as a standard paid app, but I'd like to migrate to the seemingly more successful free + IAP to unlock features model. I'm wondering about the best way to to so without forcing my current customers to buy the app again as an in-app purchase.

I've noticed that I'm allowed to create a free in-app purchase in iTunes connect without any problems so far, so I was thinking it could be possible to create two different IAPs that unlock the same functionality -- a standard one that costs money, and one that's free which can be accessed in the app by entering a redemption code that I hand out to existing users. Codes would be generated on my own server, then the app would verify the code on the server before allowing the user to "purchase" the free IAP.

I don't see why this wouldn't work from a technical perspective, but is this something that Apple would be okay with? Also, is there any way that someone would be able to access the free IAP without being able to get to the part of my app that lets them buy it? I assume it would be listed in the app store in the top in-app purchases section, but there's no way for a user to buy an IAP outside of the app, right?

# ? Oct 3, 2013 22:00

Doc Block: Apr 15, 2003; Fun Shoe

On iOS 7 apps get a Mac App Store style receipt, which contains the purchase date (among other things).

So you could just check the app receipt, and if they bought the app before it went freemium then unlock everything.

# ? Oct 4, 2013 00:08

lord funk: Feb 16, 2004

Where can I look up daily sales charts? Some users are saying I beat Garageband today but I don't know where to look this up. :ohdear:

# ? Oct 4, 2013 00:16

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

TC-11 is the top paid app of the music section, probably where they're seeing it.

# ? Oct 4, 2013 00:35

NoDamage: Dec 2, 2000

lord funk posted:

Where can I look up daily sales charts? Some users are saying I beat Garageband today but I don't know where to look this up.

Try AppAnnie or AppFigures. AppFigures is totally worth it, incidentally. For about $10/month (varies depending on the number of apps you have) it aggregates daily app sales across iOS/Mac/Android/Amazon and sends me a tidy little email summary.

# ? Oct 4, 2013 00:45

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

NoDamage posted:

Try AppAnnie or AppFigures. AppFigures is totally worth it, incidentally. For about $10/month (varies depending on the number of apps you have) it aggregates daily app sales across iOS/Mac/Android/Amazon and sends me a tidy little email summary.

Distimo does basically the same, but better/newer looking in some cases. I think it might be totally free too...or at least it is if you only have one thing you're tracking.

# ? Oct 4, 2013 01:58

DreadCthulhu: Sep 17, 2008; What the fuck is up, Denny's?!

Ender.uNF posted:

That might be easier but it makes the app suck in many scenarios, like being indoors with poor cell reception, at a game where the network is overloaded, on an airplane, etc. Not to mention the snappiness and instant feedback you get when the client isn't just a dumb viewer.

Yeah it'd work OK only in situations where there's continuous guaranteed fast Internet, that makes sense. There are some scenarios where you can get away with that, but I agree that most apps are not meant to work that way.

# ? Oct 4, 2013 05:29

dizzywhip: Dec 23, 2005

Doc Block posted:

On iOS 7 apps get a Mac App Store style receipt, which contains the purchase date (among other things).

So you could just check the app receipt, and if they bought the app before it went freemium then unlock everything.

Oh dang, I didn't even know such a thing existed! I'll give that a shot, thanks.

# ? Oct 4, 2013 06:16

Adbot: ADBOT LOVES YOU

# ? May 21, 2024 07:45

Toady: Jan 12, 2009

Friday surprise, the GM seed of OS X Mavericks is available.

# ? Oct 4, 2013 16:46

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

«‹›354 »