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 »

j4on: Jul 6, 2003; I fix computers to pick up chicks.

Small White Dragon posted:

Did you also release it for Android or any other platforms?

Old question, but I finally got around to trying it on Android. Took all of an hour to download the SDK, figure it out, and recompile the Adobe Air project for a Nexus 7. Worked! As someone who does a lot of browser compatibility debugging, this is a drat miracle.

A few small issues--Android doesn't sleep the app when backgrounded, I have some app store specific links, and of course I need to dig up some more devices to test. (The emulator runs slow enough to make me nervous about trusting it as a performance profile). But all-in-all, five stars.

# ? Mar 14, 2013 07:06

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 12:07

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

DreadCthulhu posted:

How many provisioning profiles do you guys create? I have about 3 per app right now, one for dev, one for adhoc and one for app store. Am I doing it wrong?

This is what I do, but I'm also relatively new to all of this so take that for what you will.

# ? Mar 14, 2013 13:57

Glimm: Jul 27, 2005; Time is only gonna pass you by

DreadCthulhu posted:

How many provisioning profiles do you guys create? I have about 3 per app right now, one for dev, one for adhoc and one for app store. Am I doing it wrong?

I do the same.

# ? Mar 14, 2013 16:33

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

DreadCthulhu posted:

How many provisioning profiles do you guys create? I have about 3 per app right now, one for dev, one for adhoc and one for app store. Am I doing it wrong?

That's what I do as well. I did notice that I was able to build and run a debug version of a new app I'm building on my phone without taking any steps to create a provisioning profile, though, so I'm not sure how that fits into things.

# ? Mar 14, 2013 18:01

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

PT6A posted:

That's what I do as well. I did notice that I was able to build and run a debug version of a new app I'm building on my phone without taking any steps to create a provisioning profile, though, so I'm not sure how that fits into things.

(I am terrible at provisioning profile stuff but I think) that's your wildcard profile at work. (And I find this stuff really confusing but) I believe Xcode will manage one for you for your convenience.

# ? Mar 14, 2013 18:07

Doc Block: Apr 15, 2003; Fun Shoe

Unless you're doing stuff with iCloud/GameCenter/secure keychain access/a few other things, it's perfectly fine to just use a wildcard profile. Both of my apps were developed, tested, and distributed with wildcard profiles.

# ? Mar 14, 2013 20:36

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

PT6A posted:

That's what I do as well. I did notice that I was able to build and run a debug version of a new app I'm building on my phone without taking any steps to create a provisioning profile, though, so I'm not sure how that fits into things.

I wasn't kidding when I said open the .mobileprovision file in a text editor. You will understand the whole thing a lot better.

For the lazy:

All provisioning profiles contain:

1. The app ID prefix
2. When the profile was created and when it expires
3. The list of certificate(s) that can sign code - this is just the public key corresponding to the private key of your developer certificate. For a team profile, this has all your team member's public keys. For Ad-hoc or App Store, this may have a more restricted list of developer certs to control which devs can actually distribute builds into the wild.
4. A list of entitlements, such as game center info, keychain info so apps can share keychains, iCloud ubiquity identifier, etc. In theory I assume this could be used to grant all kinds of permissions to bypass the sandbox. A non-wildcard profile specifies the explicit app identifier here; the device will refuse to honor certain entitlements if they are wildcards, that's why you need app-specific profiles if you use certain features.
5. Non-App Store profiles also contain a list of device UDIDs.
6. Then there's the binary container that wraps the plist and includes Apple's digital signature. Every device ships with Apple's certificates in the root trusted store and will refuse to load profiles not signed by an Apple certificate. The provisioning portal, enterprise accounts, et al is just a way for Apple to manage what goes into the profiles and whether or not they want to sign the resulting mobileprovision file.

When you do a build, Xcode takes the profile you selected then looks in your keychain certificates (TEAMS in Organizer) and tries to find a certificate with a private key that matches one of the public keys listed in the profile. When it can't, that's the "Valid signing identity not found" business.

Assuming it finds the cert, it signs the executable with the certificate private key. (I believe this is bog-standard Mach-O executable signing). That proves you did the build and the executable wasn't tampered with. That's it as far as your build goes, so selecting a profile is (mostly) just a "backwards" way of selecting the certificate as far as I can tell, except it also lets Xcode automatically load the profile onto the device and *i think* the build includes the app prefix (Bundle Seed ID), but really it's your certificate private key that protects from someone making malware builds with your name on them.

When the device installs or runs the code, it looks through installed profiles to find one specifying the matching public key and either a matching app ID or wildcard to validate the executable. It won't accept profiles not signed by Apple, expired profiles, or profiles that don't include its own UDID. The signature is verified to make sure the executable hasn't been corrupted. The sandbox also enforces the entitlements specified.
The exception is the App Store, where IIRC Apple's servers verify the uploaded build, then strip and re-sign with Apple's certificate but I may not be 100% correct on that.

So the short version is if you have the wildcard profile installed you can build apps all day long without doing anything else, so long as you don't want to share keychains, use iCloud/Game Center, etc. The profile only needs to be updated on new devices when that device has its UDID added or on all devices when a new team member/build server is added to the mix. You should be able to guess now why that is.

For large teams you can get fancy and only include the build server's certificate in the app store profiles so people can't submit rogue builds, or only allow managers to use the ad-hoc profile, etc.

Simulated fucked around with this message at 02:59 on Mar 15, 2013

# ? Mar 15, 2013 02:53

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

That was very informative, thanks for writing that up. I am, indeed, lazy.

# ? Mar 15, 2013 03:46

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

Doc Block posted:

Unless you're doing stuff with iCloud/GameCenter/secure keychain access/a few other things, it's perfectly fine to just use a wildcard profile. Both of my apps were developed, tested, and distributed with wildcard profiles.

Random note: It seems that secure keychain access now works with wildcard profiles with identical bundle seeds, as it should have all along.

# ? Mar 15, 2013 07:18

echobucket: Aug 19, 2004

Ender.uNF posted:

I wasn't kidding when I said open the .mobileprovision file in a text editor. You will understand the whole thing a lot better.

For the lazy:

All provisioning profiles contain:

1. The app ID prefix
2. When the profile was created and when it expires
3. The list of certificate(s) that can sign code - this is just the public key corresponding to the private key of your developer certificate. For a team profile, this has all your team member's public keys. For Ad-hoc or App Store, this may have a more restricted list of developer certs to control which devs can actually distribute builds into the wild.
4. A list of entitlements, such as game center info, keychain info so apps can share keychains, iCloud ubiquity identifier, etc. In theory I assume this could be used to grant all kinds of permissions to bypass the sandbox. A non-wildcard profile specifies the explicit app identifier here; the device will refuse to honor certain entitlements if they are wildcards, that's why you need app-specific profiles if you use certain features.
5. Non-App Store profiles also contain a list of device UDIDs.
6. Then there's the binary container that wraps the plist and includes Apple's digital signature. Every device ships with Apple's certificates in the root trusted store and will refuse to load profiles not signed by an Apple certificate. The provisioning portal, enterprise accounts, et al is just a way for Apple to manage what goes into the profiles and whether or not they want to sign the resulting mobileprovision file.

When you do a build, Xcode takes the profile you selected then looks in your keychain certificates (TEAMS in Organizer) and tries to find a certificate with a private key that matches one of the public keys listed in the profile. When it can't, that's the "Valid signing identity not found" business.

Assuming it finds the cert, it signs the executable with the certificate private key. (I believe this is bog-standard Mach-O executable signing). That proves you did the build and the executable wasn't tampered with. That's it as far as your build goes, so selecting a profile is (mostly) just a "backwards" way of selecting the certificate as far as I can tell, except it also lets Xcode automatically load the profile onto the device and *i think* the build includes the app prefix (Bundle Seed ID), but really it's your certificate private key that protects from someone making malware builds with your name on them.

When the device installs or runs the code, it looks through installed profiles to find one specifying the matching public key and either a matching app ID or wildcard to validate the executable. It won't accept profiles not signed by Apple, expired profiles, or profiles that don't include its own UDID. The signature is verified to make sure the executable hasn't been corrupted. The sandbox also enforces the entitlements specified.
The exception is the App Store, where IIRC Apple's servers verify the uploaded build, then strip and re-sign with Apple's certificate but I may not be 100% correct on that.

So the short version is if you have the wildcard profile installed you can build apps all day long without doing anything else, so long as you don't want to share keychains, use iCloud/Game Center, etc. The profile only needs to be updated on new devices when that device has its UDID added or on all devices when a new team member/build server is added to the mix. You should be able to guess now why that is.

For large teams you can get fancy and only include the build server's certificate in the app store profiles so people can't submit rogue builds, or only allow managers to use the ad-hoc profile, etc.

super informative.. Someone should put this in the OP or save it somewhere so we don't lose it.

# ? Mar 15, 2013 13:10

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

Ender.uNF posted:

A good post.

Thanks for this!

Different topic:

Does this piss off anyone else in regards to Xcode? You do a single line

code:

if([blah bloop])

And you don't add brackets because it's only a single command afterwards. But when you type out whatever you're doing, Xcode places the corresponding [ in the wrong spot?

code:

if[([blah bloop])
  something else]

No, autocomplete, please don't put that closing [ in the wrong spot that makes no sense whatsover :saddowns:

# ? Mar 15, 2013 20:03

Doc Block: Apr 15, 2003; Fun Shoe

Use curly brackets even for single line IF and FOR statements, so you don't get surprises later or forget to add them if you need to add more stuff to the conditional block.

# ? Mar 15, 2013 20:21

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Doh004 posted:

No, autocomplete, please don't put that closing [ in the wrong spot that makes no sense whatsover

That seems really terrible; I've added it as an example to an existing bug about this. Sorry!

# ? Mar 15, 2013 21:21

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

Doc Block posted:

Use curly brackets even for single line IF and FOR statements, so you don't get surprises later or forget to add them if you need to add more stuff to the conditional block.

While you are correct, I'm lazy and I wouldn't want this to get into a programming debate.

rjmccall posted:

That seems really terrible; I've added it as an example to an existing bug about this. Sorry!

Sorry? Do you work for Apple? If so, no worries I'm not blaming anyone. I didn't know if it was intentional, but I guess it's a bug.

# ? Mar 15, 2013 21:32

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Doh004 posted:

Sorry? Do you work for Apple? If so, no worries I'm not blaming anyone. I didn't know if it was intentional, but I guess it's a bug.

It's definitely a bug; thanks for the report.

I do indeed work for Apple, in the group that makes Xcode. I work on the LLVM compiler doing assorted things, and I also do a lot of the language design for various incremental improvements for Objective-C, most notably ARC.

# ? Mar 15, 2013 22:16

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

rjmccall posted:

It's definitely a bug; thanks for the report.

I do indeed work for Apple, in the group that makes Xcode. I work on the LLVM compiler doing assorted things, and I also do a lot of the language design for various incremental improvements for Objective-C, most notably ARC.

Whoa, hey that's rad. Sorry if I sounded mean or rude about it. :respek:

# ? Mar 15, 2013 22:45

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Doh004 posted:

Whoa, hey that's rad. Sorry if I sounded mean or rude about it.

Heh. You didn't come across that way at all, and even if you had, it'd be understandable. Just remember that it really is okay to file bug reports, and we do pay attention to them!

# ? Mar 15, 2013 22:56

lmao zebong: Nov 25, 2006; NBA All-Injury First Team

Running into kind of a strange issue here and I was wondering if somebody here could point me in the right direction.

I have a ViewController that has two separate ViewControllers that it manages. One of these views is 'hidden' behind the other view, in that it is not exposed until a button is pressed, and the foreground view moves down and shows the view in the back. The foreground view is a UIScrollView, and the background view is a UITableView.

The problem I have having is setting up accessibility for this particular screen. While the UIScrollView is in front of the UITableView, the UITableViewCells are accessible by Voice Over, which is obviously not ideal. I can easily tell the UITableView's header and footer views to setAccessibilityElementsHidden:YES, which makes them inaccessible from Voice Over while UIScrollView is in front. However for the life of me I can't get these stupid UITableViewCells to not be accessible. I can show the code I have here:

code:

- (void)disableAccessibility:(BOOL)disable
{
    if (disable) {
        for (UIView *view in self.tableView.tableHeaderView.subviews) {
            [view setAccessibilityElementsHidden:YES];
        }
        for (UITableViewCell *cell in self.tableView.visibleCells) {
            [cell setAccessibilityElementsHidden:YES];
        }
    } else { 
        for (UIView *view in self.tableView.tableHeaderView.subviews) {
            [view setAccessibilityElementsHidden:NO];
        }
        for (UITableViewCell *cell in self.tableView.visibleCells) {
            [cell setAccessibilityElementsHidden:NO];
        }
    }
}

This code lives inside the UITableViewController class. The table's View Controller is a subclass of UITableViewController, and the cells in the table view are a custom subclass of UITableViewCell. I make sure to do [self setIsAccessibilityElement:YES] when I create each cell.
I've also tried [self.tableView setAccessibilityElementsHidden:YES] but that doesn't work either.

What am I missing here? I assume I'm misunderstanding something important about the UIAccessibility Protocol.

lmao zebong fucked around with this message at 01:42 on Mar 16, 2013

# ? Mar 16, 2013 01:37

Glimm: Jul 27, 2005; Time is only gonna pass you by

lmao zebong posted:

Running into kind of a strange issue here and I was wondering if somebody here could point me in the right direction.

I have a ViewController that has two separate ViewControllers that it manages. One of these views is 'hidden' behind the other view, in that it is not exposed until a button is pressed, and the foreground view moves down and shows the view in the back. The foreground view is a UIScrollView, and the background view is a UITableView.

The problem I have having is setting up accessibility for this particular screen. While the UIScrollView is in front of the UITableView, the UITableViewCells are accessible by Voice Over, which is obviously not ideal. I can easily tell the UITableView's header and footer views to setAccessibilityElementsHidden:YES, which makes them inaccessible from Voice Over while UIScrollView is in front. However for the life of me I can't get these stupid UITableViewCells to not be accessible. I can show the code I have here:
code:
- (void)disableAccessibility:(BOOL)disable
{
    if (disable) {
        for (UIView *view in self.tableView.tableHeaderView.subviews) {
            [view setAccessibilityElementsHidden:YES];
        }
        for (UITableViewCell *cell in self.tableView.visibleCells) {
            [cell setAccessibilityElementsHidden:YES];
        }
    } else { 
        for (UIView *view in self.tableView.tableHeaderView.subviews) {
            [view setAccessibilityElementsHidden:NO];
        }
        for (UITableViewCell *cell in self.tableView.visibleCells) {
            [cell setAccessibilityElementsHidden:NO];
        }
    }
}
This code lives inside the UITableViewController class. The table's View Controller is a subclass of UITableViewController, and the cells in the table view are a custom subclass of UITableViewCell. I make sure to do [self setIsAccessibilityElement:YES] when I create each cell.
I've also tried [self.tableView setAccessibilityElementsHidden:YES] but that doesn't work either.

What am I missing here? I assume I'm misunderstanding something important about the UIAccessibility Protocol.

Can you just hide the entire UITableView (self.tableView.hidden = YES) until the UIScrollView scrolls out? Could even animate its alpha in/out with the scroll view.

# ? Mar 16, 2013 02:07

lmao zebong: Nov 25, 2006; NBA All-Injury First Team

Glimm posted:

Can you just hide the entire UITableView (self.tableView.hidden = YES) until the UIScrollView scrolls out? Could even animate its alpha in/out with the scroll view.

Yep, that accomplishes exactly what I'm trying to do. Thanks for the tip, I had been doing so much accessibility stuff today I didn't even think about simply hiding the entire view, I was so focused on accessibility of the cells.

# ? Mar 16, 2013 03:38

Glimm: Jul 27, 2005; Time is only gonna pass you by

lmao zebong posted:

Yep, that accomplishes exactly what I'm trying to do. Thanks for the tip, I had been doing so much accessibility stuff today I didn't even think about simply hiding the entire view, I was so focused on accessibility of the cells.

Awesome, glad it worked

It's easy to get blinders like that when you're stuck in one thing for awhile.

# ? Mar 16, 2013 03:40

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

rjmccall posted:

It's definitely a bug; thanks for the report.

I do indeed work for Apple, in the group that makes Xcode. I work on the LLVM compiler doing assorted things, and I also do a lot of the language design for various incremental improvements for Objective-C, most notably ARC.

Cool! Do you work with Jordan? Small world. Keep up the good work.

# ? Mar 16, 2013 05:11

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Jordan is two doors down, on the other side of our shared manager, so yes, I do work with him.

# ? Mar 16, 2013 08:51

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

So this page mentions "WebKit Framework" as a feature of iOS, but the actual framework and its constituent libraries are private API (using them gets you rejected from the App Store). The page even has the gall to claim that "Your application can interact with the Web as a first-class information and communication source without having to write a lot of low-level networking or parsing code" without adding "so long as you use UIWebView and send it some JavaScript". The other items on that page are perfectly usable public API, then the last item just isn't.

# ? Mar 17, 2013 16:19

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

pokeyman posted:

So this page mentions "WebKit Framework" as a feature of iOS, but the actual framework and its constituent libraries are private API (using them gets you rejected from the App Store). The page even has the gall to claim that "Your application can interact with the Web as a first-class information and communication source without having to write a lot of low-level networking or parsing code" without adding "so long as you use UIWebView and send it some JavaScript". The other items on that page are perfectly usable public API, then the last item just isn't.

IIRC your UIWebViews don't get to use the fancypants JavaScript engine because the real one emits JIT compiled code, so UIWebView is noticeably slower executing JavaScript with the interpreter.

I think Apple's stuck with the whole "impossible-to-verify-x86" code problem. I haven't dug into Google's NaCl project to see how they solved it but I know its a difficult problem, so Apple just made a blanket ban on downloadable/runtime-generated code. Presumably they also don't want to deal with an app that gets approved, then downloads some entirely different app once in the wild.

In a managed code world (C#/Java) the system's runtime loader can do verifiable checks of what the new code does and reject it if needed, Oracle's* recent Java exploits notwithstanding. In theory you might be able to red-flag it if the downloaded code tried to bring in new frameworks or made up too much % of the executing code. I'm not sure how you approach that problem; On Windows RT presumably you could update your app completely outside Microsoft's approval process, assuming they allow runtime Reflection.Emit or Assembly Load.

*(Rumor is the Java codebase used to take six weeks to verify for a new build due to Sun's incompetence, laziness, or whatever. That's now down to less than a week, so security fixes can be regression-tested for release much faster. This was apparently a massive amount of work to setup the automated tests, labs, build process, etc).

# ? Mar 17, 2013 18:30

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Ender.uNF posted:

IIRC your UIWebViews don't get to use the fancypants JavaScript engine because the real one emits JIT compiled code, so UIWebView is noticeably slower executing JavaScript with the interpreter.

Yep.

Ender.uNF posted:

I think Apple's stuck with the whole "impossible-to-verify-x86" code problem. I haven't dug into Google's NaCl project to see how they solved it but I know its a difficult problem, so Apple just made a blanket ban on downloadable/runtime-generated code. Presumably they also don't want to deal with an app that gets approved, then downloads some entirely different app once in the wild.

These are both excellent reasons, but another big one is that we just don't want to allow random user pages to get flagged executable, because that makes it much easier to get from "oh, there's a bug where loading a malicious tweet can crash the app" to "oh, there's a bug where loading a malicious tweet lets someone compromise your Twitter account", and from there potentially to "oh, there's a bug where loading a malicious tweet lets someone root your phone".

# ? Mar 17, 2013 21:05

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

Ender.uNF posted:

IIRC your UIWebViews don't get to use the fancypants JavaScript engine because the real one emits JIT compiled code, so UIWebView is noticeably slower executing JavaScript with the interpreter.

I'm 100% OK with that and have no problem with JavaScript performance in UIWebView. The impetus for me finding and bitching about that page was wanting to parse HTML with something more useful than libxml. WebCore's HTML parser would work great, and it's ostensibly available in iOS, but I'm not allowed to use it. I realize it's a nonzero amount of work to support a public API, it's just frustrating to be left with compiling a library that's already on the device. Dumping a string of HTML into UIWebView then extracting pieces of the parse tree using JavaScript isn't what I envision when I read that page.

I guess my question is, does anyone know of a decent HTML parsing library in (Objective-)C(++)?

# ? Mar 17, 2013 23:16

dizzywhip: Dec 23, 2005

App review times are making me sad

Six days to get past waiting for review, and now it's been in review for twelve days so far. I will be the Saddest Developer if it gets rejected after all this waiting.

# ? Mar 18, 2013 01:26

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

You are spoiled if you are dealing with anything less than the two month waits from a few years ago. I had a crash fix rejected after a month and a half review because the bottle graphic in my app with a pear on its logo was suddenly an unrated alcohol reference. I was bumped back to the bottom of the list and approved a month and a half later yet after doing literally nothing but changing the rating radio button that no one in the review process could be bothered to do.

No, I'm not still bitter about that and how the crash my app had in the wild for three months destroyed my sales, why do you ask?

# ? Mar 18, 2013 03:08

lord funk: Feb 16, 2004

Gordon Cole posted:

App review times are making me sad Six days to get past waiting for review, and now it's been in review for twelve days so far. I will be the Saddest Developer if it gets rejected after all this waiting.

If you're in review (not waiting) for that long you should write them a note. It's happened to me before.

# ? Mar 18, 2013 04:11

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

ManicJason posted:

You are spoiled if you are dealing with anything less than the two month waits from a few years ago. I had a crash fix rejected after a month and a half review because the bottle graphic in my app with a pear on its logo was suddenly an unrated alcohol reference. I was bumped back to the bottom of the list and approved a month and a half later yet after doing literally nothing but changing the rating radio button that no one in the review process could be bothered to do.

No, I'm not still bitter about that and how the crash my app had in the wild for three months destroyed my sales, why do you ask?

That's what the emergency review request is for; as long as you aren't abusing it they tend to honor the request (but no guarantees). I had a crash bug and they bumped me to the top of the queue and approved the update within two or three days.

It's called an Expedited App Review.

# ? Mar 18, 2013 15:29

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

Either it didn't exist years ago when that happened to me or I was just too green to know about it.

I just enjoy telling my ten miles through the snow uphill both ways iOS story.

# ? Mar 18, 2013 16:23

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

pokeyman posted:

So this page mentions "WebKit Framework" as a feature of iOS, but the actual framework and its constituent libraries are private API (using them gets you rejected from the App Store).

More annoyance: on iOS there's no public API I can find that makes NSURL instances out of strings with unicode hostnames. And ICU isn't public either, so it can't help.

I do enjoy complaining into the empty void...

# ? Mar 19, 2013 04:57

Doc Block: Apr 15, 2003; Fun Shoe

pokeyman posted:

I do enjoy complaining into the empty void...

Duck Monster alt account spotted :lol:

Doc Block fucked around with this message at 13:39 on Mar 19, 2013

# ? Mar 19, 2013 11:57

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

pokeyman posted:

More annoyance: on iOS there's no public API I can find that makes NSURL instances out of strings with unicode hostnames. And ICU isn't public either, so it can't help.

I do enjoy complaining into the empty void...

My kingdom for NSMutableURL.

# ? Mar 19, 2013 23:42

Froist: Jun 6, 2004

I've got a UIViewController subclass where I want to pass on the title property to a child view whenever it changes. I thought the obvious/simple way to do this would be to override setTitle, but when I do that I get the linker error:

code:

Undefined symbols for architecture armv7:
  "_OBJC_IVAR_$_UIViewController._title", referenced from:
      -[SBMenuViewController setTitle:] in SBMenuViewController.o
ld: symbol(s) not found for architecture armv7

My setTitle override is:

code:

- (void) setTitle:(NSString *)title
{
    if ([title isEqualToString:_title])
        return;
    
    [self willChangeValueForKey:@"title"];
    _title = title;
    [self didChangeValueForKey:@"title"];
    
    _titleBar.title = title;
}

Is there something I'm doing wrong here? I've only recently learned to add the (will|did)ChangeValueForKey calls, but even without those I still get the error. (Side-question - is there a way to automatically get the key name when calling those functions, rather than manually adding the string twice?)

My workaround for now is removing the setTitle override and just listening to the value changed notifications myself, but it seems overly complex:

code:

- (void) viewDidLoad
{
    [super viewDidLoad];
    [self addObserver:self forKeyPath:@"title" options:NSKeyValueObservingOptionNew context:nil];
}

- (void) viewDidUnload
{
    [super viewDidUnload];
    [self removeObserver:self forKeyPath:@"title"];
}

- (void) observeValueForKeyPath:(NSString *)keyPath
                       ofObject:(id)object
                         change:(NSDictionary *)change
                        context:(void *)context
{
    if ([keyPath isEqualToString:@"title"]) {
        _titleBar.title = self.title;
    }
}

Which of these do people prefer for a cleaner approach?

# ? Mar 20, 2013 19:59

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

Ender.uNF posted:

My kingdom for NSMutableURL.

Or an easy way to build URL params that doesn't require giant external libs or lovely homebrew.

# ? Mar 20, 2013 20:04

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Froist posted:

I've got a UIViewController subclass where I want to pass on the title property to a child view whenever it changes. I thought the obvious/simple way to do this would be to override setTitle, but when I do that I get the linker error:
code:
Undefined symbols for architecture armv7:
  "_OBJC_IVAR_$_UIViewController._title", referenced from:
      -[SBMenuViewController setTitle:] in SBMenuViewController.o
ld: symbol(s) not found for architecture armv7

UIViewController's _title ivar has to be declared protected in the header for obscure reasons, but you can't actually use it from user code. You need to use the accessor, i.e. you should be assigning to super.title instead of _title.

# ? Mar 20, 2013 21:14

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

Edit: my suggestion was redundant

# ? Mar 20, 2013 21:56

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 12:07

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

Ender.uNF posted:

My kingdom for NSMutableURL.

No kidding. I finally decided to start doing something about this, and ended up with this. Useful on its own, maybe a start for an actual mutable NSURL.

I also found DDURLBuilder halfway through making mine. Takes a different approach, and includes a query builder.

# ? Mar 20, 2013 23:48

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

«‹›354 »